Another errata?

[james anderson]

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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)