Henri Sivonen wrote:
What you say is true for all practical purposes when talking about
"the DOM" in browsers. It's not necessarily true in practice and per
spec for all kinds of things called "the DOM".
Okay. How about per the HTML5 spec? If it is not, then we would like
it to be. To whom do we send that comment?
The public DOM API is required to throw when setting an attribute
whose namespace is null and whose local name is "xmlns:foo":
NAMESPACE_ERR: Raised if the qualifiedName is malformed per the
Namespaces in XML specification, if the qualifiedName has a prefix
and the namespaceURI is null, if the qualifiedName has a
prefix that is "xml" and the namespaceURI is different from
"http://www.w3.org/XML/1998/namespace";, if the qualifiedName or its
prefix is "xmlns" and the namespaceURI is different from
"http://www.w3.org/2000/xmlns/";, or if the namespaceURI is
"http://www.w3.org/2000/xmlns/"; and neither the qualifiedName nor its
prefix is "xmlns".
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-ElSetAttrNS
Huh? in what way does the attribute xmlns:foo="someURI" violate the
constraints that would cause NAMESPACE_ERR to be thrown when calling
createAttribute in the DOM? I mean, I agree there is such an exception,
but so what? We are declaring an attribute and a value for that
attribute. It is not malformed per the Namespaces in XML specification,
the namespaceURI is not null, etc. Or are you claiming that in HTML5
the namespaceURI for the prefix "xmlns" is somehow different than what
is required by the XML Namespaces Recommendation?
Therefore, to comply with the HTML 5 parsing spec, the parser needs a
back door to the DOM. For example, if you set the html5.enable pref to
true in a recent nightly build of Firefox trunk, you get a parser that
uses such a back door.
I don't follow this, sorry.
The Validator.nu HTML Parser exposes the Java DOM API outside
browsers. It builds the tree using the public API, because it uses the
JDK/JAXP DOM implementation and the JDK/JAXP doesn't specify a back door.
But why do I need such a back door? I am parsing the document... the
document will create a DOM. The DOM will have the contents of the
document in it, including its elements and attributes. Yay?
To address situations like this, HTML 5 licenses the parser to drop
those attributes, which is what the Validator.nu HTML Parser does by
default when used with the JAXP DOM:
If the XML API doesn't support attributes in no namespace that are
named "xmlns", attributes whose names start with "xmlns:", or
attributes in the XMLNS namespace, then the tool may drop such
attributes.
Yes, I have read this text. But since HTML5 requires normatively XML
Namespace support, the XML API must, perforce, support attributes whose
names start with "xmlns" and MUST support them in the XMLNS namespace.
I conclude that this constraint is never applicable. Can you describe
the chain of events that would make the constraint applicable using the
example above? More importantly, how do we remove this constraint from
the spec. It appears to be spurious.
http://www.whatwg.org/specs/web-apps/current-work/#coercing-an-html-dom-into-an-infoset
For server-side use, it seems unwise to rely on things that need to be
mangled in order to make off-the-shelf XML tree implementations not
throw.
Why do you think an off-the-shelf XML parser would throw an exception
when it encounters a namespace declaration? Surely that would be a
surprise to most of our loyal viewers.
--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: sh...@aptest.com
