Thanks, Mukul.
Is there any special reason why such a simple scenario is so complex to
support witihn XSD ? The suggestion below definitely seems good, but a
schema with 10 or more elements [which is the case with my scenario] looks
very complex - visually at least - and loses readability.
rgds,
Menon


On 2/19/06, Mukul Gandhi <gandhi.mukul@g...> wrote:
>
> You can try something like this. i.e. use xs:choice to select one
> among all the permutations.
>
> <xs:element name="x">
> <xs:complexType>
>     <xs:choice>
>       <xs:sequence>
>           <xs:element name="a" type="xs:string"/>
>           <xs:element name="b" type="xs:string" maxOccurs="unbounde=
d"/>
>       </xs:sequence>
>       <xs:sequence>
>           <xs:element name="b" type="xs:string" maxOccurs="unbounde=
d"/>
>           <xs:element name="a" type="xs:string"/>
>       </xs:sequence>
>     </xs:choice>
> </xs:complexType>
>
> This works for this simple case. But once I make it slightly more
> complex as shown below (by introducing another element c), the XSD
> validator(XMLSpy 2006) reports that schema is not valid. It says
> "content model is non-deterministic. Possible causes: name equality,
> overlapping occurence or substitution groups".
>
> <xs:element name="x">
>   <xs:complexType>
>      <xs:choice>
>         <xs:sequence>
>             <xs:element name="a" type="xs:string"/>
>             <xs:element name="b" type="xs:string" maxOccurs="unboun=
ded"/>
>             <xs:element name="c" type="xs:string"/>
>         </xs:sequence>
>         <xs:sequence>
>            <xs:element name="b" type="xs:string" maxOccurs="unbound=
ed"/>
>            <xs:element name="a" type="xs:string"/>
>            <xs:element name="c" type="xs:string"/>
>         </xs:sequence>
>         <xs:sequence>
>            <xs:element name="a" type="xs:string"/>
>            <xs:element name="c" type="xs:string"/>
>            <xs:element name="b" type="xs:string" maxOccurs="unbound=
ed"/>
>         </xs:sequence>
>         <xs:sequence>
>            <xs:element name="c" type="xs:string"/>
>            <xs:element name="a" type="xs:string"/>
>            <xs:element name="b" type="xs:string" maxOccurs="unbound=
ed"/>
>         </xs:sequence>
>         <xs:sequence>
>            <xs:element name="b" type="xs:string" maxOccurs="unbound=
ed"/>
>            <xs:element name="c" type="xs:string"/>
>            <xs:element name="a" type="xs:string"/>
>         </xs:sequence>
>         <xs:sequence>
>            <xs:element name="c" type="xs:string"/>
>            <xs:element name="b" type="xs:string" maxOccurs="unbound=
ed"/>
>            <xs:element name="a" type="xs:string"/>
>          </xs:sequence>
>       </xs:choice>
> </xs:complexType>
> </xs:element>
>
> I am curious, is the validation happening correctly(for the case a, b,
> c), or is this bug in the validator?
>
> Regards,
> Mukul
>
>
> On 2/18/06, Ramkumar Menon <ramkumar.menon@g...> wrote:
> > Hi,
> >
> > is it possible to ignore the document order while using schema validato=
r
> to
> > validate an XSD ?
> > If not, is there an alternative to the following issue ?
> > I have an element that has a set of elements witihn it, one of them
> being
> > maxOccurs="unbounded". Since I wanted to use the "xsd:all" group so t=
hat
> I
> > can assume unordered child nodes, the node with maxOccurs="unbounded"
> > prevents me from making such a definition.
> >
> > Any help will be appreciated.
> > pls reply direcly to my email id, since I am not on this mailing list.
> >
> > rgds,
> > Ram
> >
> > --
> > Shift to the left, shift to the right!
> > Pop up, push down, byte, byte, byte!
> >
> > -Ramkumar Menon
> > A typical Macroprocessor
>



--
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!

-Ramkumar Menon
A typical Macroprocessor