.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?
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.
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.
Microsoft is customer oriented. If customers don't want it, they won't make it.
2009-11-18: I contacted the XML team here 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.
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. [Update] There's now an XSLT 3.0 extension for Microsoft VSCode(managed by myself) that integrates with Saxon's 3.0 XSLT processor.
So instead we have Saxon.NET, which has an unimpeachable standards compliance reputation and provides excellent extensibility options for .NET.