XSLT 值得吗？ - 开卷题库

小开

XSLT 规范将 XSLT 定义为“将 XML 文档转换为其他 XML 文档的语言”。除了 XSLT 中最基本的数据处理之外，如果您试图做任何事情，那么可能有更好的解决方案。

Also worth noting that the data processing capabilities of XSLT can be extended in .NET using custom extension functions:

小开

我仍然相信 XSLT 是有用的，但是它是一种丑陋的语言，并且会导致可怕的无法阅读、无法维护的混乱。部分原因是 XML 不具备构成“语言”的人类可读性，部分原因是 XSLT 处于声明性和过程性之间。尽管如此，我认为可以用正则表达式进行比较，它在处理定义良好的简单问题时有其用处。

在代码中使用替代方法和解析 XML 可能同样令人讨厌，而且您确实希望使用某种 XML 编组/绑定技术(比如 Java 中的 JiBX) ，将 XML 直接转换为对象。

小开

就个人而言，我在完全不同的上下文中使用 XSLT。我当时正在开发的电脑游戏使用了大量使用 XML 定义的 UI 页面。在发布后不久的一次主要重构中，我们希望更改这些 XML 文档的结构。我们使游戏的输入格式遵循一个更好的和模式感知的结构。

XSLT seemed the perfect choice for this translation from old format -> New format. Within two weeks I had a working conversion from old to new for our hundreds of pages. I was also able to use it to extract lots of information on the layout of our UI pages. I created lists of which components were imbedded in which relatively easily which I then used XSLT to write into our schema definitions.

而且，从一个 C + + 的背景，它是一个非常有趣和有趣的语言掌握。

我认为将 XML 从一种格式转换为另一种格式的工具非常棒。但是，它并不是定义将 XML 作为输入并输出 一些东西的算法的唯一方法。如果您的算法足够复杂，那么输入是 XML 这一事实就与您选择的工具无关了——例如，在 C + +/Python/whatever 中使用您自己的工具。

具体到您的示例，我认为最好的办法是创建遵循您的业务逻辑的 XML-> XML 转换。接下来，编写一个 XSLT 翻译器，它只知道格式化，不做任何聪明的事情。这可能是一个不错的中间立场，但这完全取决于你在做什么。在输出中使用 XSLT 翻译器可以更容易地创建替代输出格式-可打印的，用于移动设备等。

小开

XSLT is not the end-all be-all of xml transformation. However, it's very difficult to judge based on the information given if it would have been the best solution to your problem or if there are other more efficient and maintainable approaches. You say the authors could enter their content in a simplified format - what format? Text boxes? What kind of html were you converting it to? 要判断 XSLT 是否是适合这项工作的工具，更详细地了解这种转换的特性将有所帮助。

小开

我在 XSLT 上花了很多时间，发现虽然在某些情况下它是一个有用的工具，但它绝不是一个完全修复工具。当它用于机器可读的 XML 输入/输出的数据转换时，对于 B2B 目的来说，它工作得非常好。我不认为你说的有限性是错误的。最让我沮丧的事情之一是 XSLT 实现中的细微差别。

也许您应该看看其他一些可用的标记语言。我相信 Jeff 写过一篇关于 Stack Overflow 的文章。

HTML 是人性化的标记语言吗？

我会看看他写的东西。你也许可以找到一个软件包来做你想要的“开箱即用”，或者至少非常接近，而不是从头开始写你自己的东西。

小开

I too have made forays into the world of XSLT and I found it to be a little awkward in places. I think my main issue was in the difficulty in converting "pure data" XML into a complete HTML page. In hindsight, perhaps using XSLT to generate a page fragment that could be composed together with other fragments using Server Side Scripting (eg SSI) would have solved many of my issues.

其中一个可能的错误是尝试通过使用 document ()函数导入 XHTML 或其他 XML 数据来构造围绕我的数据的公共页面布局。

另一个错误是尝试使用编程方法，比如创建一个通用模板，用逻辑生成 XML 数据表，这种逻辑可以对具有特定值的行使用不同的背景行颜色，并允许指定要过滤掉的一些列。

