[xsd-users] Preserving element order in MusicXML?

[Boris Kolpackov]

Hi Mario,

Mario Lang <mlang at delysid.org> writes:

> <xs:choice>
> 	<xs:sequence>
> 		<xs:element name="grace" type="grace"/>
> 		<xs:group ref="full-note"/>
> 		<xs:element name="tie" type="tie" minOccurs="0" maxOccurs="2"/>
> 	</xs:sequence>
> 	<xs:sequence>
> 		<xs:element name="cue" type="empty"/>
> 		<xs:group ref="full-note"/>
> 		<xs:group ref="duration"/>
> 	</xs:sequence>
> 	<xs:sequence>
> 		<xs:group ref="full-note"/>
> 		<xs:group ref="duration"/>
> 		<xs:element name="tie" type="tie" minOccurs="0" maxOccurs="2"/>
> 	</xs:sequence>
> </xs:choice>
>
> [...]
> 
> Is this a bug in the generated serialisation code?

I suppose you can say that. This is the consequence of the "flattening"
approach that I talked about in my previous email. In this case XSD tries
to serializes each element in the order that it is encountered in the
flattened view of the above content model. This works in most real-world
schemas and results in a simpler API. However, this approach does not work
in cases where there are several choice arms that have the same elements
and they appear in different order. I don't think we will be able to fix
this in C++/Tree since that would require significant changes (and
complications) to the mapping architecture.


> If not, and this is again expected behaviour, can you see a way how I could
> modify the schema to make these cases work?  

One workaround would be to "relax" the schema for the purpose of code
generation (you would still use the original schema for validation, etc.).
For example, you can replace the above fragment with something along these
lines:

<xs:sequence>
  <xs:element name="cue" type="empty" minOccurs="0"/>
  <xs:element name="grace" type="grace" minOccurs="0"/>
  <xs:group ref="full-note"/>
  <xs:group ref="duration" minOccurs="0"/>
  <xs:element name="tie" type="tie" minOccurs="0" maxOccurs="2"/>
</xs:sequence>

This model accepts all instances that are accepted by the original model
(but also accepts instances that are invalid per the original) and should
result in the correct serialization by C++/Tree.

One possible way to address this flattening issue in the generic way
would be to implement an automatic transformation like this in the
compiler.

Boris