..., 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
