[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] killing xslt

---

---

For what its worth here is my post back to Mark Fussell's blog post.

------------------------------------------------------------------------

I tell ya I sure do love a throw down challenge to write code to
showcase just how powerful a particular language can be when written
properly.  Mark, I can write that stylesheet in 20 lines of code and in
1 minute and 45 seconds.

Name that stylesheet...

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:template match="/">
  <xsl:call-template name="bottles_of_beer">
    <xsl:with-param name="bottles" select="'99'"/>
  </xsl:call-template>
</xsl:template>
<xsl:template name="bottles_of_beer">
<xsl:param name="bottles"/>
<xsl:variable name="ps_bottle">bottle<xsl:if test="$bottles !=
1">s</xsl:if></xsl:variable>
  <xsl:value-of select="concat($bottles, ' ', $ps_bottle)"/> of beer on
the wall.
  <xsl:value-of select="concat($bottles, ' ', $ps_bottle)"/> of beer.
  Take one down, pass it around, <xsl:value-of select="$bottles - 1"/>
bottles of beer on the wall.
  <xsl:if test="$bottles &gt; 1">
    <xsl:call-template name="bottles_of_beer">
      <xsl:with-param name="bottles" select="$bottles - 1"/>
    </xsl:call-template>
  </xsl:if>
</xsl:template>
</xsl:stylesheet>

Note that any lines that are wrapped will extend the count artificially.
None the less the count would still pretty easily beat the 32 lines of
your XQuery.

Ok, so my point isnt to congratulate myself in writing XSLT that is
shorter than your XPath (although you did set yourself up nicely by
giving us a link to XSLT code that was EXTREME overkill to showcase 99
bottles ;) .  My point is to showcase the fact that XSLT is an extremely
powerful language and can be used very efficiently to develop a code
base that is easy to manage and make changes to and/or updates to
accomodate sudden shifts in the data being processed.  

For example, if XSLT is written correctly the addition of a brand new
element into the XML data requires the addition of one template that
matches this value and then transforms the containing data accordingally
when called upon to do so. In fact, if there is already a template that
transforms the new data the desired way the a simple addition of the
element name to the match attribute of the correct template using a |
(union) will add the processing capability of this new element
immediatelly.

A few comments on your remarks...

"XQuery is a nicer syntax to author" - According to who?  I would confer
that XSLT and its well formed XML structure is much more attractive.
Wasnt the well formed nature of XML one of things that attracted people
to it in the first place?


"by does not replace XSLT yet mainly from its inability to do template
style pattern matching"

EXACTLY!!!  Template matching is what makes XSLT so powerful!  XQuery is
really good at querying data from a database (thus its name, XQuery) and
because of its SQL like syntax I agree that this will bring over
developers who were frustrated with the functional way of thinking that
XSLT invoked and as such decided not to use it or created solutions that
didnt use XSLT in the way it was designed and as such created a mess of
code that caused even more frustration with how complicated it was.  

Whats the point of not including support for XSLT 2.0?  I cant imagine
there's a developer resource shortage causing the decision as Michael
Kay is one developer and wrote complete support for XSLT 2.0, XPath 2.0,
AND XQuery 1.0 into Saxon.  Heck, even if you had to throw 5 guys on the
project to allow the ties into the .NET platform Im not seeing that as
THE deterent to decide to not support XSLT 2.0.  The idea that with
EXSLT and the existing 1.0 support coupled with other .NET features you
can emulate the functionality of 2.0 seems more of an excuse than a
reason.  If your going to rely on an open source extension to the .NET
XslTransform() class to give functionality like regex to the .NET XSLT
developer then why not do the same for every technology where an open
source project fills in the gaps that are missing?

If you honestly believe that the combination of XPath and XQuery will
give the developer all the tools he/she will need to transform XML data
in the most efficient manner and in a format more desirable than that of
XSLT then I am sorry to say but I believe you are mistaken.  To justify
the fact that template matching will not be available with this
combination of technologies with the statement ", but it will get there
eventually." goes beyond what I could even extend the courtesy of
calling asinine.  And to try and suggest that template matching is there
now so why worry whether or not XSLT 2.0 is supported would make the
statement "the ability to turn bits into pixels already exists in
Windows so why develop another version" just as valid of a statement.

"However ultimately we made the decision that the non-XML syntax (or you
could say more SQL like syntax) of XQuery was going to attract more
developers in the long run, in the same way the developers on the whole
find XPath an easier file-path like syntax to write."

Ok, so then whats the justification of going the opposite direction with
XAML and Longhorn.  Isnt this pretty much the EXACT argument they used
(but reversed) to justify using a "much simpler" markup style language
to create and manage the future Windows user interface?  I agree, XAML
is FANTASTIC!  Lets keep the pattern moving in this direction and not
use the exact same argument to justify the exact opposite direction.  It
makes ZERO sense and either makes the .NET team or the Longhorn team
look foolish for taking each individual (and opposite) stance.

I can understand your point that you need to find a way to bring in
developers that have been turned away by XSLT's functional style of
programming.  So bring it in.  Let them use XQuery to develop there
solution because its more logical to there way of doing things.  But
dont cut off your nose to spite your face.  Again, why kill the most
powerful XML transformation tool available to the developer?  It doesnt
make any sense, unless...

There is something looming on the MS horizon that gives us everything
and more that XSLT gives us while adding extensive support for other
areas of Windows development.  Could a XEN or X# be the reason for the
sudden lack of interest in XSLT 2.0? Is there another transformation
engine that the Longhorn project is implementing with XAML that will
bring the benefit and power of XSLT and combine it with the benefit and
power of direct access to the Windows API?  If this is the case (and I
somewhat suspect it is...) and its just a matter of patience before we
are able to gain access to these technologies... Well, at least that
changes it from an excuse back to a reason :)

Would love to hear your comments on this and any further justification
of killing XSLT 2.0 if the above paragraph is not the reason.

And if I can make one more plea... Please dont kill XSLT 2.0.  I can
imagine that if this decision pans out and it does get the axe then
several of us of whom have a passion for XSLT and .NET will get together
and either port over Saxon to .NET (with the help of the Java to C#
conversion utility which kind of gives an ironic twist to this situation
:), extend from EXSLT.NETs extension to the XslTransform() class, or
start from scratch all together.  Maybe with some searching it will be
found that someone has already begun such development.  Any chance you
or anybody else reading this post know of any such projects?

Best regards! :)

<M:D/>

> -----Original Message-----
> From: bry@xxxxxxxxxx [mailto:bry@xxxxxxxxxx]
> Sent: Thursday, May 13, 2004 10:29 AM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] killing xslt
> 
> 
> 
> > I think the real reason Microsoft aren't
> investing in XSLT is that they
> > aren't making any money out of it, which
> is because they can't compete with
> > free software. There are plenty of XSLT
> enthusiasts inside the company, as
> > the blog indicates, but they don't have
> >any funding.
> Well this was one of the things that I saw
> as the reason for the complexity of the new
> wd, if it becomes complex enough you weed
> out the competition.
> 
> 
> > 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.
> I don't know if it kills XSLT on the
> browser. There is I assume still quite a
> long time before MS will release any browser
> that is .net based.
> 
> >
> > 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 don't know, success of a language is often
> tied to developer intuition of its future
> viability, lack of Windows support makes for
> an argument against such viability for some
> people. It's a hit, not a knockout. hmm,
> maybe it's only a slap, but I feel hurt.
> :(

---