XSD: Extenstion, substituion, and recursion, Oh My!

[David M. Aldridge]

(Background and details are first, with my questions at the end.)

Consider the following hierarchy:

Foo (abstract base)
FooDerived1
FooDerived2
<...>
Bar

At runtime, any Foo instance may have one-or-more Foo children or Bar
instances.

For example:

FooDerived1
Bar
FooDerived1
Bar
Bar
FooDerived2
Bar
FooDerived1
Bar
Bar


I'm trying to represent the above via XML Schema (I'm just learning, and
have only been at this for a couple of days), and have come up with two
possibilities (root element and other minor details omitted):

OPTION 1 (XSD)

<xs:simpleType name="Bar">
<xs:restriction base="xs:integer">
<xs:maxInclusive value="100"></xs:maxInclusive>
</xs:restriction>
</xs:simpleType>

<xs:complexType name="Foo" abstract="true">
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="FooDerived1" type="FooDerived1"/>
<xs:element name="FooDerived2" type="FooDerived2"/>
<xs:element name="Bar" type="Bar"/>
</xs:choice>
</xs:sequence>
</xs:complexType>

<xs:complexType name="FooDerived1">
<xs:complexContent>
<xs:extension base="Foo">
</xs:extension>
</xs:complexContent>
</xs:complexType>

<xs:complexType name="FooDerived2">
<xs:complexContent>
<xs:extension base="Foo">
</xs:extension>
</xs:complexContent>
</xs:complexType>


OPTION 2 (XSD)

<xs:simpleType name="Bar">
<xs:restriction base="xs:integer">
<xs:maxInclusive value="100"></xs:maxInclusive>
</xs:restriction>
</xs:simpleType>

<xs:complexType name="Foo" abstract="true">
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="Foo" type="Foo"/>
<xs:element name="Bar" type="Bar"/>
</xs:choice>
</xs:sequence>
</xs:complexType>

<xs:complexType name="FooDerived1">
<xs:complexContent>
<xs:extension base="Foo">
</xs:extension>
</xs:complexContent>
</xs:complexType>

<xs:complexType name="FooDerived2">
<xs:complexContent>
<xs:extension base="Foo">
</xs:extension>
</xs:complexContent>
</xs:complexType>



Both options are equally valid and represent the same structure, but the
XML syntax is different (OPTION 2 requires xsi:type):

OPTION 1 (XML)

<FooDerived1>
<Bar>1</Bar>
<FooDerived1>
<Bar>2</Bar>
<Bar>3</Bar>
</FooDerived1>
<FooDerived2>
<Bar>4</Bar>
<FooDerived1>
<Bar>5</Bar>
</FooDerived1>
</FooDerived2>
<Bar>6</Bar>
</FooDerived1>


OPTION 2 (XML)

<Foo xsi:type="FooDerived1">
<Bar>1</Bar>
<Foo xsi:type="FooDerived1">
<Bar>2</Bar>
<Bar>3</Bar>
</Foo>
<Foo xsi:type="FooDerived2">
<Bar>4</Bar>
<Foo xsi:type="FooDerived1">
<Bar>5</Bar>
</Foo>
</Foo>
<Bar>6</Bar>
</Foo>



I prefer the readability of OPTION 1 (XML), but I prefer the schema of
OPTION 2 (XSD), as it doesn't require any <xs:choice> blocks, which is
easier to maintain and extend in my mind -- simply add a new type
extended from Foo, and you're set. With OPTION 1 (XSD), you add the new
type the same way, but then you have to go add a line to the <xs:choice>
block as well.

Additionally, the XSD will only be worked on internally, most likely by
myself, so I'm not worried about flexible extension of the schema by
others; however, the XML document has a higher chance of being
implemented/modified by another individual.


QUESTIONS

1) Aside from the oddity of the hierarchy (which cannot easily be
rearchitected), does it look like I'm doing anything "wrong" so far with
the schema definition?

2) Is there a better way to achieve the same result? These types (both
Foo<x> and Bar) will be nested/used in other types, so I cannot take the
element/substitutionGroup route...

3) Which of the two solutions above is preferable? Opinions welcome.


Thank you for any input you can provide!