Subject: RE: [xsl] killing xslt From: "M. David Peterson" <m.david@xxxxxxxxxx> Date: Thu, 13 May 2004 09:07:09 -0600 |
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 > 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. > :(
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] killing xslt, bry | Thread | RE: [xsl] killing xslt, David . Pawson |
RE: [xsl] RE: [saxon] OASIS-Open/CA, Mullee, John | Date | Re: [xsl] two namespaces and a posi, David Carlisle |
Month |