..., let me try to explain my list
constraints:
A. ITEM1 and ITEM2 can not co-exist in the list.
B. The list can contain any number of ITEM1 (0-unbounded) OR any number of ITEM2 (0-unbounded), but only one of the types in a list. C. ITEM3 can also appear in the list, any number of times (0-unbounded), with or without the list having other elements. D. The order of the list does not carry any information, and so it does not matter.
So, Klaus and Eric's schemas will not be good because they allow ITEM1 and ITEM2 types in the same list.
Well, I repeat what I said earlier: if the order of the items in the list does not carry any information, it is usually better practice to specify a fixed order. Otherwise, you wind up with fierce, protracted arguments between people who want to argue that
<LIST1/><LIST1/><LIST3/>
must be treated subtly differently from
<LIST3/><LIST1/><LIST1/>
or
<LIST1/><LIST3/><LIST1/>
and people who argue, on the contrary, that because the order of items carries no information, these must NOT be treated separately. It is better to nip such disagreements in the bud.
I am almost unwilling to tell you how to do what you say you want to do, on the grounds that I am convinced you shouldn't do it, but if you are determined to provide an opening for such disagreements, honesty compels me to note that it's actually not impossible, just verbose. In regex notation, what you want is
(list3* ((list1 (list1 | list3)*) | (list2 (list2 | list3)*))?)
that is: any number of list3 elements, followed optionally by a mixed list of list1 and list3, or by a mixed list of list2 and list3. In
XML Schema terms:
<xsd:complexType name="LISTtype">
<xsd:annotation><xsd:documentation>
<div xmlns="
http://www.w3.org/1999/xhtml">
<p>A content model which allows any number of either LIST1 or LIST2 elements, together with any number of LIST3 elements, in any order.</p> <p>The problem with this model is that it is intended to convey the idea that "order doesn't matter" but will, by allowing different orderings of the same material, inevitably lead some users and some programmers to believe that there may be meaningful differences in meaning based on order. </p> </div></xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:element ref="LIST3" minOccurs="0" maxOccurs="unbounded"/> <xsd:choice minOccurs="0"> <xsd:sequence> <xsd:element ref="LIST1"/> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="LIST1"/> <xsd:element ref="LIST3"/> </xsd:choice> </xsd:sequence> <xsd:sequence> <xsd:element ref="LIST2"/> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="LIST2"/> <xsd:element ref="LIST3"/> </xsd:choice> </xsd:sequence> </xsd:choice> </xsd:sequence> </xsd:complexType>
The basic idea is that the instances of this content model will inevitably be either mixtures of LIST1 and LIST3, or of LIST2 and LIST3, or just sequences of LIST3. As long as you are just getting LIST3 elements, you can't tell which of these three possibilities is being realized. Once you see a LIST1 or a LIST2, however, you know which path to take through the regular expression and the other kind of list is no longer an option. Some people have said this content-model pattern reminds them of a harpoon: once the barb is in, the harpoon only goes one direction.
The more restrictive alternative is somewhat simpler:
<xsd:complexType name="simplerLISTtype">
<xsd:annotation><xsd:documentation>
<div xmlns="
http://www.w3.org/1999/xhtml">
<p>A simpler content model which prescribes an order and thus makes it impossible for variations in the order of elements to exist, let alone carry information. </p> <p>The only problem with this model is that some users will wish to convey subtle shades of meaning by putting the elements in different orders. The biggest virtue of this model is that it makes such behavior impossible. (If the shades of meaning are documented, they are worth having; otherwise, they are an illusion and only lead to tears down the road.) </p> </div></xsd:documentation></xsd:annotation> <xsd:sequence> <xsd:choice minOccurs="0"> <xsd:element ref="LIST1" maxOccurs="unbounded"/> <xsd:element ref="LIST2" maxOccurs="unbounded"/> </xsd:choice> <xsd:element ref="LIST3" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType>
I hope this helps.
-C. M. Sperberg-McQueen
