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

[Rick Jelliffe <ricko@allette.com.au>]

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.

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.

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.

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.

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.)

So the attributes are a bag not a set.  I think I have pointed out before
that this is one current short-coming ("simplification", Lord spare us) of
XML Schemas: that it does not actually provide any support for generalized
markup in the above sense.  You will notice if you read through the drafts
(I believe this is not the entertainment of the future) that the
<restriction>  element was at first an attribute: it had to be changed to
elements because, not supporting generalized markup, there was no way to get
acceptable strong-typing when an attribute changes the content model.

Cheers
Rick Jelliffe
Cheers
Rick Jelliffe