Re: [xslt] XSLT and Safari

[Mark Vakoc <thevakoc-xml yahoo com>]

--- Dave Hyatt <hyatt apple com> wrote:
> 
> I was planning on walking the DOM myself to find out that information.  
> Our stylesheet loading code already deals with imports and recursion 
> defense and so on.

Seems to me you are causing yourself significant additional work with greater
risk by taking this approach.
> 
> The fundamental issue is (and please correct me if I'm wrong) that 
> libxml/xslt seem to have a sync model of I/O.  They expect the data to 

Right.

> be handed back synchronously, and so everything blocks while the data 
> is read.  In order for us to use this model (and actually override the 
> I/O), we'd have to push all of the libxml parsing and libxslt 
> compilation off onto a separate thread (or do something hideous like 
> push a nested event loop so we didn't block the UI).

That is what I currently do and would recommend it.  I have a very long running
(may be several minutes long) XSLT transformation.  It is contained entirely
with it's own thread.  The user interface is held within a different thread so
that menu items, toolbar buttons, etc. can be functional during the
transformation.  When the long running thread is done it updates the UI and the
user experience is never interrupted.
> 
> Our loading model is asynchronous, so what I wanted to do was simply 
> get everything loaded myself up front so that when libxslt asked for 
> stylesheets I could synchronously hand them back without having to do 
> I/O.

If I understand you are using existing asynchronous services to read the
resources into memory.  Once the documents are all there you then want to run
the transformation, having it return as quickly as possible.  You should
consider the case of a long running XSLT stylesheet.  For legitimate or not so
legit reasons a stylesheet may take a very long time.  If I understand your
approach correctly you will have minimized any user inconvience during parsing
time but not during the actual transofrmation.

> 
> >  And how can you possibly handle the document()
> > function that can have it's arguments dynamically built (and hence no 
> > way to
> > know before transformation) the URI to parse/include?
> >
> 
> We probably would not handle this in an initial release if the 
> transformation expects to block while doing synchronous I/O.
> 

Hmm.. the document() function is part of the XSLT 1.0 spec.  I would state that
a non standards conformant processor is worse than none at all.

If you put the libxml2/libxslt processing into it's own thread for the duration
of it's "work unit" then you need not change as much in libxslt.  Not sure if
this is possible in your situation but has worked very well for me.