Re: attribute order (RE: Syntax Sugar and XML information models)

["Simon St.Laurent" <simonstl@simonstl.com>]

At 01:17 PM 3/30/01 +0800, Rick Jelliffe wrote:
>From: Simon St.Laurent <simonstl@simonstl.com>
>
> >I'm not really sure what good it does to specify that order is discarded
> >entirely, though at least I suspect it does less harm than claiming that
> >all namespace prefix information should be discarded entirely.
>
>Because then some company or renegade would doubtless use it for
>embrace-and- extend in some  unimaginable way.


Huh?  The order of elements is preserved, and I haven't seen much 
embrace-and-extend that I would consider harmful...


>At the moment it is clear that attribute order is not something that anyone
>should used in decisions on processing attributes or elements, and no-one
>seriously doubts that or does any different.

"Because no one has questioned the imposition of a processing model on the 
syntax previously, we shouldn't take this question seriously."  Okay.

>Changing this would be a classic embrace-and-extend manouver: we would be
>able to produce conforming XML which had some kind of information that other
>systems could not detect. For example, if some scary and enormous
>corporation with such a bad track record no-one can believe a word it says
>anymore or its leading competitor decided that
>   <pants husband="jim" wife="jean" />
>and
>   <pants wife="jean" husband="jim" />
>meant that the first attribute indicated who wore the pants, then current
>DOM based systems (or XPath based systems) would not see any difference.

Is that a problem with those applications, or is that a problem with the 
original processing model?  By losing the ordering information, the model 
leaves itself open to embrace-and-extend in a manner which would not have 
been an issue had the ordering information been preserved.

>Now, this is not to say that a system could not, for process-internal an
>non-exported data, order the attributes as a way to implement some useful
>function (e.g. c14n testing, or that the first position in the attribute
>array is the ID if any exists to allow fixed-index lookups, or that invalid
>attributes go to the end, or that attributs are ordered by namespace to
>allow searching, etc.) but that is very different from the order being
>significant at the infoset level.

In case it isn't obvious, I rather seriously doubt how useful the infoset 
is at this point.  I'm more or less suggesting that the imposition of 
infoset understandings on the syntax is shutting off some useful 
possbilities while leaving other complexities unanswered.

>I would say there is another reason why attributes should be unordered.
>Goldfarb's SGML Handbook has a potted history.  The difference between the
>70s style gencoding and the 80s innovation of generalized markup is the
>introduction of attributes to subclass the element: the genus of the element
>is specified in the "generic identifier" and the species is identified
>through the use of attributes. (Attribute syntax being available, they are
>then appropriate for IDs and IDREFs and other links too, but these are not
>"generalized markup" per se, it seems.)

Does that history mean that attributes should/must always be treated as 
unordered?

There's reuse and there's adaptive reuse.


Simon St.Laurent - Associate Editor, O'Reilly and Associates
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books