Please -please- tell me .NET 4.0 will handle XSLT 2.0/XPath 2.0

Question

Now that .NET 4 is coming out, is there any plans to bring the .NET XSLT processor up to date?
.NET's XSLT engine used to be an industry leader offering very fast performance, but the fact that Microsoft has not kept it up to date (the MS transformation engine cannot handle XSLT 2.0/XPath 2.0) has caused a number of problems.
I'll use Saxon if I have to, but I'd truly love to use the .NET performance tools with up to date XSLT.

Answer 1

.NET 4/Visual Studio 2010 is out in a public beta 2 version. The only XSLT specific change I am aware of is that xsltc allows signing, as announced here http://social.msdn.microsoft.com/Forums/en-US/xmlandnetfx/thread/88f3a46c-2c80-4101-9923-54a0d9792fad
If you want XSLT and/or XPath 2.0 you will need to use third party solutions (but you don't have to wait for .NET 4.0). You are already aware of Saxon, there is also AltovaXML tools providing XSLT 2.0 and XQuery 1.0 via COM interop, and for XPath 2.0 and XQuery 1.0 there is also XQSharp .

---

MVP XML My blog

Answer 2

Why has Microsoft allowed it's investment in XSLT to whither?
Is it because they are trying to encourage the use of proprietary technologies such as Linq and F#?
From what I saw at DevConnections, Microsoft is investing in XML more and more.  It just makes sense to me that they'd be interested in maximizing that investment by making use of XSLT/XPath - the best technology in the industry for transforming XML.
I'm not trying to be snide here, I'm just trying to understand the rationale.  The reality is, Microsoft still has a hegemony over the industry and, while that hegemony is coming under greater and greater attack from companies like Apple and Google, Microsoft still has a great deal of control over which way the wind is blowing.  If I could get in their heads and figure out what they are thinking and why - if they'd have a dialogue with the people who use .NET and explain what they are doing - it'd help me as a developer.

I guess what I'm looking for is a reason to be a little less disenchanted with .NET.  I'm far too often running into things .NET doesn't allow - whether it is using the full 64bit capability in an application which connects to MS Access or creating an XML Pipeline or creating a secure software application which actually disposes of vulnerable data in a reliable and safe manner when you tell it to or any of a number of other things, I usually discover that .NET can't do it.  It seems like, unless a developer's software design fits within a very narrow design horizon, it's better just to use something besides .NET and, well, it's frustrating.  Especially since the reason this seems to happen more often than not is that Microsoft ignores industry standards (such as XSLT) and keeps trying to reinvent the wheel (such as with Linq) and, when they reinvent the wheel, they have to start over from scratch so they never get as far as if they embraced industry standards (and, hence, made use of the lessons learned therefrom).

I find irrationality frustrating.  If Microsoft would give a sensible explanation for what it's thinking, it would help a great deal.  Because I can handle differences of opinion.  What I have trouble dealing with is things which just don't make sense.

Answer 3

I think that it is not true that Microsoft has given up on advancing XML technologies.  Case in point:  the next Visual Studio IDE will include a completely new and comprehensive XML schema editor.  This is not something someone would do if they wanted to stop investing in XML standards!  On the other hand, XML programmability enhancements are clearly not a major component of the .NET 4.0 release.  I for one would like to see better support for XML schema-object mapping (that is, a new iteration of the XmlSerializer kind of technology).  Sure there are frustrations.  We all want everything right now, but sometimes patience is in order.

I wouldn't underestimate LINQ, including LINQ to XML (XDocument).  It doesn't sound like you have used it much, but it is generally much better than XmlDocument.  Also nice is its XML integration with VB (if you happen to be using that language), a feature that I'd love to see brought into C# as well.

> they have to start over from scratch so they never get as far as if they embraced industry standards

These standards are often the results of design-by-committee with lots of compromises and inconsistencies that do not make sense technically.  Sadly, they often show what not to do.  For example, see the XML Schema specification.  But yes I will agree that it is nonetheless important to keep up with the standards while at the same time advancing elegant features like LINQ.

Answer 4

If Microsoft were to follow the design path set by these design-by-committee open standards, rather than go along a completely different path, they could build upon the successes and failures of those design-by-committee open standards and achieve more functionality with them than could be done by starting from zero all over again.
That's my point.
I look over the past ten years and I see case after case of Microsoft trying to reinvent the wheel, ending up with a poorly functioning mess, and going back to reinvent the wheel all over again.  .NET Web forms are a case in point (most people in the world are behind low bandwidth, have you ever gained any substantial benefit from using .NET web forms where your Internet connection is poor - that is, without disabling nearly all the features of .NET web forms? - not to mention all the problems with leaky abstraction).  LINQ is another.  There are too many problems with object-relational models to even begin describing (for starters, you maintain two or more seperate sets of objects if you want the data model to be present in more than one environment - for example in JavaScript (for the client) and C# (for the server)).  SOAP is yet another (who ever decided it was a good idea to write a protocol which goes through security like butter - unless you, again, reinvent the wheel all over again by implementing (what's the current number, 23?) different web service protocols all over again - ought to be taken out behind the barn and shot like Ol' Yeller).
In many cases, Microsoft has learned its lesson.  Developers now have an alternative to .NET Web forms (.NET MVC - have you ever noticed that .NET MVC looks a lot more like classic ASP then Web forms do?) and SOAP (.NET is implementing REST more and more - ie. the way the web is suppossed to work) - of course, they are playing catch up because they sunk so many resources into trying to reinvent the wheel.  And, yet, they keep trying to reinvent the wheel.  How's that old joke go?  "Doctor, doctor, it hurts when I do this!"  "Well, don't do that!"

Answer 5

We have have just released a beta version of XQSharp 2.0.

XQSharp is an implementation of XSLT 2.0 (new in this version), XQuery and XPath 2.0 for the .NET Framework.  It is free for non-commercial use.  Visit http://www.xqsharp.com/ for more information.

We are not quite as fast as the XSLT 1.0 implementation built into .NET, but we are however at least as fast as any other XSLT 2.0 implementation available for .NET.  We are working on compiling to MSIL byte code, and when this is finished we hope to have performance comparable with the built in XSLT 1.0.

Answer 6

Xslt 2.0 /XPath 2.0 is not a part of .NET 4.0.

Thanks,

Zoya

---

This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 7

Thank you very much for your question. Unfortunately, as you are aware that XSLT 2.0 and XPath 2.0 support are not in .NET 4.0. 

We are actively looking at the bring our XML technology stack(s) upto the current standards/editions, XSLT 2.0 and XPath 2.0 being on top of the list. We will communicate it out to the developer community once the roadmap is finalized.

Once again, thank you very much for your suggestions and participations in our forum!

Thanks

Allen

Answer 8

Any update if/when Microsoft is going to implement this?

Answer 9

While it seems like it's beating a 3+ year old dead horse I would like to chime in on my interest in if/when/what plants for Xslt 2.0 Microsoft has.

Answer 10

Any news on Microsoft's XML technology stack?

Answer 11

MSFT - I am also looking to beat the dead (but hopefully not rotting) horse... anything planned for .NET4.5/5.0's support for XSLT 2.0 to bring her back to life?  TIA.

---

DCFx

Answer 12

I am also looking for an update on .NET 4.0 plus using XPath 2.0.  Why?  I want to use schematron to validate basic business rules in .NET. and not be limited to number comparisons.

All I want to do is compare Dates and DateTimes and not have to convert it to a number and use the > or < operators...

I guess I will have to use Saxon (another 3rd part tool) to do this.

Answer 13

If you're using XPath in XSLT and are interested in needing extended functions you have a lot of options available to you. http://msdn.microsoft.com/en-us/magazine/cc302079.aspx shortened version of the article specific to C# and XSLT http://our.umbraco.org/wiki/reference/xslt/extend-your-xslt-with-custom-functions

You don't necessarily need to use XSLT files either. If you wish to extend XPath with functions you can use similar functionality to create advanced xpath functions and utilize it in your xpath queries.

http://www.codeproject.com/Articles/15372/Custom-XPath-Functions

Again, not the most ideal solution if what you're doing is something that could be doine by the latest XPath implementations (if it were implemented) but it might be less costlier than switching to a 3rd party tool/library that may or may not be free but may require lots of effort to integrate.

Still however, it really would behoove Microsoft to implement the latest standards for XSLT and Xpath - especially since XDocument ended up being so horrible from a developer perspective (imho) and virtually unusable and definitely extremely pain filled and not very extensible or intuitive.

Answer 14

Thanks for the reply.

I believe the solution from http://our.umbraco.org/wiki/reference/xslt/extend-your-xslt-with-custom-functions umbraco require an installation of some 3rd party package also.  If true, how does that compare to using a 3rd party install like Saxon?  Is Umbraco easier to implement?

Answer 15

As far as I am aware it does not. If you read the first MSDN link I provided you will see that the code Umbraco shows that references no UMBRACo components mimics 2 code snippets that are used in the MSDN link. From my understanding they are merely showing you a MS technology  that you can leverage while extending UMBRACO.

Additionally as I said in my prior statement, if you're not using XSLT and just want XPATH the 3rd link (CodeProject) that i provided is probably more relevant.

This was the XSLT Extensible link I was actually originally looking for. http://www.pedautreppe.com/post/Calling-C-function-in-XSL.aspx

I think this method mirrors one of the ways provided in the first 2 links, it just is a bit more cleaner (imho) (if you're going the XSLT route).

Answer 16

I would like to see XSLT 2.0 as well, or at least the ability to output XHTML with XSLT 1.0.

Internet Explorer appears to support 2.0 and <xsl:output method="xhtml"

Why not VS/.NET?