[xsd-users] xsdcxx-musicxml

[Boris Kolpackov]

Hi Mario,

Mario Lang <mlang at delysid.org> writes:

> <xs:sequence>
>   <xs:choice>
>     <xs:sequence>
>       <xs:element name="a".../>
>       <xs:element name="c".../>
>       <xs:element name="d".../>
>     </xs:sequence>
>     <xs:sequence>
>       <xs:element name="b".../>
>       <xs:element name="c".../>
>       <xs:element name="e".../>
>     </xs:sequence>
>     <xs:sequence>
>       <xs:element name="c".../>
>       <xs:element name="d".../>
>       <xs:element name="e".../>
>     </xs:sequence>
>   </xs:choice>
>   <xs:element.../>...
> </xs:sequence>

To serialize, e.g., 'c' in the correct order, XSD would need to know
which arm of the choice it is. Since XSD "flattens" choices, this is
not possible in the current architecture. In this particular case
you can kind of infer which arm it is based on which elements are
present/absent. But that would be impossible to extend to the general
case.


> I have a feeling that all that is missing, is to fix the "sorting" order
> of the flattened structure.  Or, maybe, to detect identical elements in
> a choice of sequences.  Because, in the <choice> above, <c> is *always*
> required to be present, <a> and <b> are mutually exclusive, and <d> and
> <e> are only allowed if one of <a> or <b> is present.  Again, to me, it
> looks like the serialization order is rather unambigious from the
> grammar given.

I would suggest that you customize the serializer operator for this
type. Implementing this in XSD will be non-trivial, to put it mildly.

Boris