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!