From: Scott Trenda [mailto:Scott(_dot_)Trenda(_at_)oati(_dot_)net]
Sent: Friday, June 27, 2008 2:51 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--