Re: [xsl] LINQ to XML versus XSLT

Subject: Re: [xsl] LINQ to XML versus XSLT
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Fri, 27 Jun 2008 11:00:20 -0700
> I agree.  At HighWire Press we've been working on just that for our
> new architecture.  We've built up a series of systems which are being
> driven by tools like Saxon and MarkLogic, with a large chunk of Java
> acting as glue (e.g., allowing us to more easily chain together sets of
> stylesheets to run multiple transformations in a single pass w/o having
> to use special XSLT extensions).
>

It is exciting to know that the true power of XSLT is being used
adequately serverside at large production environments.

I have only the following specific comments:

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.

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)

> We are seeing many benefits from this approach, but there are some serious
> downsides as well -- memory and CPU consumption are a big concern,
> and we have to keep a careful eye on how new services affect the load
> on the servers.
>

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).

High CPU utilization can (again manually for now) be treated by using
the advantages of multiple-core architectures. Functional programming,
due to the lack of side effects is much better suited (easier) for
parallel evaluation than imperative programming.

Any f:map() application or any DVC (divide and conquer) implementation
can be evaluated in parallel -- even by manually starting several
threads of transformations and combining their results.

Lazy evaluation (supported by Saxon), can also significantly decrease
the actual CPU time and memory required to perform a transformation.

Last, but not least, a functional program, due to the lack of side
effects, typically can be optimized more extensively and to a much
greater extent than an equivalent imperative program. The results of
such more extensive optimization naturally translate to achieving
better performance.



--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play



On Fri, Jun 27, 2008 at 9:12 AM, James A. Robinson
<jim.robinson@xxxxxxxxxxxx> wrote:
>
> > Well I would use Saxon with Glassfish or Tomcat... but I guess you
> > have Saxon.net so it is possible with IIS.   Either way implementing
> > it yourself is easy.
> >
> > With SOA being the big thing at the moment, XSLT is easily one of the
> > best placed languages to combine those services into XHTML... the way
> > I see it, XSLT 2.0 is _the_ serverside language of the future...
> > Reading and writing XML and inbuilt XML types will just be redundant
> > in an end-to-end XML stack.
>
> I agree.  At HighWire Press we've been working on just that for our
> new architecture.  We've built up a series of systems which are being
> driven by tools like Saxon and MarkLogic, with a large chunk of Java
> acting as glue (e.g., allowing us to more easily chain together sets of
> stylesheets to run multiple transformations in a single pass w/o having
> to use special XSLT extensions).
>
> We're using an XSLT framework to process incoming NLM Journal Publishing
> Format XML into XHTML, Atom Entries, and into other metadata formats.
> We're then using XSLT to run services which talk to other services over
> HTTP using XML.  About 90% of the 'native' services in our new front
> end system (we're still running some pieces off our traditional MVC
> Servlet/Mediator/RDBMS style Java architecture) runs off one servlet and
> its underlying framework, and that servlets purpose in life is to chain
> together XSLT transformations, and to act as an underlying caching
> framework (e.g., for the URIResolver used by fn:doc() calls, or as
> a store for fn:result-document() calls).
>
> We're still relatively early into this process, and we still want to
> add optimizations and better RESTful caching into the system, but so
> far XSLT is working great as a way to build new services.
>
> We're hoping the use of XSLT for large areas of our system will mean
> that we can easily bring new people on board and train them on how to
> build new services.  XSLT gives our architecture the power to *easily*
> pull data from many sources (and from many formats), and the power to
> render that aggregated data into another, perhaps completely different
> looking, form.  It's pretty great.
>
> We are seeing many benefits from this approach, but there are some serious
> downsides as well -- memory and CPU consumption are a big concern,
> and we have to keep a careful eye on how new services affect the load
> on the servers.
>
> Another problem is that the TRaX API just isn't up to speed with the level
> of configuration and caching we want to be able to perform.  We ended
> up hooking straight into Saxon directly in a few areas, just to be able
> to get more useful information and to implement optimizations we needed.
>
>
> 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