W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2000

Re: namespace treatment, 2nd attempt

From: <keshlam@us.ibm.com>
Date: Thu, 9 Mar 2000 08:53:57 -0500
cc: "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <8525689D.004C55F3.00@D51MTA03.pok.ibm.com>
Quoth Dieter:

> For Attributes set by the non-namespace method the namespaceURI is
> supposed to be an empty string or null, and if the Attribute's name is
> namespace conform it shall be treated as if it were set by the
> namespace method, e.g. setAttribute('a:b') would have the same result
> than setAttributeNS('','a:b'), what means that the prefix is 'a' and
> localName is 'b'.

The DOM Working Group did consider this alternative, but after debating it
the vote was that prefix and localname are not defined for non-namespaced
nodes and should not be provided. I'm not really delighted with that
decision -- it means that code may have to do an "if localname non-null use
that, otherwise use node name" test -- but I think I can live with it.

>Changing the prefix shall be
>allowed whenever the current nodeName is a qualified name

I think that one's definitely wrong. The only reason we permit changing the
prefix on a namespaced name is that it "isn't really part of the node's
name" -- in the namespace world, the "real" name is the combination of
namespace URI and localname. For a non-namespaced node, the prefix is an
essential part of the node's identity and really should not be mutable.

As one practical illustration of why: Consider something like the HTML DOM,
where different subclasses of element were selected based on the namespaced
name. If you allow folks to change the prefix -- from postal:address to
memory:address -- you may wind up with something that claims to be a
memory:address but supports getZipCode() instead of getBytes().

>(if those would not convince anybody I must be
>quiet for the next month for not to become the reputation of a great
>namespace troublemaker :-)

Don't worry about it. You're asking exactly the same kinds of questions
that were most difficult for us during the design process, you're
explaining your concerns clearly, and you're suggesting fairly reasonable
alternatives. We may or may not not agree that the alternatives are better,
but having someone read and think about the spec this carefully is very

If nothing else, it suggests that we may want to document the rationalle
behind the namespace design.

Joe Kesselman  / IBM Research
Received on Thursday, 9 March 2000 08:54:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:06 UTC