Question

I’m trying to understand ReST and XML a little more – A third party company has asked if we’re ok with their service accepting requesting xml elements in a specific order. This causes a problem for us as we are using objects that have an inheritance hierarchy (so can’t use etc as .Net serializes objects recursively).

I know I can use the IXmlSerializable Interface (much more work for us) to control serialization, or create individual objects for each request (not very elegant). But wanted to avoid changing anything we already have as it is very maintainable at the moment.

I wondered what possible reasons there are for requiring XML elements in a specific order, (it seems a bit of a bad design decision), and any reasons why not to order xml elements explicitly (other than the obvious point of reducing maintainability when they want to add an element).

Answer 1

A typical reason for requiring XML elements in order is that whatever is processing the XML is maintaining state while it’s doing so. It’s getting information from the foo element that is then used when processing the bar element, and so on.

You might say, “well, then process the foo element first, and then process the bar element, and don’t rely on the document order.” Which is all well and good if the process deserializes the stream of XML before you process it. But if the receiving process is using an XmlReader, or SAX, it’s combining parsing and processing into a single step, most commonly to maximize performance and minimize memory usage.