Why You Won't See XSLT 2.0 or XPath 2.0 in the Next Version of the .NET Framework
The XML team has recently started getting questions about our position on XQuery 1.0, XPath 2.0 and XSLT 2.0. Yesterday my boss, Mark Fussell, posted about why we have decided to implement XQuery 1.0 but not XSLT 2.0 in the next version of the .NET Framework. Some people misinterpreted his post to mean that the we chose to implement XQuery 1.0 over XSLT 2.0 because we prefer the syntax of the former over that of the latter. However decisions of such scale aren't made that lightly.
There are several reasons why we aren't implementing XSLT 2.0 and XPath 2.0
It takes a lot of effort and resources to implement all 3 technologies (XQuery, XSLT 2.0 & XPath 2.0). Our guiding principle was that we believe creating a proliferation of XML query technologies is confusing to end users. We'd rather implement one more language that we push people to learn than have to support and explain three more XML query and transformation languages, in addition to XPath 1.0 & XSLT 1.0 which already exist in the .NET Framework. Having our customers and support people have to deal with the complexity of 3 sophisticated XML query languages two of which are look similar but behave quite differently in the case of XPath 2.0 and XQuery seemed to us not to be that beneficial.
XPath 2.0 has different semantics from XQuery, XQuery is strongly and statically typed while XPath 2.0 is weakly and dynamically typed. So it isn't simply a case that if you implementing XQuery means that you can simply flip some flag and disable a feature or two to turn it into an XPath 2.0 implementation. However all of the use cases satisfied by XPath 2.0 can be satisfied by XQuery. In the decision to go with XQuery over XSLT 2.0, Mark is right that we felt that developers would prefer the familiar procedural model and syntax of XQuery to the template based model and syntax of XSLT 2.0. Most developers working with XSLT try to use it as a procedural language anyway, and don't really harness the power of templates. There's always the steep learning curve until you get to the “Aha“ moment and everything clicks. XQuery with its FLWOR construct and user defined functions fits more naturally with how both programmers and database administrators access and manipulate data than does XSLT 2.0. Thus we feel XQuery and not XSLT is the future of XML based query and transformation.
This doesn't mean that we will be removing XSLT 1.0 or XPath 1.0 support from the .NET Framework. It just means that our innovation and development efforts will be focused around XQuery going forward.
Comments
Anonymous
May 13, 2004
Well, that sounds fair enough for me.
And as Mark said "The next 5 years will tell whether this assertion was correct."Anonymous
May 13, 2004
The comment has been removedAnonymous
May 13, 2004
The comment has been removedAnonymous
May 13, 2004
I personally think that XQuery rocks, but I do not agree with the XML Team stating that they had to decide between two actually different development efforts, simply because they (XSLT 1.0/2.0 and XQuery 1.0) will have their own application areas, where of course some areas will naturally overlap.
IMO, XSLT is a transforming language, while XQuery is more a querying language. That difference makes the application area of each a different one, although as said there will be overlap.
And that you guys are leaving out XPath 2.0 is really weird to me: knowing that XQuery is a superset of XPath 2.0, and more important, knowing you guys want to maintain XPath in .NET you simply cannot ignore XPath 2.0. What about if XPathNavigator keeps with XPath 1.0 whereas other XQuery classes are included with XPath 2.0 underneath implemented? Shouldn't XPathNavigator be updated also? The logical answer to me is a simple 'yes'.
Another Q: Could anybody tell me why the XQuery Demo was so silently removed? I still have the hope I can continue updating my article series about XQuery, found on my site:
http://www.pietsieg.com/sections/XQuery/ArtXQueryBeg.aspx
Regards, PieterAnonymous
May 13, 2004
Thanks for the feedback Pieter. XPathNavigator is simply an abstraction of the XPath 2.0/XQuery 1.0 datamodel. XML query languages such as XPath, XSLT, and XQuery are implemented on top of this abstraction. Therefore, there's no need to 'update' the XPathNavigator.
As for the XQuery demo, it was removed for two reasons. The first reason was it was completely out of date. It was based on very old prototype code which we weren't maintaining in light of our real implementation. Secondly, our real implementation became widely available in the PDC timeframe to MSDN subscribers via the .NET Framework Alpha release. A public beta release of the .NET Framework is scheduled shortly.Anonymous
May 13, 2004
Still, we could have left the site up and have a simple page explaining that people should get themselves signed up for the beta.Anonymous
May 13, 2004
XQuery 1.0, XSLT 2.0 and XPath 2.0: The blogging continuesAnonymous
May 13, 2004
"A public beta release of the .NET Framework is scheduled shortly"
That sounds good!
but how short is shortly ? ;)Anonymous
May 13, 2004
XML isn't just for database administrator, with a direct mapping from a relational database to a simple hierarchical xml schema (I'll call it the "relational type" XML). XML is also usefull for "injecting" metadata into a text document (which i'll call the "document type" XML), which is very difficult to map into a relational database.
So, in XSL, there is 2 distinct approaches for the templates, as noted in the MSXML documentation. The "template driven approach" is closer to the procedural model, works fine with the "relational type" XML files. On the other hand, the "data driven approach", that is closer to the object model and the polymorphism, works better with the "document type XML" file.
I've also noticed that most developpers feel more confortable with the template driven approach, but are not completly relunctant to the data driven approach.
Furthermore, some new features of the XSLT 2.0 will be usefull for manipulating the text nodes, with the regular expression for instance. This will make the data driven approach even more powerfull.
For some reason I do not fully understand (and don't tell me you cannot put 2 teams if you want, the company is Microsoft, isn't it ?), you are near to ignore the "document type" XML. For instance, the xsd.exe generator is not able to interpret an XML file with a recursive definition (that is a node which contains a node of the same type) into a schema.
I am currently not completly satisfied of the implementation of XML/XSL in .NET (transformNode does not work on the current node but always in the root node ;
you cannot specify the starting mode). I was hoping the new version of the framework will resolve those issue. I am not very confident now and even more, I have the feeling that not implementing XSLT 2.0 and XPath 2.0 is moving backwards.Anonymous
May 13, 2004
The comment has been removedAnonymous
May 14, 2004
How does the support for XQuery help for XML-on-the-Web? Will IE support XQuery? What am I missing?Anonymous
May 14, 2004
I just don't get it. Here M$FT is saying that they won't support this or that because there are too many overlapping specs. The solution isn't to pick and choose. That's like putting a bandaid on a sympton. The solution is to stand up, address the root cause and say "THERE ARE TOO MANY OVERLAPPING SPECS."
Atom RSS 1.0 2.0
SOAP XML-RPC REST
XSLT XQUERY XPATH
The reason that XML is successful is because we discount any alternative, even if it is superior.Anonymous
May 14, 2004
That you for post and comments, but.. Uhhhhh...
<i>"address the root cause and say 'THERE ARE TOO MANY OVERLAPPING SPECS.'"</i>
Perhaps the solution of picking and choosing, in actual fact, IS saying exactly that? As has always been done in the past, right?Anonymous
May 14, 2004
Sheesh. "Thank you for"...Anonymous
May 14, 2004
At least you were honest this time.Anonymous
May 14, 2004
"Java" Man,
Can you factually point out an occasion when I've been dishonest??
Sure, I make plenty of mistakes which, imv (in my view) is entirely different than dishonesty.
Your reply (anonymous, as is typical), in the absence of any cogent discussion.. ?
That'd be something more akin to dishonesty than a mistake imv, but icbw I s'pose...Anonymous
May 14, 2004
Regarding XSLT (regardless of whether 1.0 or 2.0): We continue to support XSLT 1.0 and improve on it (read Mark's entry to the end). As to the resource question, see http://sqljunkies.com/WebLog/mrys/archive/2004/05/13/2479.aspxAnonymous
May 14, 2004
What about XPath 2.0 support in XQuery?Anonymous
May 14, 2004
I'm not sure what you mean by XPath 2.0 support in XQuery. We will be implementing XQuery with the optional static typing feature. This is a superset of the XPath 2.0 language without backwards compatibility mode.
My point was that we will not be explicitly supporting the XPath 2.0 subset of XQuery as a separate language nor will we be supporting the XPath 2.0 backwards compatibility mode.Anonymous
May 14, 2004
I was a big Microsoft fan, but last few years all has changed!
If you want the latest and greatest technology, Microsoft is no longer there! Java platform is more dynamic, modern, and open of innovation. It's the same situation with the IDEs - where the refactoring for .NET, for example?
Things like these make me think that Microsoft has turned into an old man. It's not the innovative company that I loved! Probably just Bill's getting older.
I still think that Windows is the best OS ever and MS Office is the #1 office suite, but at least from a developer point of view, Java technologies are more attractive!Anonymous
May 15, 2004
Is there support for XQUERY 1.0 IE 6?
Is there an MSXML parser that supports XQUERY 1.0 ?
What parser can we start using ??
ThanksAnonymous
May 15, 2004
Is there support for XQUERY 1.0 IE 6?
Is there an MSXML parser that supports XQUERY 1.0 ?
What parser can we start using ??
ThanksAnonymous
May 15, 2004
Vincent Jacquet:
"transformNode does not work on the current node but always in the root node"
That's easy problem to solve. Take a look at the different approaches here - http://www.tkachenko.com/blog/archives/000234.htmlAnonymous
May 16, 2004
The comment has been removedAnonymous
May 17, 2004
Why don't you listen to developers any more?!
We all want XSLT 2.0 and XPath 2.0.
Sometimes it's very important to rest assured that you're using the top-notch framework and not having major technologies is a major drawback!
Probably you'll decide that XForms is way too complex and not implement it too, which will be a major mistake!
Again, a major technology leader must support major technologies, developed and established by major organizations such as W3C. I you fail to do so, you'll loose many, many developers. Of course, I'm not talking about VB 6.0- ones, because I agree that even XPath 1.0 is way to much for them.Anonymous
May 17, 2004
Asbjorn & Nikolay,
Agreed.Anonymous
May 17, 2004
Asbjorn & Nikolay,
What does XSLT 2.0 and XPath 2.0 provide you with that you cannot do with either XSLT 1.0 (with the EXSLT library) or XQuery 1.0?
XPath 2.0 is just a subset of XQuery (see my blog posting on this at http://sqljunkies.com/WebLog/mrys/archive/2004/05/13/2479.aspx), so if you get XQuery, you basically get XPath 2.0.
Just supporting new languages because a committee has designed it is not a good product design decision. If you can give us a better indication of why you need XSLT 2.0, then we can evaluate that.
Michael
PS: If I go home today and tell my wife, I need a new car, she will ask me the same questions :-)...Anonymous
May 17, 2004
The comment has been removedAnonymous
May 18, 2004
During a discussion on this topic a friend of mine came up with this comment, which I happen to agree with.
Query depends on a massive amount of code that is vendor-specific. I’m supposed to believe that MS and Oracle will implement XQuery perfectly and by the standard so that I can do a join from both of their databases in the midst of an XSL transformation? Yeah, right. Not only that… why would I WANT to do a join in the midst of XSLT? Why not simply join the data at the database using SQL (isn’t that what SQL was invented for?) and then do a simple transformation on the result set?
Also, it seems to me that Microsoft shouldn't be in the business of telling me what tools/technologies are best for me to program with, but should be in the business of providing me ALL the tools to be able to do what I need to do, and let ME decide the best way to accomplish the task.Anonymous
May 18, 2004
The comment has been removedAnonymous
May 18, 2004
If MS doesn't do it, somebody else can have a chance to do it, and probably better! I see it as more of an opportunity. I would love to see more than one XQuery1.0/XSLT 2.0/XPath 2.0 implementations for .NET.
RegardsAnonymous
May 18, 2004
Looks like our instituion is going to pull back from any investment into .NET until v3/4/5 will add standards support for things like XForms, XPath 2.0, XSLT 2.0.
Thanks for the advanced notice, Redmond.Anonymous
May 18, 2004
Michael,
The answer is currency.Anonymous
May 19, 2004
> Looks like our instituion is going to pull back from any investment into .NET until v3/4/5 will add standards support for things like XForms, XPath 2.0, XSLT 2.0.
Don't forget XHTML and CSS2. :-)Anonymous
May 20, 2004
I am a novice at programming. What I know I am self taught (HTML, XML, XSLT). I am attempting to program a website that is a price guide for collectibles that are manufactured by different companies. I need to have seperate XML documents for each company. I would also like to be able to present to viewers a list of all collectibles of the same topic, yet made by different companies. From what I gather the group-by function of XSLT 2.0 is best suited to accomplish this.
I was really excited by Bill Gates' 'vision' for XML and ALL related technologies 5 years ago.
I couldn't be more disappointed by hearing Microsoft turning their back on this Standard (XSLT 2.0) for IE. It would seem they have no intention of supporting much in the browser area now that the 'browser wars' are a thing of the past.Anonymous
May 20, 2004
The first i want to say that .net v2.0 is milestone product. It affect the microsoft's future more. It should be supported more standard.
The second you said more once what xslt 2.0 can do and XSLT 1.0 with EXSLT can't do.
yes it can do . but i have to spend more time to lean the fanciful and guly solution. i think xslt 2.0 can give us a more terse and smart solution.
The third you feel XQuery and not XSLT is the future of XML based query and transformation.
transformation xslt can do more then XQuery. One can't replace the other.Anonymous
May 20, 2004
XSL transformations are slow anyway!Anonymous
May 20, 2004
The comment has been removedAnonymous
May 21, 2004
@Steve Baker
MSXML is COM based technology. .NET has been out for several years now. .NET 1.0, .NET 1.1, and soon .NET 2.0 have System.Xml namespace which is mostly implemented in System.Xml.dll. I believe the discussion here is .NET 2.0 will support XQuery 1.0. If you are still doing COM programming, you should be able to interrop with .NET fairly easily, so there is no need to put it into MSXML.Anonymous
May 21, 2004
The comment has been removedAnonymous
May 21, 2004
The comment has been removedAnonymous
May 21, 2004
The comment has been removedAnonymous
May 22, 2004
I was referring to Microsoft in General not you. All I'm saying is I appreciate MS being proactively upfront with regards to their plans and not promising something that doesn't materialize. We could go down the list of times this sort of thing occurred. Anyway, relax, I wasn't insulting anyone. Keep up the good work.Anonymous
May 23, 2004
Keep an Open Eye » Microsoft Goes Astray on Standards … AgainAnonymous
May 23, 2004
Vincent Jacquet:
"transformNode does not work on the current node but always in the root node"
Oleg Tkachenko:
"That's easy problem to solve"
I know it is easy to "solve" (eventhough your solution is quite elegant), I also have a way, by modifying
the stylesheet : http://www.flowgroup.fr/tech_transformNodeWithStartingMode_us.htm.
So why something not that difficult to solve isn't in the .Net implementation while it
was a good feature in MSXML ?
More than that, my point is that I have the feeling that they have a limited vision of what can be done with XML,
especially with documents with complex content. And this is why implementing only XQuery and not XSLT 2.0
and XPath 2.0 makes me think they intent to stay in the relational type of XML files and not go to the
XML document, may be more difficult, but potentially much more powerfull.Anonymous
May 24, 2004
XQuery has nothing to do with "relational type of XML files". It operates on the exact same data model as XSLT. And please all, repeat after me: XPath 2.0 is a subset of XQuery 1.0...Anonymous
May 25, 2004
So, XPath 2.0 is a subset of XQuery 1.0? That doesn't jive with the title of this post, nor with half of the text in this post. XPath 2.0 situations can be met with alternate XQuery 1.0 functionality. It is NOT however, just a flip of the switch subset issue.
"XPath 2.0 has different semantics from XQuery, XQuery is strongly and statically typed while XPath 2.0 is weakly and dynamically typed. So it isn't simply a case that if you implementing XQuery means that you can simply flip some flag and disable a feature or two to turn it into an XPath 2.0 implementation. However all of the use cases satisfied by XPath 2.0 can be satisfied by XQuery. I"Anonymous
May 25, 2004
Chris,
XPath 2.0 is a subset of XQuery 1.0, the parts of XQuery missing are XML construction, the query prolog, the let-where-orderby parts of the FLWOR expression, typeswitch and a few other things. XPath 2.0 has a backwards compatibility mode which has different semantics from regular XPath 2.0 and XQuery. When I talked about Microsoft not implementing XPath 2.0 I meant XPath 2.0 in backwards compatibility mode since implementing XQuery means you already have regular XPath 2.0. After all, everything you can do in XPath 2.0 you can do in XQuery.Anonymous
May 25, 2004
Thanks for the clarification; which was sort of my point about the post itself. :-)Anonymous
May 25, 2004
XPath 2.0 is not a strict subset of XQuery 1.0, at least not like computer programmers think of the term "subset".
The XPath spec says that "These languages are closely related, sharing much of the same expression syntax and semantics, and much of the text found in the two Working Drafts is identical."
It doesn't say it's a subset, because it's not. The empty query is a valid XPath but not a valid XQuery. The XPath language defines all the axes, but host languages like XQuery do not have to implement them all. XPath has a namespace axis, but XQuery does not. I'm sure there are more examples out there.
Am I the only person who thinks it's funny that the URL for XPath 2.0 is
http://www.w3.org/TR/xpath20/
?
Will the URL for XPath 20.0 be
http://www.w3.org/TR/xpath200/
?Anonymous
May 25, 2004
You Microsoft guyz sound lazy and disingenuine.Anonymous
May 26, 2004
>Talbott Crowell
I do realise that this is a .net post, and that where .net is available we would abviously use that
My post was questioning the situation for CLIENT SIDE transformations in IE using msxml.
Until a .net version of IE comes out you do not have access to system.xml etc
In my view, the ability to send data as xml to a client and then transform it on the client is great and allows sites to provide application-like functionality and performance (with obvious limitations) that would simply not be possible otherwise.
It seems to be that microsoft do not see this as a key customer requirement so I guess my post should really be:
do microsoft see client side XML transformation and manipulation within IE as an important aspect fo tehir development startegy or not?Anonymous
June 01, 2004
Steve, we certainly see client-side XML transformation as a scenario. That's why we continue to invest in the performance and scalability of our XSLT 1.0 engine.Anonymous
June 02, 2004
Michael, Then start by investing in client side XSLT 2.0 engine. Then we'll think you're a hero. Certainly not by shortchanging us at a penultimate moment in the development of XSLT.
You guys at MSoft have a lot of us scratching and shaking our heads on this one.Anonymous
June 03, 2004
Michael, that is reassuring to hear. Our view is that client side transformation is a very powerfull scenario. We appreciate improvements in performance, but would also greatly appreciate some of the functionality that you cannot, without some long and slow code, get with IE6 / MSXML4 (grouping etc as included in XSLT 2)
From the reaction to the decision to not push xslt forward I would hope that this may be reflected in MS strategy.
To me though, it still seems that the question:
"How does the support for XQuery help for XML-on-the-Web? Will IE support XQuery? What am I missing?"
asked above has not really been touched on - anyone got any comments?Anonymous
June 17, 2004
Hey. SQL Server 2005 will have XQuery 1.0, and thus also XPath 2.0 support (I presume), so parsers and lexers for both are already created in Microsoft. How difficult could it be for the .NET team to surf over to the SQL Server team and look at their code?Anonymous
June 17, 2004
Sorry. I must be tired. Please ignore my last comment. SighAnonymous
June 24, 2004
The comment has been removedAnonymous
June 24, 2004
You wrote:
“…innovation and development efforts will be focused around XQuery going forward”
I guess only time will tell if this would be the right path to follow. It must have been a though decision.Anonymous
July 15, 2004
Well, here some more thought's about the subject:
http://blogs.msdn.com/mfussell/archive/2004/05/13/130969.aspx
The blogging continues :)Anonymous
July 15, 2004
For those of you who were unaware a few of us got together after Mark Fussells original post regarding MS non-support for XSLT 2.0 in .NET 2.0 and began to port Saxon 8.0-b to the .NET 1.1 framework. We reached an early beta milestone on July 5th and if all goes well with a few bug fixes and a few more feature enhancements we will be releasing a general public beta release this coming Tuesday (July 20th).
Another capability that we have planned for sometime in the near future is the ability to do client-side transformations with the Saxon.NET engine. This capability does not exist right now but is viewed as an important aspect of the overall project development and as such is going to be given all the time and attention necessary to bring it into reality as soon as humanly possible.
The projects home page is http://www.x2x2x.org/x2x2x/home. We have both a SourceForge and GotDotNET project space but to be honest we havent spent much time utilizing either from the standpoint of forum communications, CVS accessibility to the source files, bug tracking, etc... This will change in the near future when we can move our focus away from writing the code to make everything work properly and more towards tracking down bugs and increasing the performance of transformations.
One other important point to bring forward... If not already obvious the port of Saxon to .NET was done to the .NET 1.1 platform. This means that the three supported elements of Saxon 8.0 (XSLT 2.0, XPath 2.0, XQuery 1.0) will be available on the .NET 1.1 platform as well as 2.0. Obviously MS's limited support for XPath 2.0 and full support for XQuery 1.0 is only available on .NET 2.0 (as far as I know at least). While in no way was this done to thwart people from upgrading to .NET 2.0 (remember, we're all .NET developers as well and are excited about the release of .NET 2.0 and all that it brings with it) it does allow you to begin using all three technologies immediatelly, in a stable production environment.
I'm back to writing code but I wanted to quickly update some of the blog entries that focused on MS's non-support for XSLT 2.0. Forgive me if you read this exact same post on several other blogs as well as our own project blog on the project site.
<M:D/>Anonymous
January 22, 2009
PingBack from http://www.hilpers.fr/962756-xslt-2-0-et-xpathAnonymous
June 01, 2009
PingBack from http://uniformstores.info/story.php?id=17989Anonymous
June 08, 2009
PingBack from http://quickdietsite.info/story.php?id=2754Anonymous
June 16, 2009
PingBack from http://lowcostcarinsurances.info/story.php?id=1746Anonymous
June 18, 2009
PingBack from http://gardenstatuesgalore.info/story.php?id=773