Cart
[Home] [By Thread] [By Date] [Recent Entries]
Eric van der Vlist wrote: >>If we don't >>enforce order at validation time, then we must have a more general >>processing loop that can accept any element at any time. If we do >>enforce order, then the processing stage can be simpler: accept a "foo" >>if there is one, accept a "bar", accept a "baz", etc. etc. In streaming >>applications, a well-chosen order of children (viz. no forward references) >>can make processing much more straightforward. >> >> > >I think that the additional complexity is overstated. SAX is my favorite >XML API and I find it much more robust (and only slightly more complex) >to never rely on the relative order of children elements. In the >frequent case where I want to build an object out of an element, I use >to create the object and assign the properties given as attributes on a >start element, assign properties independently for each child element >and do final tests and operations on end element. I really don't see the >additional complexity... > This is more a reflection of the limitations of SAX than a general rule. SAX forces you to maintain state in order to check sequences, so with SAX it's actually easier in many cases to work with unordered elements. If you instead use a pull parser you can make use of the element ordering directly in your code and avoid a lot of unnecessary overhead and complexity. So does that matter to you, if you're not currently using a pull parser? Only in that you may want to switch to that approach in the future, or other developers working with your documents may want to do so. Personally I find element ordering useful in most applications. Using ordering makes it easier for me to look at documents (such as configuration files) and find a particular item of information. Of course, I could always use XPath or such to search the document and find what I'm looking for, but why add unnecessary complexity? - Dennis
|
