Re: [xslt] XSLT and Safari

[Mark Vakoc <thevakoc-xml yahoo com>]

> With a sync I/O approach, you lose all ability to parallelize loads.  
> If one sheet wants to import three other sheets (A, B, and C), then 
> libxslt's model will force you to load A, then load B, and then load C. 
>   My model will allow me to kick off all three loads at once.  This 
> seems clearly better to me.  If B loads first and wants to import two 
> more sheets (D and E), I could get those loads kicked off even before A 
> or C had finished, etc.

True.  A saving grace is that I think that XSLT in general is less likely to
have as many external includes as  HTML, where you may have many externals such
as IMGs, CSSes, etc.  And HTML benefits more from asynchronous behavior because
you can progressively display the output, whereas XSLT needs all the stylesheet
loaded and compiled before you can do anything with it.  You also get the
entire result at once (there is no progressive streaming of the XSLT output,
you only get a DOM like tree.

The order of imported doucments in XSLT is significant, so even if they are
parsed asynchronously the compilation of the stylesheet would have to be
synchronous, in the order they are identified, so you lose asynchronous benefit
there.

> 
> Yeah, it might be reasonable to push the transformation itself onto a 
> separate thread, although the problem is that other browsers have JS 
> APIs that are synchronous, and so we'll have to have that as well.  
> Since client JS in a Web page runs on the UI thread (this is true in 
> both Mozilla and Safari), you'll block the UI anyway.  If you don't, 
> you end up becoming re-entrant, since you could then trigger UI events 
> on your DOM and execute more JS.

I think that is less significant as again you get the entire result in one
block and a 'node at a time', if I understand what you are saying here.

> Yeah, while I'd like to do parallel loading of the stylesheet 
> resources, it definitely seems smart to do the transform on its own 
> thread, although we'd have to invent our own DOM API for asynchronous 
> transformations, but maybe I could get Mozilla to buy off on that idea.
> 

Not entirely sure what you mean here.  You get the entire result as a libxml2
DOM like tree, so if you are sending those results into an existing DOM
document you are still inserting DOM objects as translated from the libxml2
result into whatever DOM implementation you are using.  of course I am
assumming you don't use libxml2 in Safari to manage the document tree, but I
could be wrong.