Subject: Re: [xsl] LINQ to XML versus XSLT From: "James A. Robinson" <jim.robinson@xxxxxxxxxxxx> Date: Fri, 27 Jun 2008 09:12:04 -0700 |
> 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] LINQ to XML versus XSLT, James A. Robinson | Thread | Re: [xsl] LINQ to XML versus XSLT, Dimitre Novatchev |
RE: [xsl] LINQ to XML versus XSLT, Houghton,Andrew | Date | Re: [xsl] LINQ to XML versus XSLT, Michael Ludwig |
Month |