XPath and XSLT are important technologies used for querying and transforming XML data. However, it seems that Microsoft has no plans to add support for XPath 2.0 or XSLT 2.0 in the near future. This may be disappointing for developers who rely on these advanced features.

Fortunately, there are third-party implementations available that provide support for XPath 2.0 and XSLT 2.0. Some of these implementations include Saxon, XmlPrime, QueryMachine, Lightweight XPath2 for .NET, and Exselt. These libraries offer a range of capabilities, including XPath 3.1, XQuery 3.1, and XSLT 3.0.

In 2009, the XML team at Microsoft confirmed that they had decided not to pursue an XSLT 2.0 implementation. They offered to assist developers who were struggling with XSLT 1.0, but made no promises about future versions. It appears that the team lost key members, which may have contributed to the lack of support for XPath 2.0 and XSLT 2.0.

While there are several third-party options available, one issue is that many of these implementations have not been updated to run on .NET Standard/Core. This means that they cannot be used in newer versions of the .NET framework. This limitation may be frustrating for developers who want to take advantage of the latest features in XPath and XSLT.

Some argue that the lack of support for XPath 2.0 and XSLT 2.0 in the BCL (Base Class Library) is due to Microsoft's focus on pleasing a broad market with general-purpose tools. They believe that XSLT is a niche technology and that Microsoft prioritizes features that cater to a larger audience.

However, others argue that Microsoft should prioritize customer demands, and that there is significant demand for XPath 2.0 and XSLT 2.0 support. They point out that XSLT is commonly taught in information systems classes and is a fundamental technology for data interchange.

It is worth noting that there is an open feature request on GitHub for XPath/XSLT v2 and v3 support in .NET Core. This indicates that there is ongoing interest and demand for these features among the developer community.

In conclusion, while Microsoft does not currently provide support for XPath 2.0 and XSLT 2.0, there are third-party implementations available that offer these capabilities. Developers may need to explore these options if they require the advanced features of XPath and XSLT.

在这篇文章中，作者谈到了为什么他们没有实现XSLT 2.0和XPath 2.0的几个原因。首先，实现这三种技术（XQuery，XSLT 2.0和XPath 2.0）需要大量的时间和资源。作者认为，创建多种XML查询技术会对终端用户造成困惑，他们更愿意实现一种语言并推动用户学习，而不是支持和解释另外三种XML查询和转换语言，除了已经存在于.NET Framework中的XPath 1.0和XSLT 1.0。其次，XPath 2.0和XQuery在行为上有很大的不同，这会给客户和支持人员带来复杂性。

虽然这篇文章发表于5年前，但是作者指出自那以后并没有太多变化，这是关于这个问题的最后一次交流。然而，针对在.NET中使用XSLT，作者提到了两个值得注意的事情。首先，.NET支持exslt:node-set()，这涵盖了XSLT 2.0的一个重要优势。其次，msxsl:script允许您在XSLT中直接定义任意复杂的函数，使用C#/VB/JScript.NET，而不需要对扩展性API进行干预。由于XslCompiledTransform使用XPathNavigator作为节点表示，而XPathNavigator完全实现了XDM，实际上可以在其之上实现所有XPath2功能（如运算符<<和>>）作为自定义函数。

从这些信息来看，微软目前仍然没有完全支持XPath和XSLT 2.0。这可能是因为他们认为实现这些技术需要大量的资源，并且有可能会给用户带来困惑。然而，他们提供了一些替代方案，如使用exslt:node-set()和msxsl:script来实现类似的功能。

XPath and XSLT 2.0 for .NET这个问题的出现的原因是因为许多Microsoft的XML资源被转移到了LINQ to XML上，而LINQ to XML并没有解决与XSLT相同的问题领域。此外，LINQ to XSD本应增强LINQ to XML，但Microsoft在一段时间前将其开源到CodePlex上，并且似乎没有得到社区的支持。此外，Microsoft不太可能推出一个没有将XSLT 2.0编辑器和调试器集成到Visual Studio中的新的XSLT 2.0处理器，因此需要相当大的努力和时间来扭转他们的“不采用”决定。因此，我们使用了Saxon.NET，它具有无可置疑的标准兼容性声誉，并为.NET提供了出色的可扩展性选项。