为什么我会选择 XSLT 或 XQuery 而不是其他来生成 html 文档？
我正在研究使用 Microsoft 的 XslCompiledTransform 的替代方案，一切似乎都主要指向 Saxon，其次是 XQSharp。当我开始查看 Saxon 的文档时，我发现 XQuery 可以完成与我的 XSLT 相同的操作，但它远没有 XQuery 的标记那么简洁。
与 XQuery 相比，XSLT 有哪些优势值得更详细的语法？
可以创建模板功能吗？
I was researching alternatives to using Microsoft's XslCompiledTransform and everything seemed to point towards Saxon primarily and secondly XQSharp. As I started to look at documentation for Saxon I saw that XQuery could do the equivalent of my XSLTs that are no where near as terse as XQuery's markup is.
What advantages do XSLTs offer over XQuery to deserve the much more detailed syntax?
Would it be the templating functionality that can be created?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一般来说，有很多重叠之处；两者都植根于底层 XPath 实现。至于是使用 XSLT 还是 XQuery，证据就在布丁中：XSLT 更擅长转换，而 XQuery 更擅长查询。
因此，将 XQuery 用于：
数据相反，将 XSLT 用于：
In general, there's a lot of overlap; both are rooted in an underlying XPath implementation. As for whether to use XSLT or XQuery, the proof is in the pudding: XSLT is better at transforms, and XQuery is better at queries.
So, use XQuery for:
Conversely, use XSLT for:
XSLT 旨在获取一个 xml 文档并将其转换为其他内容，例如csv、html 或不同的xml 格式，例如xhtml。
XQuery 旨在从一个或多个 xml 文档中提取信息，并将结果组合到一个新的xml 文档中。
XQuery 和 XSLT 都严重依赖 XPath。如果您的输出基于一个输入 xml 文档和**一个输出 xml 文档，则两者几乎可以互换。
XQuery 的 FLWR 语法非常直观，如果您有 SQL 背景，在处理单输入/单输出情况时，IMO XSLT 是更强大的语言，特别是在输出不是 xml 的情况下。
就我个人而言，我发现基于 xml 的语法和 XSLT 的声明性性质稍微难以阅读和维护。
尽管使用 XQuery 进行“简单”格式化有点不寻常，但它实际上归结为选择。如果您的输入基于多个 xml 文档，那么您几乎会被 XQuery 困住，如果您的输出不是基于 xml，那么您几乎会被 XSLT 困住。
XSLT is designed to take one xml document and transform it into something else, e.g. csv, html or a different xml format, e.g. xhtml.
XQuery is designed to extract information from one or more xml documents, and combine the result into a new xml document.
Both XQuery and XSLT rely heavily on XPath. If your output is based on one input xml document and **one output xml document, the two can pretty much be interchanged.
The FLWR syntax of XQuery is quite intuitive, if you have an SQL back-ground, IMO XSLT is the more powerful language when dealing with one input/one output situations, especially if the output will not be xml.
Personally I find the xml based syntax and the declarative nature of XSLT slightly difficult to read and maintain.
It really boils down to choice, although using XQuery for "simple" formatting is slightly unusual. If your input is based on more than one xml document, you are pretty much stuck with XQuery, if your output is not xml based, you are pretty much stuck with XSLT.
放弃 XslCompiledTransform 的最大原因是它只是一个 XSLT 1.0 处理器。
XSLT 2.0 和 XQuery 1.0 的大部分功能是重叠的，并且大多数情况下它们是具有不同语法的相似语言（有点像 C# 和 VB）。
XSLT 更为冗长，但它的模板功能添加了许多功能，这些功能在 XQuery 中复制起来相当麻烦，特别是对节点树进行小的更改。 XQuery 中特别麻烦的主要功能是
... 只要不需要模板功能，XQuery 就有更清晰的语法（恕我直言），而且我发现它对于更高级的计算以及从大型文档中检索数据要好得多。
XQuery 通常被视为一种数据库语言。虽然许多数据库都以这种方式使用它，但这并不是它的唯一用途。该语言在数据库中的某些实现非常受限制。另一位评论者声称 XQuery 是“非常强类型的”。除非您使用静态类型功能，否则 XQuery 的类型并不比 XSLT 强。虽然某些数据库实现强制您使用静态类型功能，但大多数其他实现正在放弃这一点。
他还声称 XQuery 不太适合“更大、更复杂的事物”。我的观点恰恰相反。语法的简洁性和风格使得在 XQuery 中编写复杂的函数和计算变得更加容易。我在XQuery中编写了一个raytracer，感觉非常自然；我认为在 XSLT 中编写计算复杂的东西会更困难（当然更冗长）。
综上所述：
XSLT 对于转换来说更加自然。如果您有一个结构大致正确的文档，并且您想要转换组件，例如呈现 XML 文件的 HTML 版本，那就更好了。
XQuery 更适合从各种来源构建新的 XML 文档，或者更改文档的结构。
请注意，重叠相当大，并且通常没有“正确”的选择，但如果您做出错误的选择，那么您往往会发现自己的工作与实际情况背道而驰。
The biggest reason to move away from
XslCompiledTransformis that it is merely an XSLT 1.0 processor.The majority of the functionality of XSLT 2.0 and XQuery 1.0 overlaps, and for the most part they are similar languages with different syntax (a little like C# and VB).
XSLT is a lot more verbose, but its templating features add a lot of functionality that can be fairly cumbersome to replicate in XQuery, particularly making small changes to node trees. The main features that are particularly cumbersome in XQuery are things like
<xsl:template match="..." />and<xsl:copy>...</xsl:copy>.XQuery has a much cleaner syntax (IMHO) as long as the templating features are not needed, and I find it is a lot better for more advanced computations, and retrieving data from large documents.
XQuery is often viewed as a database language. Whilst a lot of databases use it this way, it is not the only use for it. Some implementations of the language in databases are very restricted. Another commentor claims that XQuery is "very strongly typed". Unless you are using the static typing feature, XQuery is no more strongly typed than XSLT. Whilst some database implementations force you to use the static typing features, most other implementations are moving away from this.
He also claims that XQuery is not very good for "larger, more complicated things". I would have argued exactly the opposite. The conciseness and flavour of the syntax makes it far easier to write complicated functions and computations in XQuery. I have written a raytracer in XQuery, which feels really quite natural; I think it would be a lot harder (certainly more verbose) to write something this computationally complex in XSLT.
In summary:
XSLT is more natural for transformation. It is better if you have a document with roughly the right structure and you want to transform the components, for example rendering an HTML version of an XML file.
XQuery is more natural for building a new XML document from various sources, or for changing the structure of a document.
Note that the overlap is rather large and there is often no "right" choice, but if you make the wrong choice then you to tend to find yourself working against the grain.
XSLT 和 XQuery 做两件不同的事情。 XSLT，顾名思义，用于将数据从一种形式转换为另一种形式（例如从XML 到HTML）。另一方面，XQuery 是一种用于从 XML 文档中查找和提取某些 XML 节点的语言，然后可以将其用于多种目的。
XSLT实际上依赖于XQuery的功能，请查看www.w3schools.com上的教程；如果使用得当，它们都是非常强大的技术。
XSLT and XQuery do two different things. XSLT, as the name suggests, is used to transform data from one form into another (e.g. from XML to HTML). On the other hand, XQuery is a language used to find and extract certain XML nodes from an XML document, which can then be used for any number of purposes.
XSLT actually relies on the functionality of XQuery, take a look at the tutorials on www.w3schools.com; when used correctly, they are both very powerful technologies.