[
Lists Home |
Date Index |
Thread Index
]
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
|
