[webkit-dev] Writing a new XML parser with no external libraries

[Maciej Stachowiak]

On Jun 29, 2011, at 7:14 AM, Alex Milowski wrote:

> On Tue, Jun 28, 2011 at 10:10 PM, Dirk Schulze <krit at webkit.org> wrote:
>> 
>> Am 29.06.2011 um 05:42 schrieb TAMURA, Kent:
>> 
>>> I'm a little negative of developing a new XML parser. I'm afraid that the new parser introduces a lot of security/stability problems which existing parsers already resolved.
>> 
>> I feel the same. Writing a new parser from scratch means introducing a lot of new security bugs, parsing errors and maybe bigger performance lost at the beginning. Speaking from the SVG side, we fail at least three tests on the W3C SVG Test Suite because of parsing bugs if libxml2 on MacOS. All of these bugs are fixed in later versions of libxml2. Updating libxml2 more often on MacOS would help a lot.
>> 
>> With the new parser we won't loose support XSLT and XLink support?
> 
> If we write our own XML parser, we'd still have to use libxml2 via the
> libxslt in the short term.  libxslt uses its own internal data
> structures for XML documents and does not have a way to interface our
> DOM implementation.  As such, you load documents via the libxslt's API
> for it to use.  There are several XSLT bugs the relate to
> serialization of the XML and error reporting due to this usage.
> 
> That does mean that we'd have one XML parser for loading documents
> (e.g. XHTML) and XMLHttpRequest and then another one for when we run
> XSLT.
> 
> There are other choices for XSLT engines.  XQuilla [1] has an almost
> complete XSLT 2 implementation with an API that allows bootstrapping
> both the DOM and parser usage.  I've been chatting with one of the
> developers about their API and integration issues with WebKit but I
> haven't actually tried to integrate it yet.
> 
> Another option is to use a javascript-based XSLT engine.  I recently
> saw some exceedingly impressive demonstrations of cross-compiled XSLT
> processors interacting with the browser at XML Prague [2].
> Personally, I like the idea of a javascript-based XSLT engine but that
> would be a departure from a native implementation and I wonder how
> that would work on all our supported platforms.

We could also write a new native XSLT engine down the line, since we have our own XPath code already. This would let us fix a lot of oddities and hacks with the way our libxslt-based XSLT support works.

Regards,
Maciej