RE: [xsl] LINQ to XML versus XSLT

["Houghton,Andrew" <houghtoa@xxxxxxxx>]

> From: Scott Trenda [mailto:Scott.Trenda@xxxxxxxx]
> Sent: Friday, June 27, 2008 2:51 PM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] 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)

These things can be done from XSLT, XQuery or Tomcat/IIS mechanisms.  For
example Saxon includes extension functions to interface with SQL database
through JDBC drivers.  You can, and one of our projects is actually doing
this, access the HTTP headers.  E-mail can be also implemented as an extension
function.  Read/Write binary data can be accomplished through the use of HTTP
MIME extensions.  Some of this stuff is being done by the eXist XML database
folks and guess how?  XSLT and XQuery extension functions.

> 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.

I wouldn't say non-standard extension functions.  The XSL/XQuery
specifications have specified a standard way for application developers to
extend XSL/XQuery.  So I disagree that these are hacks, it is an extensibility
mechanism defined by the standards.  Are they implementation dependent?  Yes,
they are, but if your application development team writes their own extension
functions is that "locked in"?  There is nothing special about Saxon's
built-in extension functions.  I could have written them myself.

Rather than create a specialized dialect of XSL or XQuery Saxon smartly used
the extension mechanisms found in the specifications to enhance their product.
I don't have to use their extensions mechanisms and am free to write my own
which duplicate their functionality.  I don't see that as "locked in", but
potentially saving me development time.  Should I move to another XSL/XQuery
engine, then I may write my own extension functions that behave exactly as
theirs do.  I still don't feel "locked in", just more empowered that the
people who chaired the XSL and XQuery specification had the foresight to
include a defined extension mechanism in the specification to minimize or
avoid vendor "lock in".


Andy.