Re: [xsl] killing xslt

[David Carlisle <davidc@xxxxxxxxx>]

Mike wrote

  The sad part of this is that it pretty well kills XSLT on the browser, which
  always held out so much promise if only the interoperability problems could
  be sorted out. On the server, it's pretty clear that Microsoft don't set the
  technical direction. 

Which means it kills the primary reason for the development of XML.
Strange how things turn out. 

  XQuery in its current form is no good at document transformation, and even
  for data, it's got much less functionality than XSLT 2.0. It will succeed as
  a database query language, which is what it's designed for, but I don't
  think it will ever threaten the space where XSLT is currently used.

I think that the main threat to XSLT2 is not XQuery, it is  XSLT1.
Currently saxon7 is the only visible implementation, although when I
last speculated how XSLT2 would get out of CR status you implied that
you had hopes of further implementations appearing, which would be good.
But it remains to be seen how many other scenarios (aside from client
side browser transforms) stay at XSLT1. For as long as that remains
a significant minority, it will always be easier to achieve cross
platform portability by writing in XSLT1 than 2.

Actually now that I've written a few XSLT2 stylesheets I am coming to
quite like it. The last one I wrote could not sensibly have been written
in XSLT1, perhaps with some effort in xslt1+xx:node-set() but definitely
far more natural in xslt2. (string handling, regexp and xslt-defined
xpath functions). The schema support is an irritation (as I posted on
the offical comment list I had to a) declare the schema namespace and b)
use explict casting to xs:integer all over the place) but hopefully some
of that irritation can be avoided by minor tweaks to the casting rules
before XSLT2 is finalised. I suspect that the schema typing would be far
more annoying and intrusive in a schema-aware XSLT processor, but it's
hard to make any real comments on that given the lack of implementations
to try.  XPath2 is of course a complete mess compared to Xpath 1 but
the mess seems worse (much worse) when reading the spec, and that will
annoy rather few people, in practice as used in a non-schema aware XSLT2
engine it's not as bad as it seems (or at least, the bad bits don't
intrude as often as you might expect), which is why I'm far more relaxed
about XSLT2/XPath2 than I was when I first saw the specs.

We'll see...  Predicting the future is always a hopeless exercise:-)

David


-- 
The LaTeX Companion
  http://www.awprofessional.com/bookstore/product.asp?isbn=0201362996
  http://www.amazon.co.uk/exec/obidos/tg/detail/-/0201362996/202-7257897-0619804


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________