[webkit-dev] XPath Issues?

Eric Seidel eric at webkit.org
Tue Nov 9 12:00:41 PST 2010

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

Please excuse me if I mis-understood your suggestions of "integrating"
these Qt features with WebKit.


On Tue, Nov 9, 2010 at 1:46 AM, Alex Milowski <alex at milowski.org> wrote:
> On Mon, Nov 8, 2010 at 7:09 PM, Frans Englich <fenglich at fastmail.fm> wrote:
>> As far as I know, no, but I'm busy with studies these days. I guess one of the first questions is rather how the two stacks, Qt and Webkit, should relate to each other on this particular field, what the aim of the integration is and the nature of the integration, as well as dependencies. But it seems interesting to have these technologies in Webkit. What's your thoughts on how it would be carried be done?
> I think the simplest answer is for one to be able to "turn on Qt XML
> support" without having to use the whole Qt port.  In my research into
> how all this is put together, the XPath and XSLT support within the
> browser is separable.  Any library could be integrated by simply
> adding a build option to do so.
> I've been looking at XQuilla in this same way.  They have an XPath
> 2.0, XQuery, and XSLT 2.0 implementation that looks to be very easy to
> integrate.  The only is that they rely on some internals from Xerces-C
> that seem rather superfluous.  That is, you don't have to use the
> Xerces-C parser to use their system.
> Any implementation of XSLT or XPath needs to be able to use the XML
> DOM directly in some way.  This would avoid any kind of strange
> serialization (which is what happens when XSLT is called from
> Javascript with libxslt) that currently causes bugs.  In addition, the
> XPath implementation can't really serialize and expect to get the
> context node correct.
>> (I wrote the XPath, XQuery and XSL-T code and mentored the Schema code. However, I'm no longer employed by Nokia.)
> That's good to know!
> Have the compliance tests for XSLT 2.0 and XQuery been run?
> --
> --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

More information about the webkit-dev mailing list