更不用说尝试从 XML 数据构造一个字符串列表，这些值似乎只能使用递归模板调用来解决。

我得到了什么？页面源代码就是这里的 XML 数据，可供查看者使用。数据和表示整齐地分开。

我还会这么做吗？可能不会，除非我真的想在 静电干扰页面上实现数据/表示分离。否则，我可能会编写一个 Rails 或 JavaEE 应用程序，它可以使用模板生成 XML 视图或 HTML 视图——所有的好处，但是对我来说，一种更自然的(对我来说)编程语言就在我的指尖。

小开

我还记得 XSLT 标准刚发布时的所有宣传。能够用一个“简单”的转换构建一个完整的 HTML 用户界面是一件令人兴奋的事情。

让我们面对它，它很难使用，几乎不可能调试，往往是难以忍受的慢。最终的结果几乎总是古怪和不理想的。

虽然有更好的方法来做事情，但是我宁愿咬断自己的腿也不愿意使用 XSLT。它仍然有自己的位置，它适合于简单的转换任务。

小开

我喜欢只在更改 XML 文档的树结构时才使用 XSLT。我发现做任何与文本处理相关的事情都很麻烦，而且要把它放到一个自定义脚本中，这个脚本可能在将 XSLT 应用到 XML 文档之前或之后运行。

XSLT 2.0包含了更多的字符串函数，但我认为它不太适合这种语言，而且 XSLT 2.0的实现也不多。

小开

我为我的公司维护一个在线文档系统。作者用 SGML (类似 xml 的语言)创建文档。然后将 SGML 与 XSLT 组合并转换为 HTML。

这使我们可以轻松地对文档布局进行更改，而无需进行任何编码。只需更改 XSLT 即可。

这对我们很有用。在我们的例子中，它是一个只读文档。用户不与文档进行交互。

而且，通过使用 XSLT，您更接近于您的问题域(HTML)。我一直认为这是个好主意。

最后，如果你当前的系统工作，离开它。我永远不会建议破坏您现有的代码。如果我从头开始，我会使用 XSLT，但是在您的情况下，我会使用您所拥有的。

小开

我发现使用 XSLT 非常困难。

我曾经在一个系统上工作过，这个系统与您描述的系统有些相似。我的公司注意到，我们从“中间层”返回的数据是 XML 格式的，页面将以 HTML 格式呈现，也可能是 XHTML 格式，而且他们听说 XSL 是在 XML 格式之间转换的标准。因此，“架构师”(我指的是那些深思熟虑设计思想但显然从不编写代码的人)决定，我们的前台将通过编写 XSLT 脚本来实现，这些脚本将数据转换为 XHTML 以便显示。

这个选择结果是灾难性的。事实证明，编写 XSLT 是一个痛苦的过程。所以我们所有的页面都很难写和维护。如果我们使用 JSP (Java 中的 JSP)或者类似的方法，对输出格式(HTML)使用一种标记(尖括号) ，对元数据使用另一种标记(比如 <% ...% >) ，我们会做得更好。关于 XSLT 最令人困惑的事情是，它是用 XML 编写的，并且它可以从 XML 转换为 XML... ... 要想把所有3种不同的 XML 文档都记住是相当困难的。

您的情况略有不同: 您不需要像我一样用 XSLT 创建每个页面，只需要用 XSLT 编写一位代码(从模板转换为显示的代码)。但听起来你好像遇到了和我一样的困难。我想说，像您这样试图解释一种简单的基于 XML 的 DSL (领域特定语言)并不是 XSLT 的优点之一。(虽然它可以做这项工作... 毕竟，它是图灵完成!)

但是，如果您所拥有的更简单: 您拥有一种 XML 格式的数据，并且希望对其进行简单的修改——不是完整的页面描述 DSL，而是一些简单的直接修改，那么 XSLT 就是用于此目的的优秀工具。它的声明性(而非过程性)实际上是这方面的一个优势。

—— Michael Chermside

小开

I think you did the right thing. In my experience, XSLT developers are among the very hardest to hire, because it's a language that never caught on either with Web developers nor with casual programmers.

