Sven wrote:
> But with this schema, the order of "Name" and "Content" is relevant.
> Is there a way to define this in a way that this order is variable?


Just a thought, which I haven't tested: How about starting with an empty 
ItemType, then driving the specific versions from that, each with their 
own independent definition of the content? Something like:

  <xs:complexType name="ItemType">
  </xs:complexType>

<xs:complexType name="TextItemType">
   <xs:complexContent>
     <xs:extension base="ItemType">
       <xs:sequence maxOccurs="unbounded" minOccurs="1">
         <xs:choice>
           <xs:element name="Name" type="xs:string" />
           <xs:element name="Content" type="xs:string" />
         </xs:choice>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
</xs:complexType>

<xs:complexType name="OtherItemType">
   <xs:complexContent>
     <xs:extension base="ItemType">
       <xs:sequence maxOccurs="unbounded" minOccurs="1">
         <xs:choice>
           <xs:element name="Name" type="xs:string" />
           <xs:element name="Number" type="xs:integer" />
         </xs:choice>
       </xs:sequence>
     </xs:extension>
   </xs:complexContent>
</xs:complexType>

Of course this does have the problem that each kind of ItemType can have 
multiple instances of its fields; if that's an issue, see past posts 
here and in the XSLT FAQ for (somewhat painful) ways to overcome that. 
And I think you'd have to use xsi:type to tell the validator which type 
you intended this particular element to conform to.

BTW, the _good_ fixes are either to make folks provide the values in a 
stereotyped order, unless the variability is actually necessary for your 
application (any decent coder, and any human, ought to be able to follow 
that simple set of instructions)... or to recognize that XML Schema 
really isn't intended to capture every possible constraint, and to 
impose some of them in documentation and in application-level tests.



-- 
() ASCII Ribbon Campaign  | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry