[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

  • From: Rick Jelliffe <ricko@a...>
  • To: xml-dev@l...
  • Date: Fri, 30 Mar 2001 13:17:45 +0800

dom attribute order
From: Simon St.Laurent <simonstl@s...>

>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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.