因此，您最终不得不支付“了解主流以外语言的高级程序员”的溢价，但是购买的语言可能不是那个程序员的最爱。

小开

最佳答案

XSLT 的优点:

特定于 XML 的领域，例如，不需要在输出中引用文本 XML。
支持 XPath/XQuery，它可以是查询 DOM 的一种很好的方式，就像正则表达式可以是查询字符串的一种很好的方式一样。
实用语言。

XSLT 的缺点:

可能非常冗长——您不必引用文字 XML，这实际上意味着您必须引用代码。而且不是以一种漂亮的方式。但话说回来，这并不比典型的 SSI 糟糕多少。
不做大多数程序员认为理所当然的事情。例如，字符串操作可能是一件苦差事。这可能导致“不幸的时刻”，当新手设计代码，然后疯狂搜索提示如何实现功能，他们认为只是存在，并没有给他们自己的时间写。
实用语言。

One way to get procedural behaviour, by the way, is to chain multiple transforms together. After each step you have a brand new DOM to work on which reflects the changes in that step. Some XSL processors have extensions to effectively do this in one transform, but I forget the details.

So, if your code is mostly output and not much logic, XSLT can be a very neat way to express it. If there is a lot of logic, but mostly of forms which are built in to XSLT (select all elements which look like blah, and for each one output blah), it's likely to be quite a friendly environment. If you fancy thinking XML-ishly at all times, then give XSLT 2 a go.

否则，我会说，如果您最喜欢的编程语言有一个支持 XPath 的好的 DOM 实现，并允许您以有用的方式构建文档，那么使用 XSLT 几乎没有什么好处。绑定到 libxml2和 gdome2应该可以做得很好，而且坚持使用您熟悉的通用语言也没有什么不好意思的。

自己开发的 XML 解析器通常要么是不完整的(在这种情况下，总有一天会出现问题) ，要么不会比现成的小很多(在这种情况下，你可能是在浪费时间) ，并且给你很多机会来引入恶意输入的严重安全问题。除非你确切地知道这样做有什么好处，否则不要写。这并不是说，如果不需要 XML 提供的所有东西，就不能编写比 XML 更简单的解析器作为输入格式。

小开

关键在于你需要它做什么。它的主要优点是转换的易维护性，而编写自己的解析器通常会消除这一点。也就是说，有时候一个系统是小而简单的，并且真的不需要一个“花哨”的解决方案。只要您的基于代码的构建器是可替换的，而不必更改其他代码，就没什么大不了的。

至于 XSL 的丑陋，是的，它是丑陋的。是的，需要一些时间来适应。但是一旦你掌握了窍门(不会花太长时间) ，事实上就一帆风顺了。根据我的经验，编译后的转换运行得非常快，您当然可以对它们进行调试。

小开

我绝对建议你坚持到底。特别是如果您使用的是内置了 XSLT 编辑、查看和调试工具的可视化工作室。

Yes, it is a pain while you are learning, but most of the pain is to do with familiarity. The pain does diminish as you learn the language.

W3商学院有两篇特别有价值的文章: http://www.w3schools.com/xpath/xpath_functions.asp Http://www.w3schools.com/xsl/xsl_functions.asp

小开

在这里，我需要使用 XSLT，因为有人认为解决一个给定的问题是个好主意: 我们需要从多个 XML-Files 中提取一些数据，并将其连接到不同的输出格式，以便用于进一步处理的不同工具。

首先，我认为 XSLT 是一个非常好的想法，因为它是您可以依赖的标准。对于简单的格式化任务来说是这样的，在这些任务中，您不需要在代码中使用太多的编程逻辑或算法。

但是: 这是一个相当步骤的学习曲线，因为它是 not过程。如果你已经习惯了使用程序编程结构(C、 Java、 Perl、 PHP 等) ，你将会错过很多常见的结构，或者你会想知道一些仅仅是运气好而且有时候不是真正可读的未经训练的眼睛。例如，编写“可重用”代码: 如果你需要在不同的地方反复做一些事情，在程序编程中，你需要定义一个函数来完成这些事情。您也可以在 XSLT 中实现这些功能，但是需要编写更多的代码，而且不像普通函数那样具有可读性/可理解性。

