Re: LINQ to XML versus XSLT

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