Re: [xsl] LINQ to XML versus XSLT

Subject: Re: [xsl] LINQ to XML versus XSLT
From: "James A. Robinson" <jim.robinson@xxxxxxxxxxxx>
Date: Fri, 27 Jun 2008 12:30:53 -0700
> There is no need to use extensions in order to chain xslt
> transformations. While with XSLT 1.0 one still needed the
> exslt:node-set() extension function in order to convert the result of
> an xslt transformation to a temporary tree, now this is not necessary
> in XSLT 2.0.

Yes, you are absolutely correct that we could have crafted more of system
in XSLT.  However, the advantage we found in crafting the framework
as a combination of Java and XSLT is that we have yet to find an XSLT
implementation that allows fine grained control over how many threads
get spun up to process N templates.

Consider the scenerio where you have five different stylesheets,
each operating on a representation of the incoming HTTP request, each
responsible for collecting data from some service point and combining
it all into an aggregate document.

Controlling whether one template execution should take priority over
others, or controlling whether one template may be executed but does
not need to finish before the final result document is constructed are
not currently possible (at least as far as I know).

You might wonder why we would want to crafting a system where one
template may or may not complete before we send out the final page.
The answer is that some services might take awhile to respond, and if
we've finished the rest of the page before that response comes back,
we might want to simply annotate the outgoing page with an AJAX callback
which will fetch the final result at some later point in time.

XSLT doesn't currently give that kind of fine grained control.

> Added to that, functional composition and partial application
> (currying) are natural when using FXSL 2.x (which itself is an
> approach implemented in a function library in pure XSLT 2.0 and does
> not require any extension function)

Yes, I've been following your postings on FXSL for a few years now.
It's a really fascinating topic, and I do think it would be beneficial
to explore ways to reduce the complexity of code through the use of
libraries like this.

> Memory consumption can be controlled and minimized by using
> tail-recursion (moderately well supported by Saxon) and by using
> deforestation (fusion) techniques (for now manually, but I hope
> automatic fusion optimization could be offered by the best XSLT
> processors in the nearest future).

Do you know of any work being done in the area of deforestation
algorithms applied to XSLT Templates?


Jim

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
James A. Robinson                       jim.robinson@xxxxxxxxxxxx
Stanford University HighWire Press      http://highwire.stanford.edu/
+1 650 7237294 (Work)                   +1 650 7259335 (Fax)

Current Thread