我遇到的主要问题是，到目前为止，许多具有程序背景的人都在处理 XSLT-Files，而且几乎每个人都“模拟”了他所需要的东西。

因此，作为一个结论: 我不再认为 XSLT 是“最终”的解决方案。实际上，在 XSLT 中读写一些构造是痛苦的。对于大多数情况，您必须考虑应用程序: 对于简单的转换，我可能会再次使用 XSLT。但对于更复杂的软件，我不会再使用它。

小开

XSLT is difficult to work with, but once you conquer it you will have a very thorough understanding of the DOM and schema. If you also XPath, then you on your way to learning functional programming and this will expose to new techniques and ways about solving problems. In some cases, successive transformation is more powerful than procedural solutions.

小开

我现在的任务是从一个公共网站上获取数据(是的，我知道)。幸运的是，它符合 xhtml，因此我能够使用 xslt 收集我需要的数据。产生的解决方案是可读的，干净的，容易更改，如果需要发生。太好了！

小开

说到互操作性，XML 是一种信息存储标准。很多工具都以 XML 格式生成输出，还有什么比在应用程序中嵌入浏览器、格式化 XML 并将其放入浏览器更好(或更容易)的方式来呈现它呢。

小开

在我看来，是的。

要了解一个非常酷的 XSLT 使用示例，请查看暴雪的魔兽世界。

http://www.wowarmory.com

小开

So much negativity!

到现在为止，我已经使用 XSLT 好几年了，而且我真的很喜欢它。你必须意识到的关键事情是 它不是一种编程语言，而是一种模板语言(在这方面，我发现它比 asp.net/spay 优越得难以形容)。

XML 是当今 web 开发中事实上的数据格式，无论是配置文件、原始数据还是内存表示。XSLT 和 XPath 为您提供了一种强大且非常有效的 非常喜欢方法，可以将数据转换为您可能喜欢的任何输出格式，并立即为您提供了将表示与数据分离的 MVC 方面。

然后是实用功能: 清除名称空间、识别不同的模式定义、合并文档。

与开发自己的内部方法相比，必须的处理 XSLT 更好。至少 XSLT 是一个标准，您可以雇用它，如果它对您的团队来说真的是一个问题，那么它的本质就是让您的团队中的大多数人只使用 XML 工作。

一个真实的用例: 我刚编写了一个应用程序，它处理整个系统的内存中的 XML 文档，并根据最终用户的请求转换为 JSON、 HTML 或 XML。我有一个相当随机的请求提供作为 Excel 数据。以前的一个同事也做了类似的程序，但它需要一个模块的几个类文件和服务器有微软办公室安装！原来 Excel 有一个 XSD: 新的功能，最小的基本代码影响在3小时。

就个人而言，我认为这是我职业生涯中遇到的最干净的事情之一，我相信所有明显的问题(调试、字符串操作、编程结构)都是由于对工具的理解存在缺陷。

显然，我坚信这是“值得的”。

小开

我以前使用过 XSLT。六人小组。在我用 C # 重写 xslt 文件之前，它大约有2750行。C # 代码目前有4000行，包含大量逻辑; 我甚至不想考虑在 XSLT 中编写这些代码需要什么。

当我意识到没有 XPATH 2.0会严重影响我的进度时，我放弃了。

小开

XSLT 是宣告式编程语言的一个例子。

Other examples of declarative programming languages include regular expressions, Prolog, and SQL. All of these are highly expressive and compact, and usually very well designed and powerful for the task for which they are designed.

然而，软件开发人员通常讨厌这样的语言，因为它们与更主流的面向对象语言或过程语言有很大的不同，很难学习和调试。它们的紧凑特性使得它们很容易在不经意间造成大量的损害。

因此，尽管 XSLT 是一种将数据合并到表示中的有效机制，但在易用性方面却是失败的。我相信这就是为什么它没有真正流行起来。

小开

