[
Lists Home |
Date Index |
Thread Index
]
At 5:20 PM -0400 6/22/03, Simon St.Laurent wrote:
>I remember a lot of HTML developers who have been thoroughly aggravated
>by tools which have a habit of screwing up attribute order. Developers
>who are used to grouping attributes by function, or who used whitespace
>inside of tags to improve readability, might send something to a
>non-developer, who'd make "improvements" with an HTML editor, and the
>resulting botch was less than pleasant. (Alphabetized attribute names
>still come up once in a while as an odd result of processing.)
Source code level editors are a very special case. They really need a
special purpose API. SAX, DOM, JDOM, etc. are not adequate for their
needs. Attribute order is really the least of the problems here.
However, baking the needs of an editor into a generic processing API
would vastly complicate the APIs. It would make them much less
suitable for all other uses. I still see no reason for relying on
attribute order when it comes to the information content of an XML
document.
>For a non-HTML example, I think we're all familiar with XML documents
>representing relational tables where the creator of the document
>represented the values as attributes. If another process makes changes
>to some values in some rows with a filter and the document is
>re-serialized, there are often side effects. Suddenly, the sequence of
>attributes can vary among the elements. It may not matter to the
>computer consuming it, but it does make debugging more interesting than
>it should be.
I don't see why this is any problem at all. Can you be more specific?
>I also see it as order as important to processing which works on XML
>documents as a stream of characters, processing attributes as they
>appear in the start tag rather than as a set, though the actual
>throughput improvements in those cases are pretty minimal.
This is completely possible now. There is nothing in the spec that
says a processor cannot stream attributes to the client application
in the order they appear. There is nothing that says the processor
must shuffle the attributes. It just says that client applications
cannot rely on processors reporting attributes in any particular
order.
>One specific case where attribute ordering mattering might have been
>especially useful is in namespace declarations. It's already the case
>that the entire start tag has to be processed before you know what
>namespace the element is in, but the same issues apply to attributes.
>Stating that the namespace declaration which applies to the element must
>appear first and that all namespace declarations must appear before
>other other attributes might at least make it easier for both humans and
>computers to sort out what they're looking for with a lot less hunting
>around.
You're stretching here. This is just not a problem in practice. In
fact, adding a requirement like this would make it harder for humans
to author XML documents because there'd be one more unobvious rule
they'd need to learn and follow. The status quo is simpler than what
you propose.
>Finally, I'd like to note that namespace prefixes were considered
>throwaway for a while as well, practice sanctioned by specification, but
>over time I think we've learned the value of keeping the original prefix
>information around.
I disagree. I think we've learned that due to some poor choices made
in the early days with XSLT and XPath and now schemas, we need to
keep the prefixes around. However, this is recognized as a flaw in
those applications, not as a good thing in and of itself. More modern
applications like RELAX NG are designed so that it's no longer
necessary to keep the prefixes around.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Processing XML with Java (Addison-Wesley, 2002)
http://www.cafeconleche.org/books/xmljava
http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA
|
