XSLT 2.0 Sir?


One questions that I am getting more frequently is “Will the next release of System.Xml V2.0 support XSLT 2.0?”. The answer is “No”. It’s not that we do not love XSLT (see [1] and [2] below), in fact it has proven itself to be both a powerful and adaptable language, but a challenger has risen in the form of XQuery. Developers will soon have a choice to make. The XQuery 1.0 and the XSLT 2.0 specs have been produced in tandem and to a large extent both languages are simply different syntax manifestations for the same thing sharing both a common data model and type system. You can think about this in the same way that C# and VB.NET share the same types and Meta data via the CLR. XSLT 2.0, XQuery 1.0 and XPath 2.0 are just the same query language dressed up in different forms. Learning one means that you can easily master the others.


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. The next 5 years will tell whether this assertion was correct. This is also why we have shown little interest in XQueryX for that matter since it is, well, like XSLT 2.0 but less useful. (I predict that less that 0.001% of people will ever care about XQueryX which amounts to about 70 developers worldwide) Anyway back to the point at hand. XQuery is a nicer syntax to author by does not replace XSLT yet mainly from its inability to do template style pattern matching, but it will get there eventually. Certainly like VB and C# these languages will live side-by-side; people will tie themselves to their favorite language and go down dying to protect it.


As a point of comparison for the more usable syntax of XQuery, the well know 99 Bottles of Beer program, which currently has 621 variations, can now be incremented to 622 with a new addition under the X category. Here is the XQuery implementation of this.


_______________________________________________________________________


 


declare variable $new-line as xs:string


{ “


” };


 


declare function local:bottles($bottles as xs:integer?) as xs:string


{


    if ($bottles = 1) then


        “1 bottle”


    else


        fn:concat($bottles cast as xs:string?, ” bottles”)


};


 


declare function local:verse($bottles as xs:integer?) as xs:string


{


    if ($bottles = 1) then fn:concat(


        “0 bottles of beer on the wall”, $new-line,


        “0 bottles of beer!”, $new-line,


        “Go into town, buy a new round”, $new-line,


        “Get some more bottles of beer on the wall!”, $new-line


    )


 


    else fn:concat(


        local:bottles($bottles), ” beer on the wall,”, $new-line,


        local:bottles($bottles), ” of beer!”, $new-line,


        “Take one down, pass it around;”, $new-line,


        local:bottles($bottles – 1), ” beer on the wall,”, $new-line,


        local:verse($bottles – 1)


    )


};


 


local:verse(/bottles[1] cast as xs:integer?)


 


_______________________________________________________________________


Nicer than the XSLT equivalent? I will let you decide that.


There is functionality in XSLT 2.0 that is unique to it such as Grouping and multiple output documents. So when I am asked “Will you support XSLT 2.0” my immediate reply is “What does it [XSLT 2.0] give you that you cannot do today?


 8/10 answers typically say “How I can add these two dates together” or “I would love to be able to use Regex on this string”. If you are using the .NET platform then you can take advantage of projects like EXSLT (also described here) to do things like this today without the need for XSLT 2.0 and XQuery 1.0 will be able handle the type operations.


So do you need XSLT 2.0 and why? Do you see yourself using XQuery over XSLT?


[1] We love XSLT enough to have integrated a superb XSLT debugger into Visual Studio 2005 which will be available in the Beta 1 release coming soon.


[2] We recently asked 152 .NET framework customers “Do you use XSLT in your application development“. The spectrum of customers was broad including large enterprises, ISVs and smaller companies. 52 of them replied “Yes” which is an interesting statistic since it shows that XSLT is now fairly pervasive in the software industry.