我确实广泛地使用了 XSLT... 有几个小时。对于更改元素名称或过滤输入文档(删除不需要的内容)这样的事情来说，它很酷。

任何事情都会很快变得复杂。这继承了复杂性，加上缺少其他编程语言(比如变量)中使用的大部分内容，以及使 XPath 表达式不可读的简单方法，真的很伤人。

最后，XSLT 遭遇了一个分裂: 程序员不喜欢它，因为它的局限性，其他人根本不能使用它(比如，Web 设计师或任何其他非程序员类型)。

如果将 XSLT 作为某种 XML SQL 进行推广，情况就会有所不同。首先，人们甚至懒得去看它。而那些知道的人也不会对疼痛感到惊讶。

小开

我认为这个概念是合理的，也许执行并不像它可能的那样“干净”。

然而，我认为它应该被视为一个工具，它可能不是明智的使用它在每一个情况下，然而，一个人不应该忽视一个工具时，解决方案。

我已经看到了非常好的 XSLT，也看到了非常糟糕的 XSLT 使用情况，我得出的结论是，其中一些问题可能取决于开发人员的技能。我认为这需要开发人员同时思考多个领域。

这是未来吗? 也许不是，也许有更好的解决办法. 。

我不知道未来会出现什么样的新技术，但至少学习它是最好的，增加自己的工具总不会是一件坏事吧？

小开

是的，我经常用。通过使用不同的 xslt 文件，我可以使用相同的 XML 源来创建多个多语言(X) HTML 文件(以不同的方式表示相同的数据)、 RSS 提要、 Atom 提要、 RDF 描述符文件和站点地图片段。

这不是灵丹妙药。有些事情它做得很好，有些事情它做得不好，就像编程的所有其他方面一样，它完全是为了正确的工作使用正确的工具。这是一个非常值得在工具箱中使用的工具，但它应该只在适当的时候使用。

小开

回答你的三个问题:

几年前我曾经使用过一次 XSLT。
我相信在某些情况下 XSLT 可能是正确的解决方案
我倾向于同意您的评估，即它对于“简单”转换最为有用。但是我认为，只要您很好地理解 XSLT，就有理由将其用于更大的任务，比如将网站发布为 XML 转换为 HTML。

我相信许多开发人员不喜欢 XSLT 的原因是因为他们不理解它所基于的根本不同的范式。但是随着最近对函数式编程的兴趣，我们可能会看到 XSLT 卷土重来... ..。

小开

我使用 XSLT (因为没有更好的选择) ，但不是为了表示，只是为了转换:

I write short XSLT transformations to do mass edits on our maven pom.xml files.
我已经编写了一个从 XMI (UML 图)生成 XMLSchema 的转换管道。它工作了一段时间，但它最终变得太复杂，我们不得不把它带到谷仓后面。
我已经使用转换来重构 XMLSchema。
通过使用 XSLT 生成 XSLT 来完成实际工作，我已经解决了 XSLT 中的一些限制。(有没有尝试过编写一个 XSLT，使用直到运行时才知道的名称空间生成输出?)

我之所以不断回到这个话题，是因为与我尝试过的其他方法相比，它在往返处理所处理的 XML 方面做得更好，这些方法看起来毫无必要地有损失，或者只是误解了 XML。XSLT 令人不快，但是我发现使用氧气可以使它变得可以忍受。

也就是说，我正在研究使用 Clojure(一个 lisp)来执行 XML 转换，但是我还没有了解到这种方法是否会给我带来好处。

小开

我们广泛地将 XSLT 用于文档之类的事情，并使一些复杂的配置设置具有用户可维护性。

对于文档，我们使用了很多 DocBook，它是一种基于 XML 的格式。这使我们可以使用所有源代码来存储和管理文档，因为这些文件是纯文本。使用 XSLT，我们可以很容易地构建自己的文档格式，从而允许我们以通用方式自动生成内容，并使内容更具可读性。例如，当我们发布发布说明时，我们可以创建类似下面这样的 XML:

<ReleaseNotes>
<FixedBugs>
<Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
<Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
<Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
</FixedBugs>
</ReleaseNotes>

