A [flax].

Одной из самых больших сложностей при создании схем является проблема детерминистического описания. Описание данной проблемы и ее истоков можно причерпнуть из RELAX NG by Eric van der Vlist:: Chapter 16. Determinism and Datatype Assignme

A [flax]. Дополнительные разъяснения comp.text.xml (не для новичков)

A [flax]. Краткое разъяснение детерминистичности от David Marteinson (cм. также http://www.w3.org/TR/REC-xml/#determinism):

There is no contradiction in saying that XML content models are both
context free and deterministic. The deterministic thing just means that
at each step the parser can determine exactly which model group it's in
(without look-ahead). 
Consider the example from the rec:   ((b, c) | (b, d))  This is 
non-deterministic because once the parser encounters a <b> it doesn't know
yet whether it's in (b,c) or (b,d). So we'd have to write this content model
this way:  b, (c|d) in which case after a <b> the parser is in model group (c|d).

A [flax].

Для начала перечислим некоторые, часто встречающиеся ситуации и ошибки, приводящие к нарушению детерминистичности.

<xsd:element name="code">
   <xsd:complexType>
      <xsd:choice maxOccurs="unbounded">
 
        <xsd:element name="setbit">
          <xsd:attribute name="att1" type="xsd:string" use="required"/>
          <xsd:attribute name="att2" type="xsd:string" use="required"/>
        </xsd:element>
 
         <xsd:element name="setbit">
           <xsd:attribute name="att3" type="xsd:string" use="required"/>
           <xsd:attribute name="att4" type="xsd:string" use="required"/>
         </xsd:element>
 
      </xsd:choice>
    </xsd:complexType>
</xsd:element>

Richard Tobin (W3C XML Core Working Group :) ) отмечает:

Because matching of content models does not take any account of the
types of the child elements, only their names.

При распознавании моделей содержимого типы дочерних элементов не рассматриваются, и учитываются только их имена.

A [flax].

<xs:complexType name="MyMessageType">
 <xs:complexContent>
   <xs:extension base="sg:FieldsType">
     <xs:sequence maxOccurs="unbounded">
       <xs:element name="field1" type="skt:field1type"/>
       <xs:element name="field2" type="skt:field2type" minOccurs="0"/>
        ..
        ..
       <xs:element name="fieldn" type="skt:fieldntype"/>
 
       <xs:sequence maxOccurs="unbounded">
         <!-- Обратите внимание на опциональное minOccurs=0 присутсвие fieldx здесь ...-->
         <xs:element name="fieldx" type="skt:fieldxtype" minOccurs="0"/>
         <xs:element name="field1" type="skt:field1type" />
       </xs:sequence>
 
       <!-- ...и здесь. Именно при этом нарушается детерминизм-->
       <xs:element name="fieldx" type="skt:fieldxtype" minOccurs="0"/>
    </xs:sequence>
   </xs:extension>
 </xs:complexContent>
</xs:complexType>

Richard Tobin замечает, что необходимо изменить (fieldx?, field1)+, fieldx? определение на аналогичное ( но уже детерминистическое) определение fieldx?, (field1, fieldx?)+

A [flax]. Для того, чтобы проверить схему, а также точно найти возможные нарушения модели, можно использовать XSV: XSV -i yourschema.xsd