[
Lists Home |
Date Index |
Thread Index
]
"Nada Reinprecht" <Nada_Reinprecht@nemmco.com.au> writes:
> The problem is:
> there are a, b, c and d entities that can be represented with the same type
> x
> there is e entity that can be represented with type y which is derivation
> of type x.
> there is need to identify a, b, c, d and distinguish between them
> all these entities are used in the same transaction where any combination
> of entities is allowed
> options:
>
> 1.use elements a type x, b type x, c type x, d type x and e type y; place
> them in the transaction as optional elements; the solution is clean but
> requires rigid order of elements in the transaction.
This is the correct solution in my opinion -- if order does not encode
any information, then imposing an arbitrary order is good, not bad -- leaving
order unconstrained encourages people to suppose that perhaps
<container>
<a>...</a>
<b>...</b>
</container>
actually means something different from
<container>
<b>...</b>
<a>...</a>
</container>
However, this is an FARP (Frequently Asserted Religious Position), and
if you're not a devotee, you can use an <all> group to allow any
order, e.g.
<xs:all>
<xs:element name="a" type="my:x" minOccurs="0"/>
<xs:element name="b" type="my:x" minOccurs="0"/>
<xs:element name="c" type="my:x" minOccurs="0"/>
<xs:element name="d" type="my:x" minOccurs="0"/>
<xs:element name="e" type="my:y" minOccurs="0"/>
</xs:all>
ht
--
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
Half-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
|
