Subject: RE: [xsl] LINQ to XML versus XSLT From: "Scott Trenda" <Scott.Trenda@xxxxxxxx> Date: Fri, 27 Jun 2008 14:22:37 -0500 |
My original point was that there _should_ be one, for those reasons and because working with HTML and XML in a C-style language is unwieldly and ugly. You subsequently said there shouldn't be one since XSLT 2.0 can do anything and everything and therefore _should_ do anything and everything, and my previous e-mail was in response to this. Like I said, the proprietary preprocessor we use at my work is tag-based, and is quite pleasant for working with XSLT, HTML and other tag-based input and output. We've been using it less and less for raw string-based HTML generation, and more for a "glue" of sorts to coordinate the other technologies that do the brunt of the hard work. It does a wonderful job of, say, taking in a SOAP request, feeding the XML payload into an XSL transformation that generates SQL code to verify the business information in there, taking the FOR XML AUTO result of that SQL query and transforming it into its own code (which can generate e-mails, do file I/O manipulation, etc.), which it can then run. It's procedural, sure, but only where it needs to be procedural. (Michael Ludwig's comment about SQL relevant here.) The point I'm trying to convey here is that rather than trying to shoehorn everything into XSLT 2.0 through the vendor's extension functions may not be the best way to go for most webserver tasks. If a group like the W3C were to finally tackle this issue with the goal of producing an XML-based language to handle these tasks (while leveraging against the strengths of the other XML technologies), then we may finally be able to escape PHP and other awkward preprocessors. ~ Scott -----Original Message----- From: Colin Paul Adams [mailto:colin@xxxxxxxxxxxxxxxxxx] Sent: Friday, June 27, 2008 2:02 PM To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx Subject: Re: [xsl] LINQ to XML versus XSLT >>>>> "Scott" == Scott Trenda <Scott.Trenda@xxxxxxxx> writes: Scott> Pointing to non-standard extension functions and possibly Scott> insecure (or locked) protocols to do what, admittedly, seem Scott> like hacks in XSLT isn't a real substitute for a Scott> well-designed (perhaps even standardized) XML language Scott> designed specifically to deal with the day-to-day Scott> requirements of an average webserver. There are no languages designed to do these things - only languages with library routines. So you are right that it's not a substitute - it's the same thing. -- Colin Adams Preston Lancashire
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] LINQ to XML versus XSLT, Colin Paul Adams | Thread | Re: [xsl] LINQ to XML versus XSLT, Colin Paul Adams |
Re: [xsl] LINQ to XML versus XSLT, James A. Robinson | Date | RE: [xsl] LINQ to XML versus XSLT, Houghton,Andrew |
Month |