[webkit-dev] XPath Issues?

[Maciej Stachowiak]

On Nov 10, 2010, at 2:54 AM, Alex Milowski wrote:

> 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]).

Do most existing XSLT 1.0 stylesheets have an explicit 1.0 label? Does XSLT require this? How would unlabeled stylesheets be processed?

> 
> 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.

Yeah, I am more interested in how much content would be affected, than whether it is poorly written.

> 
>> 
>> 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.

The informal information I have so far is that none of them want to say "yes" and hope no one else does, because they don't like the complexity or featureset.

(I also gave Alex some contact info for relevant folks at Opera and Mozilla out of band.)

Regards,
Maciej