Re: xs:choice and xs:sequence question

Hi David,

oXygen reports the error with a link to the specification related with that:
http://www.w3.org/TR/xmlschema-1/#cos-nonambig

The idea is that when a parser sees the Description element it should be 
able to identify whether that Description is the Description from the 
first sequence inside the choice or the Description from the second 
sequence inside the choice without looking forward in your document to 
see what follows after Description. That is not possible if both 
sequences start with Description.

The general solution for these cases is to rewrite the content model in 
a non ambiguous way, sometimes this is simple but sometimes this may be 
difficult if not impossible.

In your case you have (d*, m?) | (d+, m, a). I think it is not possible 
to rewrite that in a non ambiguous way.
If the model (a, d+, m) | (d*, m?) works for you then use that as it is 
not ambiguous.

Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com


David Carver wrote:
> George you are correct, after re-running some tests yesterday none of 
> the processors validated it, not sure what happened on the first run 
> with Xerces and XSV.   Anyway, I did finally manage to get working what 
> I wanted by doing the following:
> 
> This works:
>    <xs:complexType name="ProcessingOutcomeMessage">
>        <xs:choice>
>            <xs:sequence>
>                <xs:element name="ApplicationReasonCode" 
> type="ApplicationReasonCode" />
>                <xs:element name="Description" type="Description" 
> maxOccurs="unbounded" />
>                <xs:element name="MessageReasonCode" 
> type="MessageReasonCode" />
>            </xs:sequence>
>            <xs:sequence>
>                <xs:element name="Description" type="Description" 
> minOccurs="0" maxOccurs="unbounded" />
>                <xs:element name="MessageReasonCode" 
> type="MessageReasonCode" minOccurs="0" />
>            </xs:sequence>
>        </xs:choice>
>    </xs:complexType>
> 
> The below doesn't work:
> 
>  <xs:complexType name="ProcessingOutcomeMessage">
>      <xs:choice>
>          <xs:sequence>
>              <xs:element name="Description" type="Description" 
> minOccurs="0" maxOccurs="unbounded" />
>              <xs:element name="MessageReasonCode" type="Description" 
> minOccurs="0" />
>          </xs:sequence>
>          <xs:sequence>
>              <xs:element name="Description" type="Description" 
> minOccurs="1" maxOccurs="unbounded" />
>              <xs:element name="MessageReasonCode" 
> type="MessageReasonCode" minOccurs="1" />
>              <xs:element name="ApplicationReasonCode" 
> type="ApplicationReasonCode" minOccurs="1">
>                  <xs:annotation>
>                      <xs:documentation 
> source="http://www.starstandard.org">Contains a software specific 
> application reason code.</xs:documentation>
>                  </xs:annotation>
>              </xs:element>
>          </xs:sequence>
>      </xs:choice>
>  </xs:complexType>
> 
> 
> 
> The only way to get this to work was to have ApplicationReasonCode as 
> the ApplicationReasonCode as the first element in the first sequence.  
> If it was included after MessageReasonCode in the first sequence, every 
> parser would complain about not being able to determine how to handle 
> the Description element.   I would have thought that it wouldn't have 
> mattered what order the elements were setup in the sequence but 
> apparently in this case it does.   It would have been helpful if the 
> specs were a bit clearer on exactly what has to occur in this type of 
> situation.   Anyways, it now validates against Xerces, XSV, XML Spy, 
> MSXML and Oxygen.
> 
>