然后使用 XSLT (将上述内容转换为 DocBook) ，我们得到了很好的发布说明(通常是 PDF 或 HTML) ，bug ID 自动链接到 bug 跟踪器，bug 按组件分组，所有内容的格式完全一致。通过查询我们的 bug 跟踪器，可以自动生成上面的 XML，了解不同版本之间发生了什么变化。

我们发现 XSLT 有用的另一个地方实际上是在我们的核心产品中。有时在与第三方系统接口时，我们需要以某种方式处理复杂 HTML 页面中的数据。解析 HTML 很难看，所以我们通过类似泰格汤(它生成正确的 SAX XML 事件，本质上让我们处理 HTML，就像它是正确编写的 XML 一样)的东西提供数据，然后我们可以针对它运行一些 XSLT，将数据转换成我们实际上可以使用的“已知稳定”格式。通过将转换分离成 XSLT 文件，这意味着如果 HTML 格式发生变化，应用程序本身不需要升级，而是最终用户可以自己编辑 XSLT 文件，或者我们可以通过电子邮件向他们发送更新后的 XSLT 文件，而不需要升级整个系统。

我想说，对于 Web 项目来说，目前有比 XSLT 更好的方法来处理视图端，但是作为一种技术，XSLT 肯定有其用途。它不是世界上最容易使用的语言，但它肯定没有死，从我的角度来看，仍然有很多好的用途。

小开

我使用 XSLT 来纠正非常复杂的 xml 文件中的错误。因此，我没有处理 xml 中的错误，而是使用 xslt 来纠正它们。

这非常好，因为这种语言非常强大，而且适合 xml 用例。为了在一种通用的编程语言中做同样的事情，每当出现一种新的风格时，我都要花很长时间来调整我的代码。

它还有助于迁移视觉工作室的解决方案，而不让微软决定哪些事情要改变。因此，转换一个解决方案。看看有什么变化。恢复您不希望更改的内容，并运行 xslt 脚本对所有文件执行此工作。

所以我从来没有用它来做网页演示或类似的东西，但它帮助我在我的 xml 为基础的问题。为了解决这些问题，它真的非常强大，非常值得一看。

小开

我广泛使用 XSLT (还有 XQuery)做各种事情——作为构建过程的一部分生成 C + + 代码，从 doc 注释生成文档，以及在一个必须大量使用 XML 特别是 XHTML 的应用程序中使用 XSLT。特别是代码生成器有超过10,000行的 XSLT 2.0代码，分散在大约12个独立的文件中(它做了很多事情——客户端的头、远程代理/存根、 COM 包装器、。NET 包装器，ORM 等等)。我从另一个不太懂英语的家伙那里继承了这种语言，因此老的部分相当混乱。然而，我们写的较新的东西大多保持理智和可读性，我不记得实现这一点有什么特别的问题。当然，这并不比为 C + + 做这件事更难。

说到版本，处理 XSLT 2.0肯定有助于您保持理智，但是对于更简单的转换，1.0仍然是可以的。在它的利基市场，它是一个非常便利的工具，你从某些领域特定的功能(最重要的是，通过模板匹配克劳斯·福尔曼)得到的效率是很难匹配的。尽管 XSLT 基于 XML 的语法冗长乏味，但 LINQ to XML (即使在使用 XML 文本的 VB 中)中的相同内容通常要长好几倍。然而，由于在某些情况下首先不必要地使用 XML，它常常受到不应有的抨击。

总而言之: 它是一个非常有用的工具，可以放在你的工具箱里，但它是一个非常专业的工具，所以只要你正确地使用它并达到预期的目的，它就是好的。我真的希望有一个合适的，本地人。NET 实现 XSLT 2.0。

小开

在生成报告方面，xslt 真正发挥作用的地方是。我发现了一个2步的过程，第一步将报告数据导出为 xml 文件，第二步使用 xslt 从 xml 生成可视化报告。这允许在保留原始数据作为验证机制(如果需要的话)的同时提供良好的可视化报告。

小开

