- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 06 Apr 2009 15:52:24 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6777 --- Comment #16 from Jonathan Robie <jonathan.robie@redhat.com> 2009-04-06 15:52:23 --- (In reply to comment #15) > (In reply to comment #14) > > That > > still wouldn't achieve compatibility of course - the only way to ensure that > > the expression //p[namespace-uri()=''] continues to return the same result that > > it does now is to map your HTML5 DOM to an XDM instance (or the XPath 1.0 > > equivalent) in which the p elements are in no namespace. Since you're so > > concerned about compatibility, I can't see why you are so reluctant to do that. > > That would address the backward-compatibility issue without addressing the > forward-looking point of changing how HTML elements in the DOM are assigned to > a namespace. The point of assigning HTML elements to the > http://www.w3.org/1999/xhtml namespace is to make the data model representation > consistent between the two serializations of HTML (text/html and > application/xhtml+xml). So that in the future, authors can write XPath > expressions with names in the http://www.w3.org/1999/xhtml namespace and those > expressions work on DOMs regardless of whether the DOM came from text/html or > application/xhtml+xml. Name tests do something very simple: the test to see whether the name specified in the name test is the same as the name of a node. If they don't match, the test says they are not the same. I think the tools you have to work with have already been identified - you have control over the mapping to the data model, and you have control over the default element namespace for queries. I don't think redefining XPath to account for the way you are mapping things makes sense. It's a little like redefining the + operator if your accounts don't balance, these are simple, well-defined operators that are universal, and should not be adapted to particular use cases. Jonathan -- 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, 6 April 2009 15:52:33 UTC