On Jun 29, 2011, at 7:14 AM, Alex Milowski wrote: > On Tue, Jun 28, 2011 at 10:10 PM, Dirk Schulze <k...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
