libxml2, libxslt in mozilla2.0?

Axel Hecht axel at
Wed, 25 Aug 2004 20:19:55 +0200

As a peer of our XSLT engine, I bet I should comment.

Briefly, as my head is full with other stuff.

There are three fields of concern:

One is the infamous d-o-e and document.write. I get nightmares each time 
I think about what can be done with this. Anyway, there are people that 
expect this to work, and there is even a use case, which is RSS feeds. 
Of course, those only work within html output, don't try to think about 
using d-o-e in xml output. (Worded too strongly, sure, but I'm hungry, 
and I don't have time to reply this week at other times.)

The other is the host of work you do for serializing and parsing. If you 
do it right (tx doesn't yet), you can get from parsing to content 
creation thru atoms and nsids. Considering how expensive our html parser 
is alone, this is worth noting. I'm afraid tx is still a bit apart from 
being able to see this, though.

A third part is the integration into the content model. I did think 
about this every now and then, but I haven't come up with a descent 

Oh, I wonder how many sites out there rely on MS using the html parser 
whatever they do. We do see bugs that rely on crappy default namespace 
bugs, for example. So if we serialized right, we'd still be breaking 
alot of sites that are broken right now.

I'm honestly not convinced either way. Numbers could convince me, if I 
wouldn't know that tx isn't at the limits of its performance. A good 
design/patch for the hookup, maybe too.


David Hyatt wrote:
> I don't believe any of Mozilla's current limitations regarding XSLT are 
> technical.  In the case of XSLT, I think a deliberate design decision 
> was made that causes most of the WinIE incompatibilities.  One could 
> rectify that (IMO) design mistake without abandoning Transformiix.
> Basically Mozilla's path when transforming is to go directly from source 
> DOM to result DOM.  What I did in Safari is go from source libxml DOM to 
> result libxml DOM to serialized stream, which then gets fed to the 
> parser and built into a KHTML DOM.  This is important for features like 
> document.write, proper loading of subresources, and 
> disable-output-escaping.
> It's also nice too to not have to be in the business of maintaining XSLT 
> support.
> As for libxml, I can't say enough good things about it.  DTD loading 
> hooks, better error reporting hooks, built in namespace support, and so on.
> dave
> On Aug 24, 2004, at 5:30 PM, Brendan Eich wrote:
>> For XForms, it sounds like bryner is gonna use libxml2 for schemas.  
>> We could use relax-ng or schemas for developer tools to check XUL, for 
>> sure (Bob Clary has written a XUL 1.0 Relax-NG schema).
>> So if by next year XForms, an optional Gecko extension, depends on 
>> libxml2, what would we lose by switching from expat and transformiix 
>> to libxml2 and libxslt?  We'd gain the ability to load DTDs and other 
>> stuff from separate URIs, which we now lack.  Hyatt says good things, 
>> and shaver and vlad vouch for DV (libxml2's author).  Reactions?
>> /be