Bug 10712 – lookupNamespaceURI for "xml" and "xmlns" does not return the corresponding namespaceURI

• Component: DOM
• Status: RESOLVED DUPLICATE

[Robert Burns]

From the recommendation: (http://www.w3.org/TR/2006/REC-xml-names-20060816/#ns-decl)

"The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace."

"The prefix xmlns is used only to declare namespace bindings and is by definition bound to the namespace name http://www.w3.org/2000/xmlns/. It MUST NOT be declared . Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. Element names MUST NOT have the prefix xmlns."

Some discussion in bug 6638 ( http://bugzilla.opendarwin.org/show_bug.cgi?id=6638) indicated these namespaceURI's should not be returned for the correpsonding reserved prefixes. I cannot find any support for that view in the recommendation and definnitely think those correct values should be returned.

[Alexey Proskuryakov]

Could you please attach a test case demonstrating this issue?

[Robert Burns]

(In reply to comment #1)
> Could you please attach a test case demonstrating this issue?
> 

DOMNode -lookupNamespaceURI:xml  should return "http://www.w3.org/XML/1998/namespace" even when its not declared in the document (it need not be declared). And:

DOMNode -lookupPrefix:@"http://www.w3.org/XML/1998/namespace" should return xml.

Likewise xmlns => "http://www.w3.org/2000/xmlns/" and vice versa.

I believe these DOM3 methods may have been recently added to WebKit because they are not documented in th headers. The discussion I cite in comment http://bugzilla.opendarwin.org/show_bug.cgi?id=6638#c15 seems to indicate that the commenter thinks these values should not be returned. I think they should and cannot imagine what the rationale behind not returning them might be.

I hope that helps clarify the bug.

[Alexey Proskuryakov]

The DOM3 spec is rather unclear on this. The normative section doesn't specify the behavior of lookupNamespaceURI, referring to a non-normative appendix(!). According to this appendix <http://www.w3.org/TR/DOM-Level-3-Core/namespaces-algorithms.html#lookupNamespaceURIAlgo>, WebKit behavior is correct.

However, Mozilla developers have apparently decided that this is a mistake in the spec: <https://bugzilla.mozilla.org/show_bug.cgi?id=246604>, <http://www.nabble.com/DOM3-Core:-Namespaces-Algorithms-vs-xml:-and-xmlns:-t766498.html>.

Confirmed for further nvestigation, added a test case to bug URL (works in current Minefield, but not in Firefox 1.5). Downgrading priority and severity, since no practical consequences have been reported.

[Robert Burns]

As you say the appendix is non-normative. The spec does suggest it is an error xmlns or xml prefixes are assigned to any other namespace URIs. I think it would be hard to read the spec as wanting these prefixes and URIs leftout of the lookup methods.

[Alexey Proskuryakov]

http://www.w3.org/2006/webapi/track/issues/95

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.

[Ahmad Saleem]

From MDN Article:

https://developer.mozilla.org/en-US/docs/Web/API/Node/lookupNamespaceURI

and running the "Example", Safari 15.6 and Chrome Canary 105 match and reports following:

Namespace URL for xlink on <output>: null.
Namespace URL for xml on <output>: null.
Namespace URL for html on <output>: null.
Namespace URL for `` on <output>: http://www.w3.org/1999/xhtml.
Namespace URL for svg on <svg>: null.
Namespace URL for xlink on <svg>: null.
Namespace URL for xml on <svg>: null.

While Firefox Nightly 104 reports following:

Namespace URL for xlink on <output>: null.
Namespace URL for xml on <output>: http://www.w3.org/XML/1998/namespace.
Namespace URL for html on <output>: null.
Namespace URL for `` on <output>: null.
Namespace URL for svg on <svg>: null.
Namespace URL for xlink on <svg>: null.
Namespace URL for xml on <svg>: http://www.w3.org/XML/1998/namespace.

I am not sure, what is latest spec and whether Safari need to follow Firefox or vice versa. Just wanted to share updated details. Thanks!

[Chris Dumez]

*** This bug has been marked as a duplicate of bug 252716 ***