[webkit-dev] XPath Issues?

[Alex Milowski]

On Wed, Nov 10, 2010 at 10:29 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> The first thing we should figure out is whether XSLT 2.0 is something we even want to implement. If it's not backwards compatible with XSLT 1.0 and other browsers are not planning on implementing it, then it's a significant risk to move to XSLT 2.0. We'd likely break backwards compatibility with Web content, and end up long-term incompatible with other browsers. That's not very well aligned with the goals of the project. Breaking backwards compatibility is generally considered unacceptable, unless we can convincingly show it won't affect real-world content.

XSLT 2.0 provides what it calls "backwards compatibility mode".  When
an XSLT 2.0 processor encounters a transformation labeled with a
version of "1.0", it can run that transform in the backwards
compatibility mode.  There are very minor differences but I highly
doubt they would "break" existing uses (see [1]).

For example, XPath 2.0 has the concept of sequences rather than "node
sets" and within certain context, the string value will be space
separated rather than the string value of the first node.  If someone
wrote a stylesheet assuming (or more likely accidentally using) that
fact, with an XSLT 2.0 processor, the string value in the result would
be from all the nodes.  The output would essentially be slightly
different.

One could argue that was a "poorly written stylesheet" and it would be
very easy to fix so that it had consistent behavior in XSLT 1.0 and
2.0 stylesheets.

I need to look/ask around and see if I can quantify the scope of these
incompatibilities in live stylesheets used on the web to help answer
this question.

>
> If, in addition, XSLT 2.0 requires a major engineering effort and/or a large external dependency, then this would not be a cheap experiment. Now, we could add it under a new API, but then we'd be stuck carrying around two versions of XSLT forever, and Web content might not be able to reliably use the new version in any case.
>

I guess I was thinking, to begin with, that this would be a
compile-time feature that you could turn on.  That's not a cheap
experiment but, to begin with, I'm really talking about *my* time to
implement such an integration.  I have uses for such things and I just
want to do it in such a way that the work would be an acceptable
implementation if vendors choose to switch to 2.0.

> What we'd normally do in a situation like this is check with other implementors whether they are prepared to implement the new technology. I would recommend starting there, before we talk implementation strategy.
>

I'd be curious about that too.  For those that use XSLT in the
browser, "better" (e.g. more reliable, consistent, and "modern")
support for XSLT would be very, very welcome.

It is a long road to getting XSLT and XPath 2.0 support into *all* the
major browsers.  It has to start somewhere and a standoff of browser
vendors, each looking at each other, waiting for each other to say
"yes" first is where I believe we are right now.  Possibly some are
hoping that no one will say "yes" and the status quo will reign.

[1] http://www.w3.org/TR/xslt20/#backwards-compatibility-behavior

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics