- From: <bugzilla@jessica.w3.org>
- Date: Mon, 04 Oct 2010 01:38:52 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10692 --- 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: xmlns:foo="http://example.org/bar#" 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