[webkit-dev] XPath Issues?

[Alex Milowski]

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