RE: LINQ to XML versus XSLT
That's cool (and I especially like Andrew Houghton's idea of applying different transforms based on the extension being requested), but I still see a few vital requirements that I haven't yet seen a way to do in XSLT 2.0. A basic-functionality replacement would need to be able to: - work with relational databases (believe it or not, many of us still need to work with these) - access HTTP data (headers, GET/POST data) - send e-mail - read/write binary data (admittedly getting picky, but the base restriction from XML makes this hairy) And I may be omitting other common ones. What I'm trying to get at is that these things are common requirements for an HTML preprocessor, and there are several flavors out on the market these days, each of which seem to do it wrong in their own way from an XSLT-based perspective. It seems like it'd be a good idea to write up a spec for these common tasks, figure out the way to Do It Right, and design an XML-based language to do exactly that. Since both would Just XML, this language could work hand-in-hand with XSLT 2.0 (and other XML-based technologies as well) so that they can be used within one another, leveraging off each others' strengths and helping prevent redundant duplication of features. Pointing to non-standard extension functions and possibly insecure (or locked) protocols to do what, admittedly, seem like hacks in XSLT isn't a real substitute for a well-designed (perhaps even standardized) XML language designed specifically to deal with the day-to-day requirements of an average webserver. ~ Scott -----Original Message----- From: Andrew Welch [mailto:andrew.j.welch@xxxxxxxxx] Sent: Friday, June 27, 2008 10:53 AM To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx Subject: Re: LINQ to XML versus XSLT > All fairly trivial. For example a custom handler coupled with IIS 7.0 and > you could have that up-and-running within a day. 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. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/
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