- From: Ray Whitmer <ray@personallegal.net>
- Date: Mon, 19 Dec 2005 10:33:13 -0700
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: www-dom@w3.org
On Dec 18, 2005, at 1:16 PM, Bjoern Hoehrmann wrote:
>
> Hi,
>
> From http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ it is
> not clear how lookupPrefix and lookupNamespaceURI behave for the
> special
> xml: and xmlns: namespaces. I would expect
>
> lookupNamespaceURI('xml') == 'http://www.w3.org/XML/1998/
> namespace' &&
> lookupNamespaceURI('xmlns') == 'http://www.w3.org/2000/xmlns/' &&
> lookupPrefix('http://www.w3.org/XML/1998/namespace') == 'xml' &&
> lookupPrefix('http://www.w3.org/2000/xmlns/') == 'xmlns'
>
> to hold true for any Node regardless of the actual state of the tree,
> this however does not seem to be required or licensed by the DOM
> Level 3
> Core Recommendation; https://bugzilla.mozilla.org/show_bug.cgi?
> id=246604
> implementers don't care much about that though, so in Mozilla we now
> have the surprising result that lookupNamespaceURI behaves as I would
> expect, but lookupPrefix does not.
I have to agree with you that treatment of xml and xmlns by these
methods seems potentially undesirable.
If I were a user, I would avoid looking up xml or xmlns, but would
just rely on the namespaceURI.
I think the reason these functions are there is for someone trying to
use prefixes in attribute values or element text contents. They
certainly are not needed or useful to manipulate node identities. It
would seem quite wrong to be using xml or xmlns prefixes in content.
I did not read the bug report, but I hope it agrees. I have to agree
that it isn't a significant problem, as I see it.
Ray
Received on Monday, 19 December 2005 17:33:31 UTC