[
Lists Home |
Date Index |
Thread Index
]
elharo@metalab.unc.edu (Elliotte Rusty Harold) writes:
>What contexts? How would having attribute order preserved help you?
>Even in the context of an XML editor I can't say that preserving
>attribute order is all that important. People get upset when editors
>screw with their entities. I don't remember anyone getting too peeved
>because an editor shuffled their attributes.
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.)
Early editors (and some current ones still) tended to mash the entire
structure into their notion of what HTML should look like, but better
editors at least preserved element structure. Attribute order may seem
like a minor part of this, but it matters a lot more as the number of
attributes increases.
The use of 'identity transforms' in XSLT is a problem for just this
reason for these kinds of developers, as attribute order isn't counted
as part of the document identity.
>What would preserving attribute order let you do that you can't do
>now? What concrete use cases can you present for this functionality?
I see it as a substantial improvement for cases where humans are
expected to interact with the markup at any point during the lifecycle
of the markup. It lets humans group information in a way which makes
sense to them, and this matters more as the number of attributes
increases.
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.
(It drove me to an XSLT stylesheet which turned all the attributes into
elements with a SPECIFIC ORDER I CHOSE. That is a less tenable option
as documents grow more complex, unfortunately.)
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.
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.
Of course, the value of namespace declarations and the mechanism by
which they are represented is a debatable issue in the best of
circumstance.
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.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
