.NET 3.5 doesn't completely support XPATH 2.0 or XSLT 2.0, which is just too bad. Does anyone know if these two will be included and fully supported in any future .NET versions?
+1
A:
I can't believe they won't be at some stage since they're core W3C technologies. However I can't find any current reference to these (only info posted a long time ago).
For the near future you should take a look at Saxon which supports the Xpath/XSLT versions you require.
Brian Agnew
2009-10-06 12:35:04
I would use AltovaXML instead: http://www.altova.com/altovaxml.html It's free and supports Java, .NET and WIN32 through COM. It's just that I hoped .NET would support it natively.
Workshop Alex
2009-10-06 13:59:19
AltovaXML API is useless, plus it's native code, while Saxon is managed.
Max Toro
2009-10-07 17:34:13
Altova is also slower.
Pavel Minaev
2009-10-07 17:45:33
+4
A:
See this blog post
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.
David Basarab
2009-10-06 12:35:11
That's from 5 years ago from a blog titled "Why You Won't See XSLT 2.0 or XPath 2.0 in the *Next* Version of the .NET Framework" (my emphasis)
Brian Agnew
2009-10-06 12:36:36
Thanks! Didn't notice that! Unaccepted this answer again, hoping for a newer explanation. (Although it is a good explanation so the +1 stays.)
Workshop Alex
2009-10-06 19:53:43
Nothing has really changed since then; it's the last communication on that subject, sadly.
Pavel Minaev
2009-10-07 17:46:14
That said, there are two things worth keeping in mind when dealing with XSLT in .NET: 1) it supports exslt:node-set(), which covers one of the big advantages of XSLT 2.0, and 2) msxsl:script lets you define arbitrarily complex functions directly within your XSLT using C#/VB/JScript.NET, without mucking with extensibility APIs. Since `XslCompiledTransform` uses `XPathNavigator` for node representation, and the latter fully implements XDM, you can actually implement all XPath2 functionality (like operators `<<` and `>>`) as custom functions on top of that.
Pavel Minaev
2009-10-07 17:49:10
It is not the last communication on the subject. E.g.:http://blogs.msdn.com/xmlteam/archive/2007/01/29/xslt-2-0.aspx
thorn
2009-10-15 17:42:24
+13
A:
I don't think they'll add support for XPath 2.0 or XSLT 2.0 any time soon.
However, you shouldn't feel bad if these are not part of the BCL, as long as you have 3rd party implementations available, such as Saxon (XPath 2.0, XQuery 1.0, XSLT 2.0), XQSharp (XPath 2.0, XQuery 1.0, XSLT 2.0), QueryMachine (XPath 2.0, XQuery 1.0).
Microsoft is customer oriented. If customers don't want it, they won't make it.
2009-11-18: I contacted the XML team here http://blogs.msdn.com/xmlteam/contact.aspx and got this response:
While XML continues to be a key part of our platform going forward, we have decided not to pursue an XSLT 2.0 implementation at this time. If there is a specific XSLT task you’re trying to accomplish and are having difficulty with XSLT 1.0, please let us know and we’ll do our best to help.
Max Toro
2009-10-07 17:40:11
They initially promised implementation - that's the reason why there are only few implementations because when big company like Microsoft says we will do it and we will give it to everyone as part of Windows there is no reason to program it. But then MS lost several key people in the XML Team and since then 2.0 support is dead.
CodeRipper
2010-04-20 19:57:25
+2
A:
My understanding is that many Microsoft XML resources were diverted from XSLT 2.0 onto LINQ to XML, which - in my view - doesn't address the same problem-space as XSLT at all.
LINQ to XSD was supposed to enhance LINQ to XML (as well as XML Schema benefits, the syntax is less ugly), but this was open-sourced by Microsoft onto CodePlex some time ago and appears to have no community support.
Also, its unlikely that Microsoft would launch a new XSLT 2.0 processor without an XSLT 2.0 editor and debugger integrated into Visual Studio, so quite a bit of effort/time would be required to reverse their 'non-adoption' decision.
So instead we have Saxon.NET, which has an unimpeachable standards compliance reputation and provides excellent extensibility options for .NET, especially in its latest 9.2 version. (Declared interest: My startup company, Qutoric, specialises in .NET XSLT/XPath 2.0 tools using Saxon.NET)
pgfearo
2010-01-18 18:45:07
+2
A:
Microsoft have no plans to release support for XPath/XSLT 2.0 in .NET.
XQSharp provides a 3rd party implementation of XPath 2.0, XSLT 2.0 and XQuery for .NET.
[edit: XQSharp 2.0 beta (with XSLT 2.0) has been released]
Oliver Hallam
2010-01-19 14:07:27
@Oliver-Hallam: Is this forecast still valid? Are you on track?
Dimitre Novatchev
2010-09-04 16:29:46
@Oliver-Hallam: Will XQSharp-XSLT 2.0 be faster than Saxon.NET?
Dimitre Novatchev
2010-09-04 16:31:12
@Dimitre-Novatchev - Funny you ask now; we should have a beta version of our XSLT implementation released in the next few hours! As for speed we believe our performance to be as good as Saxon, although we are biased so we would love an independent opinion!
Oliver Hallam
2010-09-06 13:19:34