Re: xmlns in HTML5

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: shane@aptest.com

Received on Friday, 17 July 2009 14:14:42 UTC