RE: [xsl] LINQ to XML versus XSLT

["Scott Trenda" <Scott.Trenda@xxxxxxxx>]

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