On Wed, Nov 10, 2010 at 10:29 AM, Maciej Stachowiak <m...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev