[xsd-users] Preserving XML element order

[Barrie Kovish]

Boris,

We do need to add nodes to the tree so the last option appears to be out.  I had a look at XSD/e and it looks like it won't support XPATH queries which is also a significant limitation for us.

Currently I am investigating using Xerxes.  This presents a much more complex programming model so is not appealing!  

Barrie

On 2010-02-11, at 11:11 AM, Boris Kolpackov wrote:

> 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