I use XSLT extensively, for a custom MVC style front-end. The model is "serialized" to xml (not via xml serializaiton), and then converted to html via xslt. The advantage over ASP.NET lie in the natural integration with XPath, and the more rigorous well-formedness requirements (it's much easier to reason about document structure in xslt than in most other languages).

不幸的是，该语言包含一些限制(例如，转换另一个转换的输出的能力) ，这意味着使用它有时会令人沮丧。

尽管如此，它所提供的这种容易实现、强制执行的关注点分离并不是我目前看到的另一种技术所能提供的——所以对于文档转换来说，我仍然推荐它。

小开

如果您可以以声明式样式使用 XSLT (尽管我不完全同意它是声明式语言) ，那么我认为它是有用的和具有表现力的。

我曾经编写过使用面向对象语言(在我的例子中是 C #)来处理数据/处理层的 Web 应用程序，但是输出的是 XML 而不是 HTML。然后，客户端可以将其作为数据 API 直接使用，或者通过 XSLT 呈现为 HTML。因为 C # 输出的 XML 在结构上与这种使用兼容，所以一切都非常顺利，并且表示逻辑保持声明性。这比从 C # 发送标记更容易跟踪和更改。

然而，当您需要更多 XSLT 级别的处理逻辑时，即使您“得到”函数样式，也会变得复杂和冗长。

当然，如今我可能已经使用 RESTful 界面编写了这些 Web 应用程序——我认为数据“语言”(如 JSON)正在传统上由 XSLT 转换 XML 的领域获得越来越多的关注。但就目前而言，XSLT 仍然是一种重要且有用的技术。

小开

在2004年的某个时候，我在一个非常不同的 DB 系统之间的集成项目中使用了 XML、 XSD 和 XSLT。我必须从头学习 XSD 和 XSLT，但这并不难。这些工具的伟大之处在于，它使我能够编写独立于数据的 C + + 代码，依赖于 XSD 和 XSLT 来验证/验证，然后转换 XML 文档。改变数据格式，改变 XSD 和 XSLT 文档，而不是使用 Xerces 库的 C + + 代码。

感兴趣的是: 主 XSD 为150KB，XSLT 的平均大小 < 5KB IIRC。

另一个巨大的好处是 XSD 是 XSLT 所基于的规范文档。这两者协调工作。如今在软件开发中，规格说明书已经很少见了。

虽然我在学习声明性 XSD 和 XSLT 方面没有遇到太多困难，但是我发现其他 C/C + + 程序员在适应声明性方式方面遇到了很大的困难。当他们看到就是这样，啊程序他们嘀咕，现在我明白了！然后他们继续(双关语?)编写过程 XSLT！问题是您必须学习 XPath 并理解 XML 的轴。这让我想起了以前的 C 程序员在编写 C + + 时适应使用 OO。

我使用这些工具，因为它们使我能够编写一个小型的 C + + 代码库，除了最基本的数据结构修改外，它与所有数据结构修改都隔离开来，后者是 DB 结构修改。尽管比起其他语言，我更喜欢 C + + ，但我还是会使用我认为有用的语言，以便使软件项目的长期生存能力受益。

小开

I used to think XSLT was a great idea. I mean it 是 a great idea.

它失败的地方就是执行。

随着时间的推移，我发现用 XML 编程语言是个坏主意。这让整件事变得无法理解。具体来说，我认为 XSLT 是很难学习、编码和理解的。在函数方面之上的 XML 只会让整个事情变得太混乱。在我的职业生涯中，我已经尝试学习了大约5次，但它就是不能坚持下去。

好吧，您可以“工具化”它——我认为这是它设计的部分要点——但这是第二个缺陷: 市场上所有的 XSLT 工具，非常简单——都是垃圾！

小开

就纯粹的生产力而言，您最好使用 jQuery 风格的库之一—— pyQuery、 phpQuery 等。大多数 XML 库都很糟糕，XSLT 本质上只是另一个打包为成熟语言的 XML 库，但没有一套像样的工具。JQuery 使得用您选择的语言遍历和操作 XML 样式数据变得非常容易。

小开

在前一家公司，我们在 XML 和 XSLT 方面做了很多工作，XML 和 XSLT 都很大。

Yes there is a learning curve, but then you have a powerful tool to handle XML. And you can even use XSLT on XSLT (which can sometimes be useful).

性能也是一个问题(对于非常大的 XML) ，但是可以通过使用智能 XSLT 并对(生成的) XML 进行一些预处理来解决这个问题。

任何了解 XSLT 的人都可以更改成品的外观，因为它不是编译的。

小开

我不得不承认这里存在偏见，因为我以教授 XSLT 为生。但是，这可能是值得涵盖的领域，我看到我的学生在工作。他们一般分为三类: 出版业、银行业和网络业。

到目前为止，许多答案可以概括为“它不适合创建网站”或“它与 X 语言完全不同”。许多技术人员在职业生涯中从未接触过函数式/声明式语言。当我在教学的时候，经验丰富的 Java/VB/c/etc 用户是那些有语言问题的人(例如，变量是代数意义上的变量，而不是程序编程)。这是很多人在这里回答-我从来没有得到与 Java，但我不会因为这个麻烦去批评语言。

在许多情况下，它是一个不合适的工具来创建网站-一个通用的编程语言可能更好。我经常需要获取非常大的 XML 文档并在 Web 上显示它们; XSLT 使这一点变得微不足道。我在这个空间看到的学生倾向于处理数据集并在网上展示它们。XSLT 当然不是这个领域中唯一适用的工具。但是，其中许多都使用 DOM 来完成这项工作，XSLT 当然没有那么痛苦。

我看到的银行系学生通常使用 DataPower 框。这是一个 XML 设备，用于处理“说”不同 XML 方言的服务之间的关系。在 XSLT 中，从一种 XML 语言到另一种 XML 语言的转换几乎是微不足道的，参加我这门课程的学生人数正在增加。

The final set of students I see come from a publishing background (like me). These people tend to have immense documents in XML (believe me, publishing as an industry is getting very into XML - technical publishing has been there for years and trade publishing is getting there now). These documents need to be processing (DocBook to ePub comes to mind here).

上面有人评论说，脚本往往低于60行或他们变得笨重。如果 XSLT 确实变得笨拙，那么很可能程序员并没有真正理解它—— XSLT 与许多其他语言的思维方式非常不同。如果你没有这种心态，它就不会起作用。

It's certainly not a dying language (the amount of work I get tells me that). Right now, it's a bit 'stuck' until Microsoft finish their (very late) implementation of XSLT 2. But it's still there and seems to be going strong from my viewpoint.

小开

我个人喜欢 XSLT，您可能想看看简化语法(没有显式的模板，只是一个普通的旧 HTML 文件，带有一些 XSLT 标记，可以向其中输入值) ，但它并不适合所有人。

也许你只是想为你的作者提供一个简单的 Wiki 或 Markdown 界面。这方面也有库，如果 XSLT 不适合您，那么 XML 可能也不适合它们。

小开

我对 XSLT 有很好的体验，但是我没有转换成 HTML。可能 XSLT-HTML 组合对于完成任务来说是非常困难的。

小开

XSLT 1.0是最便携的代码之一，至少在桌面和服务器计算机上是如此。因为它在大多数系统上都有一个(通常是多个)运行时:

MicrosoftWindows 具有 MSXML，至少从 Windows2000开始就安装在基本系统中。它可以在 MSIE、从命令行(使用 WSH)或 Office 应用程序中使用
JRE (JRE)有一个 XSLT 运行时，并且大多数桌面上都安装了一个 JRE
Almost all major web browser have one. Opera is the exception.
There are free implementations that installed by default on major GNU based operating systems (libxslt, xsltproc)
I've not checked MacOS X, but it has at least an implementation in Safari

这使得构建一些既需要可移植性又需要轻量级/不需要安装的应用程序变得非常合适。

而且，XSLT 只需要一个运行时(不需要编译器) ，您可以使用任何文本编辑器创建代码。因此，您可以很容易地从任何桌面创建程序(当然，只要您掌握了该语言)。