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
Anonymous
May 12, 2004
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.Anonymous
May 12, 2004
> 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.Anonymous
May 12, 2004
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.Anonymous
May 12, 2004
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.Anonymous
May 12, 2004
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.Anonymous
May 12, 2004
The comment has been removedAnonymous
May 12, 2004
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.Anonymous
May 12, 2004
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.Anonymous
May 13, 2004
The comment has been removedAnonymous
May 13, 2004
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, PieterAnonymous
May 13, 2004
The comment has been removedAnonymous
May 13, 2004
Take Outs for 13 May 2004Anonymous
May 13, 2004
Take Outs for 13 May 2004Anonymous
May 13, 2004
XQuery 1.0, XSLT 2.0 and XPath 2.0: The blogging continuesAnonymous
May 14, 2004
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 assignmentAnonymous
May 14, 2004
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?Anonymous
May 14, 2004
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?Anonymous
May 14, 2004
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.Anonymous
May 15, 2004
+1 for fast XSLT 1.0
And +1 for fast XSL 2.0 in a couple of years :)Anonymous
May 15, 2004
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.Anonymous
May 17, 2004
sign me up :)Anonymous
May 17, 2004
"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/Anonymous
May 17, 2004
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#.Anonymous
May 20, 2004
The comment has been removedAnonymous
May 20, 2004
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.Anonymous
May 20, 2004
The comment has been removedAnonymous
May 24, 2004
Can somebody tell me please what is the complexity of searching using Saxon XSLT keys O(1) or O(log n)?Anonymous
June 01, 2004
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.Anonymous
June 07, 2004
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 gsiAnonymous
June 22, 2004
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/>Anonymous
July 15, 2004
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.htmlAnonymous
July 15, 2004
So when will the System.Xml V2.0 be released then or is it allready out?Anonymous
July 30, 2004
.NET 2.0 will not support XPath 2.0/XSLT 2.0Anonymous
December 14, 2004
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...Anonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=mark-fussell-s-weblog-xslt-2-0-sirAnonymous
June 15, 2009
PingBack from http://debtsolutionsnow.info/story.php?id=669