Re: Another errata?
Up until the remark quoted below appeared, I had taken the namespace spec 'with grain of salt', and simply presumed matters would clear up eventually. If matters continue in this direction, however, there is a Ronald Bourret wrote: > > Tim Bray wrote: > > > I repeat: in the sense the spec uses the word namespace, an unprefixed > > attribute is NOT IN ANY NAMESPACE. > > I'm happy to live with this interpretation -- it's just that it comes as a > complete surprise to me (and apparently to others as well). In this > respect, how anybody can read A.2 and determine that prefixed attributes > belong to a namespace and unprefixed attributes do not belong to a > namespace is beyond me. While I could live with the assertion, I would, unfortunately, be unable to write useful software which conformed to it. If an "unprefixed attribute name" is really not in any namespace, then it would be impossible for application code to execute an affirmative comparison against the name, and it would be, for similar reasons, impossible to write xsl patterns which addressed the attribute. Are these consequences really intended? I would be very surprised if they were. An unqualified attribute name may be in a namespace with a unique structure, or in one which has a unique name form, but it should be in some namespace. Otherwise it's not possible to refer to an identifier more than once. I suggest that one take the spec at its word and propose that qualified attribute names are in exactly the namespace which the spec describes, that is, a namespace which has a two part name: the element identifier's uri and the element identifier's local part. This is straight forward. I can even imaging why one might want to do it. One alternative, that they are in the so-called "null" namespace, would be workable, but it contradicts much of the exposition in the spec. (see below for a qualification to this). Another alternative, that they are not in any namespace, means that a name cannot be repeated, which has very limited utility for something intended to be an encoding mechanism. > > One very important consequence of this interpretation is that > namespace-aware applications need to be sure they don't look for > namespace-prefixed local attribute names and namespace-aware SAX and DOM > implementations need to be careful that the namespace name passed for local > attributes is null. Since we've gotten this far, we should also be clear that a namespace with a null name is not identical to a null namespace. The "grain of salt" referred to above, is that I had been presuming that the spec meant the former where the latter appears. Perhaps someone can suggest another interpreation which makes sense. > ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format