Re: LINQ to XML versus XSLT
> 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)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format