[webkit-dev] XPath Issues?

[Maciej Stachowiak]

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.

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.

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.

Regards,
Maciej

On Nov 10, 2010, at 1:53 AM, Alex Milowski wrote:

> On Tue, Nov 9, 2010 at 8:00 PM, Eric Seidel <eric at webkit.org> wrote:
>> This conversation is heading in a dangerous direction... :)
>> 
>> Allowing QXML parser support to be added to WebKit was probably a
>> mistake.  Adding custom QXPath or QXSLT support would be another.
>> 
>> WebKit is one platform.  If XSLT or XPath 2.0 is good for the web, we
>> should add them to all ports, just like we did XPath 1.x.  The only
>> reason XMLDocumentParserQt hasn't been a bigger compatibility problem
>> (or source of crashes, security bugs, etc.) for the Qt Port is that
>> XML is used so very very very little on the web (and it's relatively
>> simple to parse).  (The XMLDocumentParserQt was a huge headache for
>> Adam and I when trying to re-factor DocumentParser for HTML5, for
>> example.  I'm sure we introduced still-present bugs in it.)
>> 
> 
> Implementing XSLT 2.0 or just XPath 2.0 is a huge engineering effort.
> Like many other things, we should rely on an existing implementation
> if possible that can be used on the various platforms.  I'd rather see
> a general solution where you can "turn on 2.0 support" and swap out
> the current use of libxslt.
> 
> XSLT 2.0 is continuously asked about by those people who use XSLT in
> the browser.  There are so many things that just work better or
> features that are now standard.  It would be a real win to have such
> support that also runs efficiently within the context of transforming
> XML.
> 
> Most of the implementations that I've looked at would also solve a
> number of issues with the current integration of libxslt as they
> wouldn't require serialization of the document to transform an exist
> XML DOM (e.g. transforming a node via javascript).
> 
> The question is which one?
> 
> I'm leaning towards xquilla as a choice but their XSLT 2.0
> implementation isn't quite finished.  The API is relatively clean and
> their implementation is active.  It would also provide the ability to
> use XPath 2.0 and XQuery (although there is no API for that as of
> yet).
> 
> The technical issue with xquilla is that their API uses XMemory,
> MemoryManager and few other low-level base classes for certains
> aspects like memory management, strings, etc.  This would have to be
> resolved (or accepted) so that it would integrate well with WebKit.
> 
> I suspect this sounds like a radical departure to many of you out
> there.  In the case of things like libxslt, we expect it to be
> available on the platform or development environment so that it can be
> linked into WebKit somehow.  We'd now add another such dependency for
> a new library that you might have to compile somehow.
> 
> Thoughts on that?
> 
> Also, keep in mind that I'm still trying to figure out which
> implementation would be the best choice given the architecture and API
> design of WebKit.
> 
> -- 
> --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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev