W3C home > Mailing lists > Public > public-qt-comments@w3.org > April 2009

[Bug 6777] In HTML documents, no-namespace expression must match http://www.w3.org/1999/xhtml nodes

From: <bugzilla@wiggum.w3.org>
Date: Tue, 07 Apr 2009 15:09:39 +0000
To: public-qt-comments@w3.org
Message-Id: <E1LrCvj-00065W-4N@wiggum.w3.org>

--- Comment #23 from Henri Sivonen <hsivonen@iki.fi>  2009-04-07 15:09:38 ---
(In reply to comment #22)
> So what is being requested is actually an XPath 1.2 specification which is
> XPath 1.0 but with the addition of the default element namespace feature.

Right. I filed this Bugzilla item on the wrong spec. (I was unaware that XPath
2.0 was incompatible with XPath 1.0, so I thought the latest spec would be the
most natural place.)

> One possible route forward would be for the HTML5 spec to do do what Henri
> indicated is not feasible.
> > Requiring the XPath 1.0 processor to be
> > replaced with an XPath 2.0 processor entirely is not a feasible first step.
> HTML5 could (like many specs before it) define a profile/subset of xpath2.

My statement of feasibility wasn't about specs. It was about software. That is,
it's necessary to address this issue in implementations independently of adding
the entire set of XPath 2.0 features.

> (In this case, basically default to BC mode, initialise the default element
> namespace to xhtml, don't allow "for" or  "," operators and restrict the
> function library to those functions that were in xpath 1). Any Xpath 1 engine
> that could not make the small number of changes to support such a profile of
> xpath 2 probably isn't going to change at all anyway so it doesn't matter what
> spec you make for them.

In an implementation that doesn't allow a prefix to be bound to no namespace
(Gecko currently allows this but WebKit and Presto don't), how would the
outcome be black-box distinguishable from the behavior I asked about in comment

| If the document is an HTML document and a name 
| expression is being compared against an element, 
| behave as if "" namespace on the expression side 
| were the "http://www.w3.org/1999/xhtml" namespace.

> I find it ironic that a breaking change in xpath (which would confuse all
> existing xpath users) is being proposed in the name of preserving existing
> content when for example changes such as outlawing the use of
> <?xml-stylesheet href="../style/foo.xsl"
> in Firefox 3.x broke a large fraction of existing pages (when used from
> the local filesystem).

Breaking existing content on the Web for a non-security reason and breaking
content on the local file system for a security reason are totally different

> If it's thought acceptable to force people to rearrange
> the directory structure of their site and all the links in all their pages, why
> is it unacceptable to  admit that you have changed the namespace used in the
> html to XDM mapping, and that people using xpath will need to update to the new
> reality?

The sites still worked when accessed via HTTP, right?

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 Tuesday, 7 April 2009 15:09:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:27 UTC