XML element order

Dunamis

[H]Lurker Supreme[/H]
Joined
Jun 30, 2004
Messages
2,301
I'm using xsd.exe in Visual Studio 2005 to create a strongly typed dataset from an XML file to an XSD file.

The problem is that when writing back into XML (DataSet.WriteXml()), the elements are not in the correct order.

What produced
Code:
<CXML>
  <CXMLRq error="stop">
    <AddRq>
      <Invoice>
        <Date>2009-08-25T13:11:03+12:00</Date>
        <RefNumber>InvNo0001</RefNumber>
        <Memo>Memo line 1</Memo>
        <CustRef>
          <ID>10002111</ID>
          <Name>John Doe</Name>
        </CustRef>
      </Invoice>
    </AddRq>
  </CXMLRq>
</CXML>

Notice the CustRef element is placed at the bottom?
What's expected:
Code:
<CXML>
  <CXMLRq error="stop">
    <AddRq>
      <Invoice>
        <CustRef>
          <ID>10002111</ID>
          <Name>John Doe</Name>
        </CustRef>
        <Date>2009-08-25T13:11:03+12:00</Date>
        <RefNumber>InvNo0001</RefNumber>
        <Memo>Memo line 1</Memo>
      </Invoice>
    </AddRq>
  </CXMLRq>
</CXML>
 
Sorry for asking a silly question, I'm trying to understand, but how does this hurt parsing? Your deserialization algorithm shouldn't have to depend on order. I'm probably missing some key piece of information.
 
There is no 'correct order' in XML, order is not significant. If you need to preserve ordering information, you need to build it into your schema with ID or sequence codes.
 
There is no 'correct order' in XML, order is not significant. If you need to preserve ordering information, you need to build it into your schema with ID or sequence codes.
Any pointers regarding the sequence codes?

This is a custom XML that I have to work with and have no control over how the data is parsed and in this case order of elements are important.
 
Sorry for asking a silly question, I'm trying to understand, but how does this hurt parsing? Your deserialization algorithm shouldn't have to depend on order. I'm probably missing some key piece of information.

In this case I just need to build the "request" XML and pass it back up. And as stated above I'm dealing with custom XML format and the order of elements are crucial.
 
Then you need to contact the person who designed the API you're dealing with and tell them to fix it, because while they may claim it's XML compliant, it clearly isn't if it cares about element order. I don't know anything about MS programming languages, so I'm not sure how you might force it to output the XML in a particular order, but I'm willing to bet it's a pain in the ass if it's even possible without string processing.

When I mentioned sequence numbers, I just meant the kludge that is adding an e.g. 'seq' attribute that you increment based on the sequence the elements should be interpreted in, and then sorting by at the receiving end once the XML is parsed. If you're doing this with anything that's not a list of similar typed elements, it's a giant kludge that shouldn't really be necessary with a properly designed schema.

You might have to resort to 'dumb' string processing if the target for this is unwilling to fix their implementation. If they don't support XML properly, why should you?
 
You might have to resort to 'dumb' string processing if the target for this is unwilling to fix their implementation. If they don't support XML properly, why should you?

I might have to go down this path.

Grrr... why can't people stick with the existing specifications!! :mad:
 
whoever made the original program should also make sure it passes XML, and give the tools on how to do that. This involves the program they wrote directly. If it doesnt work, the program needs to be changed, and they are the ones that change it, so if they do have it working then they should show you that it does by providing sample outputs.

Everything outside of the scope of their program is up to you to figure out. Since XML output seems to be within their program, they need to get it working. Once it is working its up to you to manipulate.

Also if the program uses XML input, then they should show you how the XML schema needs to be written to interact with the program.

In your example is seems that the data is entered into your XML with the proper tags. I believe the issue lies with the way the parser reads the data tags. Instead of doing a line by line (ex: line three needs to be cust name), the parser should know that <name> </name> tags denote what the customers name is, not which line is falls on. That is just good programming, and if things down the road change with the sort orders, the parser will still work.

XML is only a middle man, so in all actuallity it is up to the two (or more) other programs that interact with the XML output to work around XML.
 
are you using xsd.exe with an xml file to infer what the schema should be?
Then using that schema to generate code?

You could change the xs:sequence to xs:all if you've got control of the parser. Wouldn't help with the output though.
 
are you using xsd.exe with an xml file to infer what the schema should be?
Then using that schema to generate code?

You could change the xs:sequence to xs:all if you've got control of the parser. Wouldn't help with the output though.

Yes, the XSD file is generated by xsd.exe from a model sample xml file which provided by the application (for third party developers like me to use)

So for the second part, no, I don't have control over how the data is parsed, I am only responsible constructing the xml to get passed to the application they way it is expected (elements with specific order).

Anyway, what I end up doing was reconstructing the xml output to another xml. Although I'm still a bit curious why the (strongly typed) dataset doesn't output elements with nested child in the same order as the schema described.
 
Back
Top