.NET 的 XPath 和 XSLT 2.0？ [关闭]

Posted 2023-02-16

【中文标题】.NET 的 XPath 和 XSLT 2.0？ [关闭]

【英文标题】：XPath and XSLT 2.0 for .NET? [closed]

【发布时间】：2010-12-04 06:17:13

【问题描述】：

.NET 3.5 不完全支持 XPATH 2.0 或 XSLT 2.0，这太糟糕了。有谁知道这两个是否会在未来的任何 .NET 版本中包含并完全支持？

【问题讨论】：

codeproject.com/Articles/24766/… Java saxon 库实现了 XSL 2.0 和 XQuery 1.0。使用 IKVM 和 GNU Classpath，您可以在 .NET 中访问此库。但是，使用 Saxon 的接口与您在 .NET 中使用的接口非常不同。从这篇文章页面，您可以下载接口适配器，它们有助于弥合 Saxon 接口和 .NET XslCompiledTransform 之间的差距。这反过来又使得将代码从使用 .NET XSL 1.0 移植到 Saxon XSL 2.0 变得更加容易。

您可以通过微软在uservoice 发布此功能请求

【参考方案1】：

我认为他们不会很快添加对 XPath 2.0 或 XSLT 2.0 的支持。

但是，如果这些不是 BCL 的一部分，您应该不会感到难过，只要您有可用的 3rd 方实现：

Saxon：XPath 3.1、XQuery 3.1、XSLT 3.0 XmlPrime：XPath 3.1、XQuery 3.1、XSLT 2.0 QueryMachine：XPath 2.0，XQuery 1.0 Lightweight XPath2 for .NET: XPath 2.0 Exselt: XSLT 3.0

Microsoft 以客户为导向。如果客户不想要，他们就不会成功。

---

2009-11-18：我联系了 XML 团队 here 并得到了回复：

虽然 XML 仍然是关键部分 在我们平台的未来发展中，我们有 决定不追求 XSLT 2.0 此时执行。如果有 是您正在尝试的特定 XSLT 任务 完成并且正在拥有 XSLT 1.0 的困难，请让 我们知道，我们会尽力提供帮助。

---

此列表现在维护在github.com/maxtoroq/dotnet-xml

【讨论】：

他们最初承诺实施 - 这就是为什么只有很少实施的原因，因为当像微软这样的大公司说我们会这样做并且我们会将它作为 Windows 的一部分提供给每个人时，没有理由进行编程它。但随后 MS 在 XML 团队中失去了几个关键人物，从那时起 2.0 支持就消失了。

这个答案看起来非常熟悉 - 几年前我问了一个类似的问题并得到了相同的答案。耻辱 - XSLT 2.0 看起来像是对语言可用性的一个相当重要的改进。

真正的问题是，这些第 3 方选项都没有更新为在 .NET Standard/Core 上运行——其中一些基于 JKVM，这意味着它们不能 更新。考虑到您在那里链接了多少第三方商业产品，我不确定“以客户为导向”这一行能解释什么..

如果他们真正以客户为导向，他们就会这样做。这是他们的 UserVoice 中最受好评的问题之一。每个人都在乞求它。 XSLT 不是小众，它在大多数信息系统课程中都有讲授。这是一种基本的数据交换格式。

仅供参考：.Net 核心功能请求：github.com/dotnet/corefx/issues/2295 支持 XPath/XSLT v2 和 3。

【参考方案2】：

看到这个blog post

我们有几个原因 没有实现 XSLT 2.0 和 XPath 2.0

这需要大量的精力和资源 实施所有 3 项技术 （XQuery、XSLT 2.0 和 XPath 2.0）。我们的 指导原则是我们相信 创建 XML 查询的扩散 技术令人困惑 用户。我们宁愿再实施一个 我们推动人们学习的语言 比必须支持和解释三个 更多 XML 查询和转换 语言，除了 XPath 1.0 和 XSLT 1.0 中已经存在 .NET 框架。拥有我们的客户 和支持人们必须应对 3 复杂 XML 的复杂性 查询语言，其中两种是look 相似但行为完全不同 对于 XPath 2.0 和 XQuery 在我们看来并非如此 有益的。

【讨论】：

这是 5 年前的一篇博客，标题为“为什么在 .NET Framework 的 Next 版本中看不到 XSLT 2.0 或 XPath 2.0”（我的重点）

谢谢！没注意到！再次不接受这个答案，希望有更新的解释。 （虽然这是一个很好的解释，所以 +1 仍然存在。）

也就是说，在 .NET 中处理 XSLT 时有两点需要牢记：1) 它支持 exslt:node-set()，它涵盖了 XSLT 2.0 的一大优势， 2) msxsl:script 允许您使用 C#/VB/JScript.NET 在 XSLT 中直接定义任意复杂的函数，而无需使用可扩展性 API。由于XslCompiledTransform 使用XPathNavigator 表示节点，而后者完全实现了XDM，因此您实际上可以将所有XPath2 功能（如运算符<< 和>>）作为自定义函数实现。

这不是关于该主题的最后一次交流。例如：blogs.msdn.com/xmlteam/archive/2007/01/29/xslt-2-0.aspx

2013，没有变化:(

【参考方案3】：

我的理解是，许多 Microsoft XML 资源从 XSLT 2.0 转移到 LINQ to XML，在我看来，这根本无法解决与 XSLT 相同的问题。

LINQ to XSD 应该增强 LINQ to XML（以及 XML Schema 的好处，语法不那么难看），但这是微软不久前在 CodePlex 上开源的，似乎没有社区支持。

此外，如果没有将 XSLT 2.0 编辑器和调试器集成到 Visual Studio 中，Microsoft 不太可能推出新的 XSLT 2.0 处理器，因此需要相当多的努力/时间来扭转他们的“不采用”决定。 [更新] 现在有一个XSLT 3.0 extension for Microsoft VSCode（由我自己管理），它与 Saxon 的 3.0 XSLT 处理器集成。

因此，我们选择了 Saxon.NET，它在标准合规方面享有无可挑剔的声誉，并为 .NET 提供了出色的可扩展性选项。

【参考方案4】：

Microsoft 没有计划在 .NET 中发布对 XPath/XSLT 2.0 的支持。

XQSharp 提供 XPath 2.0、XSLT 2.0 和 XQuery for .NET 的第 3 方实现。

[编辑：XQSharp 2.0 beta（带有 XSLT 2.0）已经发布]

【讨论】：

@Oliver-Hallam：这个预测还有效吗？你步入正轨了吗？

@Oliver-Hallam：XQSharp-XSLT 2.0 会比 Saxon.NET 更快吗？

@Dimitre-Novaatchev - 你现在问很有趣；我们应该会在接下来的几个小时内发布 XSLT 实现的 beta 版本！至于速度，我们相信我们的表现与撒克逊人一样好，尽管我们有偏见，所以我们希望获得独立的意见！

XQSharp 现在更名为 XMLPrime

【参考方案5】：

我不敢相信它们不会处于某个阶段，因为它们是 W3C 的核心技术。但是我找不到任何当前对这些的引用（只有很久以前发布的信息）。

在不久的将来，您应该看看Saxon，它支持您需要的 Xpath/XSLT 版本。

【讨论】：

我会使用 AltovaXML：altova.com/altovaxml.html 它是免费的，并且通过 COM 支持 Java、.NET 和 WIN32。只是我希望 .NET 能够原生支持它。

AltovaXML API 没用，加上它是本机代码，而 Saxon 是托管的。

Altova 最大的问题是他们拒绝正确实现只保留文本节点的空白。