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 (70)

  1. Well, that sounds fair enough for me.

    And as Mark said "The next 5 years will tell whether this assertion was correct."

  2. Drew Marsh says:

    I applaud the decision to attempt to go best of breed on just the one technology. Also, let’s not forget Microsoft isn’t the only software company out there. Nothing is preventing anyone from writing a third party product that provides full support for these other technologies. If the demand is high enough, then whoever ends up implementing them has a chance to make some serious bank.

  3. 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:


    Regards, Pieter

  4. Arpan Desai says:

    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.

  5. Michael Rys says:

    Still, we could have left the site up and have a simple page explaining that people should get themselves signed up for the beta.

  6. Michael Rys says:

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

  7. Ryan Heath says:

    "A public beta release of the .NET Framework is scheduled shortly"

    That sounds good!

    but how short is shortly ? 😉

  8. Vincent Jacquet says:

    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.

  9. Me says:

    I agree 100% with 1st and 2nd paragraphs in Pieter Siegers post (5/13/2004 6:54).

    XSLT and XQuery are indeed 2 different things.

    Reading that "It takes a lot of effort and resources to implement all 3 technologies …", sounds particularly ironic to a common developer like me.

    If the all-mighty MicroSoft is complaining about effort and resources for THREE CORE XML technologies, what is the common developer to say about keeping up-to-date with the constant flood of new standards, technologies, APIs, products, that seem to pop-up like mushrooms?

    I am afraid that in the future, the very same reasoning exposed above by Dare Obsasanjo, could be re-used again and again by Microsoft, to justify not supporting any new standard or technology, when it does not fit its interests.

    Thinking about it all, when will Microsoft support (out-of-the-box, whithour 3rd-parties), some other long-awaited standards (XForms,RDF – just to name two)?

  10. Julian Reschke says:

    How does the support for XQuery help for XML-on-the-Web? Will IE support XQuery? What am I missing?

  11. 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



    The reason that XML is successful is because we discount any alternative, even if it is superior.

  12. 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?

  13. Sheesh. "Thank you for"…

  14. LooksLikeJava says:

    At least you were honest this time.

  15. "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…

  16. Michael Rys says:

    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.aspx

  17. anonymous coward says:

    What about XPath 2.0 support in XQuery?

  18. 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.

  19. Nikolay Kolev says:

    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!

  20. 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 ??


  21. 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 ??


  22. 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.html

  23. Boy, this makes me sad. I love the .NET framework, and grow more and more fond of it the more I work with it, and the more I realize that the people behind it actually understand what the users want (e.g. XHTML validity in ASP.NET).

    This is a hard blow in the face, as I’ve been hoping, wating and almost rejoicing at the next version of .NET which of course would have support for XSLT 2.0, XPath 2.0 and XQuery. But there I was wrong, it seems.

    XQuery support is mighty fun, but not being able to exploit the extreme strength of XSLT 2.0 and XPath 2.0 is really dull. And besides being dull, it makes my faith in Microsoft’s .NET initiative weaker, as I saw the framework as one of the major "pushers" of new technology.

    Anyway, I hope this decision is only for the next version of .NET, and not all future versions. It would be really miserable not being able to utilize technologies like XPath 2.0 and XSLT 2.0 in .NET. Ever. :-

  24. Nikolay Kolev says:

    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.

  25. Asbjorn & Nikolay,


  26. Michael Rys says:

    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.


    PS: If I go home today and tell my wife, I need a new car, she will ask me the same questions :-)…

  27. Gurbhajan S. Bagh says:

    How can Microsoft claim they love XSLT, when one of the new key guys claims to hate it.

    Read the tag line in Don’s banner under his name.


  28. Rich Sabo says:

    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.

  29. Steve Baker says:

    A few posters here have asked about XQuery support in IE but with no replies.

    I get the point about XQuery being great if you want to get data from a repository (ie SQL Server) and that in the strongly typed application world it has many advantages.

    However, when you move to the task of presenting data to clients then I believe that xslt is unsurparsed. We use it a lot to take data as xml and transform it on the client using MSXML4. This allows us to reduce server load, and give a much richer user experience (ie sorting / alternate view of the smae data without any server roundtrips)

    I take the point that xslt 1.0 / xpath 1.0 can perform most of these tasks, but many of the new features in v2 would dramatically increase performance + simlicity of development. Without installing 3rd party components (not really acceptable on a client machine) we cant utilise exslt.

    Will msxml ever be improved or is v4 the last word? I have heard many rumours about IE 6 being the same status – is that true or just one for another blog???

  30. sk says:

    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.


  31. John Meyers says:

    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.

  32. Michael,

    The answer is currency.

  33. Chris says:

    > 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. 🙂

  34. Cal says:

    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.

  35. zhuiqiu111 says:

    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.

  36. xsl mongrel says:

    XSL transformations are slow anyway!

  37. Dennis K says:

    Adam Bosworth was responsible for XML at Microsoft. That’s why their XML work was so strong 5 years ago. I still remember his presentation at TechEd about XML features in IE and SQL Server (he was responsible for both!)

    But five years is a long time. Adam left Microsoft for BEA, and XML at Microsoft hasn’t been the same ever since. They used to have regular releases of MSXML and SQLXML online, but both have dried up. What happened?

    I think Microsoft isn’t implementing XSLT 2.0 and XPath 2.0 not because they want to force developers away from them, or because these languages aren’t important or useful, but because of the reason Dare and Mark Fussell cited – the XML team lacks the resources (i.e., isn’t competent enough) to do the work.

    Their XQuery demo was crap, and the current beta isn’t much better. Saxon (Michael Kay’s implementation) is far more complete and up-to-date. How is it that one guy in his spare time can do more than an entire team of engineers at Microsoft?

    Also, note that according to his blog, Don Box doesn’t even work for the XML team — he works for Indigo. Why didn’t he join the XML team? All the XML action at Microsoft must be happening there, instead of the old XML team.

  38. Talbott Crowell says:

    @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.

  39. John Meyers says:

    > Don’t forget XHTML and CSS2. 🙂

    Well, we haven’t migrated to .NET 1.1 yet because the above are still, more than 5 years after they became a standard, not supported (not to mention the total invalid HTML 4.0 VS.NET & ASP.NET 1.1 generates currently).

    From the looks of it at least XHTML will get some kind of support in .NET 2.0 but we will wait until the final product to evaluate what Redmond really put into the final release.

    We are an institution that builds Web applications going with the standards to support any browser, any operating system on any device (wasn’t that something Bill Gates said in the past?).

    We don’t build Web applications for a particular browser or do you build streets in a way that only a particular car can drive on it and then tell all your customers who complain that this is according to your toll-gate camera statistic the most used car on your street?

  40. ANON says:

    The First line of code on EVERY eBay auction ???

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

  41. Nikolay Kolev says:

    I’m sorry to say that, but Microsoft really disappoints recently.

    I hope that they will change their mind and that the new VS.NET will be finally a modern IDE. Now everybody has a better IDE – Sun with the Rave project, IBM with Eclipse, even IntelliJ is more convenient to use…

    As some of you guys said, it’s amazing how one or just few developers can build much more mature and vital products!

    I get sick when have to use Source Safe – ugly as hell (looks like a Win 3.0 app), limited functionality, does not support WebDAV, does not work over the web and so on.

    It seems that M$ really turned back on the developers! It’s a real pity!

  42. LooksLikeJava says:

    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.

  43. Anonymous says:

    Keep an Open Eye &raquo; Microsoft Goes Astray on Standards &#8230; Again

  44. Vincent Jacquet says:

    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.

  45. Michael Rys says:

    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…

  46. Chris says:

    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"

  47. 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.

  48. Chris says:

    Thanks for the clarification; which was sort of my point about the post itself. 🙂

  49. this is fubar says:

    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



    Will the URL for XPath 20.0 be



  50. NotaLazyGuy says:

    You Microsoft guyz sound lazy and disingenuine.

  51. Steve Baker says:

    >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?

  52. Michael Rys says:

    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.

  53. XSLTguy says:

    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.

  54. Steve says:

    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?

  55. 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?

  56. Sorry. I must be tired. Please ignore my last comment. *Sigh*

  57. Harold says:

    For example, XSLT 1.0 does not support "disable-output-escaping" in attributes. This would be very helpful; if MS doesn’t support XSLT 2.0, we’ll be out of luck, unless we can resort to another XSLT engine or hack it together with the MSSCRIPT elements.

  58. 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.

  59. Ted James says:

    Well, here some more thought’s about the subject:


    The blogging continues 🙂

  60. 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.