Comments (42)

  1. Luc Cluitmans says:

    Well, XQuery looks very interesting. But where can I find some .NET based implementation (or partial implementation) right now?

    Almost any list of current implementations of XQuery, including the list on the officila XQuery website ( http://www.w3.org/XML/Query ), lists "Microsoft’s XML Query Language Demo" at "http://xqueryservices.com" as a .NET based implementation. However, googling around shows that that site has been dead for nearly a year now. Is there any clarification from you, microsoft guys, why the site was pulled, and when/if something will be back in place for it? Is there any hope to see any MS implementation of (a subset of) XQuery that works on the 1.1 framework and VS2003? Or alternatively, is there any hope of the ‘community previews’ of whidbey being made available to MSDN Professional (not Universal) subscribers?

    The problem is that any currently available XQuery implementation relies on Java, and there are no implementations available that use XPathNavigator or other .NET framework classes as input.

  2. > Nicer than the XSLT equivalent?

    Yup, that’s really nicer than XSLT 1.0 equivalent. But XSLT 1.0 is 5 years old and XQuery is still in works. That would be interesting to compare it with XSLT 2.0 solution.

  3. Andrey Skvortsov says:

    I don’t think that XQuery can completely replace XSLT in long run because:

    1)XSLT already have stable(and unique from languages perspective) template based mechanism proved his flexibility and power in many situations tested by numerous people worldwide(why create another?).

    2)XSLT has wonderful/unique feature what it can be expressed through itself forming recursive/loop programming models where XSLT recognized as data or code depending on context but XQuery is text by nature and can’t be handled in structured/convenient/usual(for xml) way.And I doubt that you can provide tools(not proprietary) which can compare to standard xml instruments in ability to manipulate XQuery(that critical in most serious cases), so same question-why another "CodeDOM" for XQuery?

    Best wishes.

  4. bryan says:

    okay, first what Oleg said.

    second, I have a hard time taking your statements at face value here because I’m not used to people saying things like We love X, and we’re not gonna support it, and of course because the xslt example you used was written in a style for which the xquery example would look much better. No doubt 99 bottles has restrictions that keep xslt from being used properly but I don’t think most competent xslt people would want to write it that way.

    I would probably do something like this, using rounded brackets instead of angle to represent markup:

    (xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

    xmlns:d="http://www.99-bottles-of-beer.net/x.html#XSLT" version="1.0")

    (xsl:output method="text"/)

    (d:data)

    (d:n/) bottles of beer on the wall, (d:/n) bottles of beer, take 1 down pass it around (d:n2/) bottles of beer on the wall

    (/d:data)

    (xsl:variable name="newline")

    (xsl:text)

    (/xsl:text)

    (/xsl:variable)

    (xsl:template match="*")

    (xsl:param name="n"/)

    (xsl:apply-templates)(xsl:with-param name="n" select="$n"/)(/xsl:apply-templates)

    (/xsl:template)

    (xsl:template match="d:n")

    (xsl:param name="n"/)

    (xsl:value-of select="$n")

    (/xsl:template)

    (xsl:template match="d:n2")

    (xsl:param name="n"/)

    (xsl:value-of select="$n – 1")

    (/xsl:template)

    (xsl:template match="/")

    (xsl:variable name="n" select="99"/)

    (xsl:call-template name="loop")(xsl:with-param name="n" select="$n"/)(/xsl:call-template)

    No More bottles of beer on the wall

    (/xsl:template)

    (xsl:template name="loop")

    (xsl:param name="n"/)

    (xsl:value-of select="$newline"/)

    (xsl:if test="$n > 0")

    (xsl:apply-templates select="document(”)/xsl:stylesheet/d:data")

    (xsl:with-param name="n" select="$n"/)

    (/xsl:apply-templates)

    (xsl:call-template name="loop")(xsl:with-param name="n" select="$n – 1"/)(/xsl:call-template)

    (/xsl:if)

    (/xsl:template)

    (/xsl:stylesheet)

    This is of course still somewhat verbose, however it is structured in such a way that xslt 2.0 could minimize it even further.

  5. bryan says:

    note that I didn’t do anything to take care of difference between 1 bottle and multiple bottles, the above is more to indicate the close connection between xslt and data input. any use of xslt without a data input to work on is using the language in a really bad way. It’s like using visual basic for working with sockets. To coin an analogy.

  6. Michael Kay says:

    It’s a little bit odd to try and prove your point with an example that makes no use of XML input or XML output, and without providing an equivalent in XSLT 2.0 for comparison (which would show how little difference actually exists).

    The use of XML syntax in XSLT has pros and cons. The pros are that you can use all the XML tools on it – editors, XML databases, XSLT and XQuery. (What, you can’t store queries in an XML database and use XQuery to find them?) There have been non-XML syntaxes for XSLT and they’ve never caught on. Syntax is not really the issue.

    Microsoft seems to make U-turns in its strategy every 12 months or so. Applications last for ten years. People who have been battling with the limitations of version 1.0 of one language for five years don’t want to be told to switch to version 1.0 of another language with similar limitations. XQuery is full of deliberate restrictions in functionality, which make it highly suited as a database query language, and very difficult to use as a general-purpose XML transformation language. Handling narrative XML (anything without a rigid schema) in XQuery is really hard work.

    The underlying problem, I suspect, is that in MSXML Microsoft produced a superb technical product, but it made no money because there were too many free competitors. Database software still attracts high prices, so there is money available to be spent on XQuery development. There are plenty of XSLT enthusiasts in Microsoft, but they have no funding.

    Anyway, if Microsoft stay out of this one, it certainly creates more scope for other suppliers to fill the gap.

  7. I have to second (third, fourth, etc, as the case may be) the opinions above. I just can’t believe the reasoning you use to explain the decision. If those are, in fact, the real reasons, I would say they just aren’t good enough.

  8. I mostly agree with Michael.

    I don’t think XQuery to XSLT is what VB.NET to C#. Everything that can be done in C# can be done in VB.NET, while XQuery is a limited subset of XSLT. Of course XQuery can be extended with extension functions to provide absent functionality like grouping, but you know, extensions are just extensions.

    For people struggled to climb XSLT learning curve that’s really bad news. XSLT 2.0 is so cool and so simplifies practical XSLT programming, not having it is a nonsense.

    But if you ask me what I’d choose XQuery or XSLT implementation from Microsoft – my choice is XQuery. IMO it’s only Microsoft who can make good XQuery impl for .NET and SQL Server, while XSLT processor can be developed by third party or by the community.

  9. 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&quot; 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/>

  10. Luc,

    > Well, XQuery looks very interesting. But where can I find some .NET based implementation (or partial implementation) right now?

    try this link:

    http://www.pietsieg.com/sections/XQuery/ArtXQueryBeg.aspx

    there is an updated article I wrote about XQuery and MS’s implementation, and the installer is also there. I also wrote a .NET Web Application called XQuery Expression Tester using the XQuery Demo class set to demonstrate XQuery queries.

    I was hoping I could update this article as MS followed the spec development, but it seems the effort has died somewhere and I never knew the cause of that. Anyone at MS who can comment on this?

    Cheers, Pieter

  11. bryan says:

    Well Dare says there won’t be Xpath 2.0 in the framework either. But there will be Xquery.

    hmm.

    damn, well M.David’s example shows I should have used a concatenative approach in my earlier example, also shows that you can post straight angle brackets here I guess.

  12. Take Outs for 13 May 2004

  13. Take Outs for 13 May 2004

  14. Michael Rys says:

    XQuery 1.0, XSLT 2.0 and XPath 2.0: The blogging continues

  15. wilhe says:

    let’s say it is a fair statement to make that developers will find the syntax of XQuery more natural than the templated markup of XSLT….. what about non-developers who follow their developer’s instructions for supplying content for an application… a website for example. I don’t think adoption of a technology hinges only on the developer. What "attracts" this developer is the consistency of a toolset, dependability of a vendor’s implementation and feature extensibility be made possible where needed. I like being able to say "Just create a template that looks like this, add your features here, save it in this directory, and I will take care of the data for it and it will display on the site…. without having to tell this user what the difference is between this loop and that assignment

  16. Michael Rys says:

    Again, XSLT 1.0 will continue to be supported and improved. Do you rather have a slow 1.0 and slow 2.0 or a fast 1.0?

  17. wilhe says:

    I used the XQuery implementation that is no longer available on xqueryservices.com.. I liked it quite a bit and got very excited about another way to manipulate data. I have used java based APIs for xquery as well. I even wrote a CCW around the XQuery implementation from the .NET site and used it in classic ASP sites last year. If XSLT 2.0 and XQuery are basically the same thing, would your decision to not support XSLT 2.0 in favor of XQuery be similar to saying you will support database access to SQLServer but not new versions of Access in a future release because SQLServer and Access are basically the same thing but SQLServer has more enterprise level features and allows developers to write much richer queries? Sorry I may be a little slow…. please excuse me if I am still missing the point. I am not sure what Michael Rys means when he suggests a fast 1.0 vs. a slow 1.0 and 2.0. Why would it be slow either way?

  18. Michael Rys says:

    wilhe, the point I made was trying to make was that resources to implement XSLT 2.0 in addition to improve the existing XSLT 1.0 engine and to implement XQuery 1.0 have to be taken from somewhere. While Microsoft is a large company, not everyone at Microsoft works on XSLT or XQuery :-). So if you put resources on XSLT 2.0, it may be very likely that you will use the people that worked on XSLT 1.0 and thus they will not be able to improve the performance of XSLT 1.0.

  19. +1 for fast XSLT 1.0

    And +1 for fast XSL 2.0 in a couple of years 🙂

  20. There is another resource – the devs around.

    I’m sure XSLT 2.0 processor can be developed by the commutity (XML MVPs + XML Insiders + anybody interested).

    The only thing we need to start is some kind of blessing or at least sign of appreciation from the house.

  21. wilhe says:

    sign me up 🙂

  22. Gurbhajan S. Bagh says:

    "It’s not that we do not love XSLT" an opinion not shared by all Microsoft employees….(Read the tagline under his name)

    http://www.gotdotnet.com/team/dbox/

  23. Brad King says:

    Man, I hate to see nice declarative code like XSLT replaced with "IF" procedural blocks. If I wanted to do that I would code in c#.

  24. Benjamin says:

    Well, it looks like I belong to 0.001% of the developers who care about XQueryX :-). One of the possible use cases for the syntax could be following: MS, Oracle , IBM are implementing XQuery. The probability that code written in XQuery will be compatible across all platforms is 0.0000001% even if people agree on the common XSD and model they are querying. Therefore, it’s possible that participants will convert standart XQuery to their particular implementation of the XQuery standard.

    If generic XQuery comes in then you can parse it, create AST, then genenerate your proprietary XQuery version (stylesheet, or whatever engine you might have) and execute it. If standard XQueryX comes in then all you have to do is just apply stylesheet to generate your proprietary XQuery statement, skipping the step of parsing original XQuery and creating AST.

    For example BEA Liquid Data supports previous draft of XQuery which has

    "namespace foo=’http://bar.net“>http://bar.net‘"

    intead of latest addition

    "declare namespace foo=’http://bar.net“>http://bar.net‘"

    (there are other things as well).

    If my LD engine gets latest XQuery then I will have to "jump throught the hoops" before i can run this query against my engine, where as if XQueryX comes in it will be much easier to provide compliance with my engine syntax.

  25. Yuriy says:

    I think the question is not XSLT 2.0, as it was said there is nothing so important in v2.0 that makes is so desirable. However, it is more interesting question if we can expect future improved versions of XSLT processor, even if it is still 1.0 compliant. I think any improvements in performance (it is already very very fast) is much more important than XSLT 2.0 support. EXSLT approach is fine and I really do not see big importance for 2.0.

    However, I do not see easy way to use Xquery instead of XSLT where I use XSLT, i.e. to define XML language and generate source code, XSLT, CSS etc using XSLT from the source XML file. So, it is usual for me to have 3Mb XSLT file processing small XMLs, where this master XSLT is generated by XSLT.

    XQuery is superb to query, but it is not so fine to transform XML to XML, especially when you do identity XSLT transformation handling only some elements.

  26. Anon says:

    The First line of code on EVERY eBay auction :

    <html xmlns:x="urn:schemas-microsoft-com:xslt">

  27. Flavius says:

    Can somebody tell me please what is the complexity of searching using Saxon XSLT keys O(1) or O(log n)?

  28. Sinister says:

    The syntax used for writing queries is horrible. Why in the world would you ever want to copy that?! The whole point of using XSLT instead of the billions of other languages to format data (not the least of which would be scripts like ASP or code like C#) is the XML formatting. XQuery looks like just another script language. To that point: who cares? Why should we use it instead of the others out there? I say it buys us virtually nothing.

    It’s unfortunate when developers completely sell out to marketing ya-hoos. Why be such a sellout Mark? Just admit the truth: XQuery is weak, XSLT is better.

  29. gsi says:

    Hi @ all

    Where do i find an XSLT to XQuery Converter. I need it for a prove of concept imlementation. Is there such a converter or do i have to do i by my own?

    Best wishes gsi

  30. In quick follow up… As it was hinted towards in various threads of this post an open source project to port Saxon 8.0-B to C# and the .NET platform(and thus bring XSLT 2.0 and backwards compatible XPath 2.0 to .NET) has been developed and is well underway. Pieter Siegers, Don "DonXML" Demsak, Kurt Cagle, myself, and a few others to follow have teamed up to bring this project into fruition. See the above link for the main project page.

    Although we are all well equipped and quite determined to quickly get the first set of bits up to for download there is much more that can be done. Don has really focused his desire (and the rest of us agree) that the port from Java to C#/.NET is only the first step. Bringing the Saxon bits in unison with the strengths of the .NET platform (and of course extending the areas where Java has a considerable advantage over C#/.NET) is going to be an effort that can only be strengthened by the input of those of you who have the strength and knowledge in some very particular and fined tuned areas. We look forward to the contributions of anybody and everybody who has a desire to get involved.

    Thanks!

    <M:D/>

  31. Ted James says:

    About that "XSLT to XQuery Converter" question from gsi. Here’s a link to a message which writer Eva Lenz (elenz@xyzfind.com) tells about how she is developing a XSLT to XQuery Converter.

    Here’s the link: http://lists.xml.org/archives/xml-dev/200102/msg00570.html

  32. Mike Marx says:

    So when will the System.Xml V2.0 be released then or is it allready out?

  33. Ken Brubaker says:

    .NET 2.0 will not support XPath 2.0/XSLT 2.0

  34. I was doing some catch up reading feeds I’m subscribed and I found this one item that made me feeling some sort of bitter nostalgia. It’s right on MSDN TV site, a new episode where Mark Fussel explains new XML features in upcoming .NET 2.0. The episode is dated December…