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(_dot_)robinson(_at_)stanford(_dot_)edu> 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(_dot_)robinson(_at_)stanford(_dot_)edu
Stanford University HighWire Press http://highwire.stanford.edu/
+1 650 7237294 (Work) +1 650 7259335 (Fax)
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--