[Bug 10692] Fix coercion to Infoset for HTML5 to correctly preserve xmlns attributes


--- Comment #6 from Manu Sporny <msporny@digitalbazaar.com> 2010-10-04 01:38:51 UTC ---
(In reply to comment #2)
> I think requesting that HTML5 be "fix[ed]" mischaracterizes the problem. It
> *might* be that the HTML5 side needs *changing* in order to paper over the
> problem RDF-in-XHTML TF caused by using the xmlns syntax while fully intending
> RDFa to be deployed in text/html.

The problem exists whether or not RDFa is there. So, let's assume that RDFa
does not exist. There are going to be plenty of people that are publishing
text/html that includes SVG, MathML, XHTML declarations and other intranet
applications that utilize xmlns:. When these documents are converted to an
Infoset, it would be nice if the xmlns information was not mis-characterized
upon conversion.

> When xmlns="foo" is parsed on an HTML element in text/html, it is an attribute
> with local name xmlns in no namespace. Mapping this into a namespace
> declaration would substantially alter the nature of the attribute in the
> infoset, so while such mapping might be desirable from the RDFa point of view,
> it clearly wouldn't be a "fix" or be "correct" from the point of view of
> retaining the meaning of the DOM as converted into an Infoset.

The proposal states that the exact same thing that happens now would happen
when the proposal is applied. That is, the behavior you describe above would be
preserved - an attribute with a local name "xmlns" in no namespace with a value
of "foo" would appear in the Infoset.

To give a more in-depth example, if the following attribute was provided:


There would be two attributes created in the converted Infoset:

(NULL_NAMESPACE, "xmlns:foo", "http://example.org/bar#") AND
(http://www.w3.org/2000/xmlns/, "foo", "http://example.org/bar#")

All old code would continue to operate, /and/ the xmlns: declarations would be
carried into the Infoset in a loss-less way.

If this is not performed, the library that is searching for that term still has
to find it and would look in NULL_NAMESPACE to search all of the "xmlns:*"
patterns. That is, two code paths would have to be created for Infoset
applications that want to find xmlns: attributes.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 4 October 2010 01:38:53 UTC