W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > June 2009

[Bug 7059] Forking XPath

From: <bugzilla@wiggum.w3.org>
Date: Sat, 27 Jun 2009 23:49:32 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1MKheG-0001eP-CQ@wiggum.w3.org>

--- Comment #11 from Jonathan Robie <jonathan.robie@redhat.com>  2009-06-27 23:49:30 ---
(In reply to comment #10)
> Note also that supporting XPath 2.0 or a new language does not solve the
> problem. The problem is legacy XPath 1.0 expressions applying to legacy HTML
> content. What changed is that legacy HTML content turns into a namespaced tree
> (to make HTML and XHTML more consistent and all sorts of other smallish
> benefits) and so we have to change how XPath 1.0 expressions are evaluated
> because otherwise the legacy content would break.
> Potential solutions:
>  1. Break with XPath 1.0 as proposed.
>  2. Abandon the namespaced tree approach.
>  3. ???
> Since 2 is an explicit design goal 1 seems like the best solution, but I'd be
> interested in hearing about a potential number 3 given that a) we can keep the
> tree namespaced and b) legacy XPath expressions keep working.

I think it would be helpful to get a small group together from your Working
Group and from the XSL and XQuery Working Groups to make sure we understand the
requirements on both sides and look for solutions.

If you are mapping both sets of HTML onto the same namespace, and you want
unprefixed names to match names in that namespace, you can do that in XPath 2.0
by declaring the default element namespace to be that namespace. An
implementation is allowed to set a default element namespace.

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 Saturday, 27 June 2009 23:49:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:00:55 UTC