用于.NET的XPath和XSLT 2.0?

Wim*_*ink 90 .net xslt xpath

.NET 3.5并不完全支持XPATH 2.0或XSLT 2.0,这太糟糕了.有谁知道这两个将在未来的.NET版本中被包含和完全支持吗?

Max*_*oro 129

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

但是,如果这些不是BCL的一部分,您应该感觉不好,只要您有第三方实施可用:

微软以客户为导向.如果客户不想要它,他们就不会成功.


2009-11-18:我在这里联系了XML团队 并得到了这样的答复:

虽然XML仍然是我们平台未来的关键部分,但我们决定此时不再采用XSLT 2.0.如果您正在尝试完成特定的XSLT任务并且在使用XSLT 1.0时遇到困难,请告诉我们,我们会尽力提供帮助.


此列表现在保存在github.com/maxtoroq/dotnet-xml

  • 他们最初承诺实施 - 这就是为什么只有很少的实施,因为当像微软这样的大公司说我们会这样做,我们会把它作为Windows的一部分给每个人,没有理由对其进行编程.但随后MS在XML团队中失去了几个关键人物,从那时起2.0支持已经死亡. (21认同)
  • 这个答案看起来非常熟悉 - 几年前我问了一个类似的问题并得到了同样的答案.羞耻 - XSLT 2.0看起来是对语言可用性的一个相当重要的改进. (6认同)
  • 如果他们真正以客户为导向,他们就会这么做。这是他们的 UserVoice 中获得最多支持的问题之一。每个人都在乞求它。XSLT 并不是一个小众领域,它在大多数信息系统课程中都有教授。它是一种基本的数据交换格式。 (3认同)
  • 仅供参考:.Net 核心功能请求:https://github.com/dotnet/corefx/issues/2295 用于 XPath/XSLT v2 & 3 支持。 (2认同)

Dav*_*rab 23

看到这篇博文

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

实现所有3种技术(XQuery,XSLT 2.0和XPath 2.0)需要大量的精力和资源.我们的指导原则是,我们认为创建大量XML查询技术会让最终用户感到困惑.除了.NET Framework中已经存在的XPath 1.0和XSLT 1.0之外,我们宁愿实现一种我们推动人们学习的语言,而不是支持和解释三种XML查询和转换语言.让我们的客户和支持人员必须处理3种复杂的XML查询语言的复杂性,其中两种看起来相似,但在XPath 2.0和XQuery的情况下表现相当不同似乎对我们没那么有用.

  • 那是5年前的一篇名为"为什么你不会在.NET Framework的*Next*版本中看到XSLT 2.0或XPath 2.0"的博客(我的重点) (11认同)
  • 2013年,没有变化:( (9认同)
  • 也就是说,在.NET中处理XSLT时,有两件事值得记住:1)它支持exslt:node-set(),它涵盖了XSLT 2.0的一大优势,以及2)msxsl:脚本可以让你使用C#/ VB/JScript.NET直接在XSLT中定义任意复杂的函数,而不会破坏可扩展性API.由于`XslCompiledTransform`使用`XPathNavigator`进行节点表示,而后者完全实现了XDM,因此您可以将所有XPath2功能(如运算符`<<`和`>>`)实现为自定义函数. (3认同)

pgf*_*aro 12

我的理解是,许多Microsoft XML资源从XSLT 2.0转移到LINQ to XML,在我看来,它根本没有解决与XSLT相同的问题空间.

LINQ to XSD应该增强LINQ to XML(以及XML Schema的好处,语法不那么难看),但是这是微软前一段时间开源的CodePlex,似乎没有社区支持.

此外,微软不太可能在没有将XSLT 2.0编辑器和调试器集成到Visual Studio中的情况下推出新的XSLT 2.0处理器,因此需要相当多的努力/时间来扭转他们的"不采用"决策.

因此,我们拥有Saxon.NET,它具有无可比拟的标准合规性声誉,并为.NET提供了出色的可扩展性选项.