[xsd-users] Preserving XML element order

[Boris Kolpackov]

Hi Barrie,

Barrie Kovish <barrie.kovish at singularsoftware.com> writes:

> <xs:element name='A' type='xs:string'>
> 
>  <xs:element name='W'>
>   <xs:complexType>
>    <xs:choice minOccurs='0' maxOccurs='unbounded'>
>      <xs:element ref='A'/>
>      <xs:element ref='B'/>
>    </xs:choice>
>   </xs:complexType>
>  </xs:element>
> 
>  <xs:element name='U'>
>   <xs:complexType>
>    <xs:choice minOccurs='0' maxOccurs='unbounded'>
>      <xs:element ref='W'/>
>      <xs:element ref='V'/>
>    </xs:choice>
>     <xs:attribute name='id' type='xs:string'/>  
>   </xs:complexType>
>  </xs:element>
> 
> I would say that 90% of the schema is structure like this.  There 
> are probably 50-100 choice elements in the schema and another 100-200 
> string and integer elements.

Barrie Kovish <barrie.kovish at singularsoftware.com> writes:

> There is probably another aspect of the schema I should mention.  The 
> various element types are shared.  By this I mean the following:
> 
>  <xs:element name='W'>
>   <xs:complexType>
>    <xs:choice minOccurs='0' maxOccurs='unbounded'>
>      <xs:element ref='A'/>
>      <xs:element ref='B'/>
>    </xs:choice>
>   </xs:complexType>
>  </xs:element>
> 
> 
>  <xs:element name='X'>
>   <xs:complexType>
>    <xs:choice minOccurs='0' maxOccurs='unbounded'>
>      <xs:element ref='A'/>
>      <xs:element ref='C'/>
>    </xs:choice>
>   </xs:complexType>
>  </xs:element>
> 
> 
> So elements named A are shared between elements named X and W.

In such cases C++/Tree just makes two separate sequences, one for
element A, another for element B. If you only had a handful of
types that used such a choice construct then this could have been
handled by customizing the corresponding types and proving order-
sensitive storage as well as parsing and serialization. But if you 
have a hundred of them then this approach won't scale. So I would
suggest that you take a look at C++/Hybrid in XSD/e. This mapping
will preserve ordering without any extra work from your side.

If you really want to stick to C++/Tree and XSD then there might be 
a way to still work around this situation if you don't add/remove any 
elements. I.e., the only modification that you make is the change of 
values of attributes and simple type elements (e.g., A in the schema 
above). In a nutshell, the idea is to use the original DOM document
for structure and then re-set the elements and attributes with simple
types from the object model. Because we can only get an object model
node from a DOM node as xml_schema::type&, we will need to use the 
polymorphic type map to call the serializer function in a polymorphic
way. This add another limitation to this approach namely that none 
of the simple type elements/attributes can have anonymous types since
those are not registered in the maps. Let me know if you think this 
might work for your situation and I will provide you with a more 
detailed outline.

Boris