XSLT值得吗？[关闭]

前一段时间，我开始设计一个html风格的XML模式的项目，以便作者可以以简化的格式编写其内容（教育课程资料），然后通过XSLT将其转换为HTML。我玩了一段时间（苦苦挣扎），并把它提升到一个非常基本的水平，但后来却因遇到的局限性（可能是我的知识局限性）以及阅读博客建议抛弃它而感到恼火XSLT并以您选择的语言编写您自己的XML解析器，我急切地跳到这一点，并且效果非常出色。

直到今天，我仍在努力（实际上我应该现在就在研究它，而不是在SO上玩），并且我看到越来越多的事情使我认为放弃XSLT的决定是好人

我知道XSLT占有一席之地，因为它是一个公认的标准，而且如果每个人都在编写自己的解释器，则其中90％的结果将在TheDailyWTF上发布。但是考虑到它是一种功能样式语言，而不是大多数程序员熟悉的过程样式语言，对于从事诸如我自己的项目的某人来说，您会建议他们沿着我所做的那样走下去，还是坚持使用XSLT？？

XSLT的优点：

• 特定于XML的域，因此例如无需在输出中引用文字XML。
• 支持XPath / XQuery，这是查询DOM的好方法，就像正则表达式是查询字符串的好方法一样。
• 功能语言。

XSLT的缺点：

• 可能非常冗长-您不必引用文字XML，这实际上意味着您必须引用代码。而且不是很漂亮。但是再说一次，它并不比典型的SSI差多少。
• 不执行大多数程序员认为理所当然的某些事情。例如，字符串操作可能很麻烦。当新手设计代码时，这可能会导致“不幸的时刻”，然后疯狂地在网络上搜索提示，以提示如何实现他们认为只是存在而又没有时间自己编写功能的功能。
• 功能语言。

顺便说一句，获得程序行为的一种方法是将多个转换链接在一起。每一步骤之后，您将需要使用一个全新的DOM来反映该步骤中的更改。一些XSL处理器具有扩展功能，可以在一次转换中有效地完成此操作，但是我忘记了细节。

因此，如果您的代码主要是输出而没有太多逻辑，则XSLT可以是表达它的一种非常简洁的方法。如果有很多逻辑，但大多数都是XSLT内置的形式（选择所有看起来很虚构的元素，并为每个输出等），这可能是一个非常友好的环境。如果您想一直思考XML，那么请尝试XSLT 2。

否则，我想说的是，如果您最喜欢的编程语言具有支持XPath的良好DOM实现并允许您以有用的方式构建文档，那么使用XSLT几乎没有好处。与libxml2和gdome2的绑定应该做得很好，并且坚持使用您熟知的通用语言也没有什么可耻的。

本地的XML解析器通常不完整（在这种情况下您有一天会被卡住），或者比要下架的东西小很多（在这种情况下您可能会浪费时间），并且付出您有很多机会在恶意输入周围引入严重的安全问题。除非您确切地知道这样做会带来什么，否则不要写一个。这并不是说，如果您不需要XML所提供的所有内容，就不能为XML作为输入格式编写解析器。

如此消极！

我使用XSLT已经有好几年了，并且真的很喜欢它。您必须意识到的关键是它不是一种编程语言，而是一种模板语言（在这方面，我发现它比asp.net / spit优越得多）。

XML是当今Web开发的事实数据格式，无论是配置文件，原始数据还是在内存中。XSLT和XPath为您提供了一种非常强大且非常有效的方式，可以将数据转换为您可能想要的任何输出格式，从而立即为您提供将演示文稿与数据分离的MVC方面。

然后是实用程序的功能：清除名称空间，识别不同的架构定义，合并文档。

它必须是更好地应对XSLT比开发自己的内部方法。至少XSLT是一个标准，您可以租用它，而且，如果这确实对您的团队来说是个问题，那么很自然的做法就是让您让大多数团队仅使用XML。

一个真实的用例：我刚刚编写了一个应用程序，该应用程序处理整个系统中的内存XML文档，并根据最终用户的要求转换为JSON，HTML或XML。我有一个相当随机的要求提供Excel数据。一位前同事在编程上做了类似的事情，但是它需要一个包含几个类文件的模块，并且该服务器已安装了MS Office！事实证明，Excel具有XSD：3小时内对基本代码的影响最小的新功能。

我个人认为这是我职业生涯中遇到的最干净的事情之一，而且我认为所有显而易见的问题（调试，字符串操作，编程结构）都归因于对该工具的理解有缺陷。

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

我不得不承认这里有偏见，因为我以XSLT为生。但是，值得掩盖我看到我的学生从事的领域。他们通常分为三类：发布，银行和网络。

到目前为止，许多答案都可以概括为“对创建网站不利”或“与X语言完全不同”。许多技术人员在职业生涯中都没有接触过功能性/声明性语言。在我教学时，经验丰富的Java / VB / C / etc等人是对该语言有疑问的人（变量是代数而不是过程编程的变量）。那是很多人在这里回答的问题-我从没接触过Java，但是我不会因此而去批评这种语言。

在许多情况下，这是创建网站的不适当工具-通用编程语言可能更好。我经常需要处理非常大的XML文档并将其显示在Web上。XSLT使这变得无关紧要。我在这个空间中看到的学生倾向于处理数据集并将其显示在网络上。XSLT当然不是该领域中唯一适用的工具。但是，他们中的许多人都在使用DOM来做到这一点，而XSLT无疑会减轻痛苦。

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

我看到的最后一批学生来自出版背景（例如我）。这些人倾向于使用XML编写大量文档（相信我，随着行业的发展，XML的应用已日趋成熟-技术发布已经存在了很多年，而贸易发布也正在到那里实现）。这些文档需要处理（在这里想到DocBook到ePub）。

上面的人评论说脚本往往在60行以下，否则变得笨拙。如果确实变得笨拙，那么很有可能是编码人员并没有真正想到这一点-XSLT与许多其他语言完全不同。如果您没有这种想法，那将行不通。

这当然不是一门必死的语言（我得到的工作量告诉我）。现在，在Microsoft完成XSLT 2的（很晚）实施之前，这有点“卡住”了。但是从我的角度来看，它仍然存在，并且似乎还很强大。

我们将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），其中错误ID自动链接到我们的错误跟踪器，错误按组件分组，并且所有内容的格式完全一致。通过查询我们的Bug跟踪器以了解版本之间的变化，可以自动生成上述XML。

我们发现XSLT有用的另一个地方实际上是我们的核心产品。有时，当与第三方系统接口时，我们需要以某种方式处理复杂HTML页面中的数据。解析HTML很丑陋，所以我们通过TagSoup这样的数据来馈送数据（它会生成适当的SAX XML事件，从本质上让我们像对待XML一样正确地处理HTML），然后可以对它运行一些XSLT，以将数据转换为我们可以实际使用的“已知稳定”格式。通过将该转换分离为XSLT文件，这意味着，当HTML格式发生更改时，不需要升级应用程序本身，而是最终用户可以自己编辑XSLT文件，或者我们可以通过电子邮件发送它们是更新的XSLT文件，而无需升级整个系统。

我要说的是，对于Web项目来说，比今天的XSLT有更好的方法来处理视图方面，但是作为一种技术，XSLT肯定有用途。它不是世界上最容易使用的语言，但它绝对不会死，而且从我的角度来看，它仍然有很多良好的用法。

XSLT是声明性编程语言的示例。

声明性编程语言的其他示例包括正则表达式，Prolog和SQL。所有这些都具有很高的表现力和紧凑性，通常针对它们要完成的任务设计得很好并且功能强大。

但是，软件开发人员通常讨厌这样的语言，因为它们与更主流的OO或过程语言截然不同，以致于它们很难学习和调试。它们的紧凑特性通常使其很容易在不经意间造成大量损坏。

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

我记得新发布标准时有关XSLT的所有宣传。围绕能够通过“简单”转换构建整个HTML UI的所有兴奋之处。

面对现实吧，它很难使用，几乎无法调试，而且速度通常令人难以忍受。最终结果几乎总是古怪而又不理想。

在有更好的方法来做事情的同时，我会比使用XSLT更快地腿。它仍然占有一席之地，非常适合简单的转换任务。

我已经广泛地使用XSLT（以及XQuery）来做各种事情-在构建过程中生成C ++代码，从文档注释中生成文档，以及在必须与XML尤其是XHTML一起使用的应用程序中。尤其是代码生成器，它在大约十二个单独的文件中散布了10,000行以上的XSLT 2.0代码（它做了很多事情-客户端头，远程代理/存根，COM包装器，.NET包装器，ORM-命名）一些）。我是从另一个不太了解该语言的家伙那里继承下来的，因此较旧的位子一团糟。但是，我们撰写的较新的文章大多保持理智和可读性，而且我不记得实现此目的有任何特殊问题。当然，这比为C ++做任何事情都难。

说到版本，使用XSLT 2.0无疑可以使您保持理智，但对于更简单的转换，1.0仍然可以。在它的利基市场中，它是一个非常方便的工具，并且从某些特定于域的功能（最重要的是，通过模板匹配进行动态分配）获得的生产力很难匹配。尽管XSLT的基于XML的语法令人生厌，但是LINQ to XML中的同一件事（甚至在具有XML文字的VB中）通常要长几倍。但是，由于在某些情况下首先不必要地使用XML，因此经常会出现这种情况。

概括起来：它是一个非常有用的工具，可以放在一个工具箱中，但是它是一个非常专业的工具，因此，只要您正确地使用它并达到预期的目的，它就很好。我真希望XSLT 2.0有一个适当的本机.NET实现。

我使用XSLT（因为缺少更好的替代方法），但不用于演示，仅用于转换：

1. 我编写了简短的XSLT转换，以对我们的maven pom.xml文件进行批量编辑。

2. 我已经编写了一个转换管道，可以从XMI（UML图）生成XML模式。它工作了一段时间，但最终变得太复杂了，我们不得不将它从谷仓后面拿出来。

3. 我已经使用转换来重构XML模式。

4. 我已经通过使用XSLT生成XSLT来完成实际工作来解决XSLT中的一些限制。（是否曾经尝试编写使用运行时才知道的名称空间来生成输出的XSLT？）

我继续讨论它，因为与我尝试过的其他方法相比，它在处理XML方面做得更好，这似乎不必要地造成了损失，或者只是误解了XML。XSLT令人不快，但我发现使用Oxygen可以忍受。

就是说，我正在研究使用Clojure（一种Lisp）来执行XML转换，但是我还没有足够的了解这种方法是否会给我带来好处。

我个人在完全不同的环境中使用XSLT。我当时从事的计算机游戏使用了大量使用XML定义的UI页面。在发布之后不久的一次重大重构中，我们希望更改这些XML文档的结构。我们使游戏的输入格式遵循更好的架构意识结构。

XSLT似乎是从旧格式->新格式进行此翻译的理想选择。在两周内，我对数百页的工作进行了从旧到新的有效转换。我还能够使用它来提取有关UI页面布局的大量信息。我创建了将哪些组件嵌入其中的列表，这些列表相对容易，然后我使用XSLT将其写入我们的架构定义。

同样，来自C ++背景，这是一门非常有趣且有趣的语言。

我认为，作为将XML从一种格式转换为另一种格式的工具，这是很棒的。但是，这不是定义将XML作为输入并输出Something的算法的唯一方法。如果您的算法足够复杂，那么输入XML是与您选择的工具无关的事实，即在C ++ / Python /其他版本中滚动您自己的工具。

具体到您的示例，我想最好的主意是按照您的业务逻辑创建自己的XML-> XML转换。接下来，编写一个XSLT转换程序，该转换程序只知道格式设置，而不会做任何聪明的事情。那可能是一个很好的中间立场，但这完全取决于您在做什么。在输出上具有XSLT转换器使创建替代输出格式（可打印，用于移动设备等）的过程变得更加容易。

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

这不是万能药。在某些方面它做得很好，在某些方面它做得不好，就像编程的所有其他方面一样，这都是关于使用正确的工具完成正确的工作。这是一个非常值得在您的工具箱中使用的工具，但只有在适当时才应使用。

我绝对会建议坚持下去。特别是如果您使用的Visual Studio内置了XSLT的编辑，查看和调试工具。

是的，这是您学习时的痛苦，但是大多数痛苦与熟悉有关。学习语言时疼痛会减轻。

W3schools有两篇特别有价值的文章：http : //www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

我发现XSLT很难使用。

我曾在与您描述的系统有些相似的系统上工作过。我的公司指出，我们从“中间层”返回的数据是XML，并且页面将以HTML形式呈现，而HTML也可能是XHTML，此外他们还听说XSL是XML之间转换的标准格式。因此，“架构师”（我的意思是指那些具有深刻的设计思想，但显然从不编码的人）决定通过编写XSLT脚本（将数据转换为XHTML进行显示）来实现我们的顶层。

选择结果是灾难性的。事实证明，编写XSLT很痛苦。因此，我们所有的页面都难以编写和维护。如果使用JSP（这是Java语言）或其他类似的方法将输出格式（HTML）使用一种标记（尖括号）和另一种标记（例如<％... ％>）。关于XSLT的最令人困惑的事情是，它是用XML编写的，并且从XML转换为XML……很难完全记住所有3种不同的XML文档。

您的情况略有不同：无需像我一样在XSLT中编写每个页面，只需在XSLT中编写一位代码​​（从模板转换为显示的代码）。但是听起来您可能遇到了和我一样的困难。我会说，像您一样尝试解释基于XML的简单DSL（特定于域的语言）并不是XSLT的强项之一。（尽管它可以完成工作……毕竟，它已经完成了图灵！）

但是，如果您的工作更简单：您拥有一种XML格式的数据，并且想要对其进行简单的更改-不是完整的页面描述DSL，而是进行了一些简单明了的修改，那么XSLT就是一个出色的工具。声明性（而非过程性）本质实际上是为此目的的优势。

-迈克尔·彻姆赛德

XSLT很难使用，但是一旦您克服了它，您将对DOM和架构有一个非常全面的了解。如果您还使用XPath，那么您将在学习函数式编程的途中，这将向您介绍解决问题的新技术和新方法。在某些情况下，连续转换比过程解决方案更强大。

我将XSLT广泛用于自定义MVC样式的前端。该模型被“序列化”为xml（而不是通过xml serializaiton），然后通过xslt转换为html。与ASP.NET相比，优点在于与XPath的自然集成以及对格式要求的更加严格的要求（使用xslt推理文档结构比大多数其他语言要容易得多）。

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

但是，我认为，现在可以轻松实现，强行实施的关注点分离并不是我所提供的另一种技术-因此，对于文档转换，我仍然建议这样做。

2004年的某个时候，我在一个非常不同的数据库系统之间的集成项目中使用了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 ++，但我还是会使用我认为对提高软件项目的长期生存能力有用的语言。

我曾经认为XSLT是个好主意。我的意思是个好主意。

执行失败的地方。

随着时间的推移，我发现的问题是XML编程语言只是一个坏主意。它使整个事情变得坚不可摧。具体来说，我认为XSLT很难学习，编码和理解。功能方面之上的XML只会使整个事情变得混乱。在我的职业生涯中，我曾尝试学习过大约5次，但这并不持久。

好的，您可以“工具化”它-我认为这部分是它设计的重点-但这是第二个失败：市场上的所有XSLT工具都非常简单...废话！

在XSLT规范定义XSLT作为“为XML文档转换成其它XML文档的语言”。如果您想做任何事情，但XSLT内最基本的数据处理都可能有更好的解决方案。

还值得注意的是，可以使用自定义扩展功能在.NET中扩展XSLT的数据处理功能：

• MSDN文档
• CSharpFriends：教程

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

这使我们无需编写任何代码即可轻松更改文档布局。只需更改XSLT。

这对我们来说很好。在我们的情况下，它是一个只读文件。用户没有与文档进行交互。

另外，通过使用XSLT，您可以更接近问题域（HTML）。我一直认为这是个好主意。

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

它取决于您的需求。它的主要优点是转换的易维护性，编写自己的解析器通常会消除这种情况。话虽如此，有时系统很小却很简单，实际上并不需要“理想”的解决方案。只要您的基于代码的构建器是可替换的，而不必更改其他代码，那也没什么大不了的。

至于XSL的丑陋，是的丑陋。是的，这需要一些习惯。但是一旦掌握了它（不要花很长时间IMO），它实际上就很顺畅。根据我的经验，编译后的转换运行非常快，您当然可以对其进行调试。

我仍然相信XSLT可能有用，但是它是一种丑陋的语言，并且可能导致可怕的无法阅读，无法维护的混乱。部分原因是XML对人类的可读性不足以构成“语言”，部分原因是XSLT处于声明性和过程性之间。话虽如此，而且我认为可以使用正则表达式进行比较，但在解决简单的定义明确的问题时它很有用。

使用替代方法并在代码中解析XML可能同样令人讨厌，您确实想使用某种XML编组/绑定技术（例如Java中的JiBX）将XML直接转换为对象。

如果您可以声明性的方式使用XSLT（尽管我并不完全同意它是声明性语言），那么我认为它很有用且富有表现力。

我编写了使用OO语言（在我的情况下为C＃）来处理数据/处理层但输出XML而不是HTML的Web应用程序。然后，客户端可以将其直接用作数据API，也可以由XSLT将其呈现为HTML。因为C＃输出的XML与这种用法在结构上兼容，所以一切都非常顺利，并且表示逻辑保持了声明性。跟从C＃发送标签相比，跟踪和更改要容易得多。

但是，由于您需要在XSLT级别上使用更多处理逻辑，因此即使您“了解”了功能样式，它也会变得令人费解和冗长。

当然，这些天我可能已经使用RESTful界面编写了这些Web应用程序-我认为JSON等数据“语言”在XML传统上已经由XSLT转换的领域中越来越受欢迎。但是就目前而言，XSLT仍然是一项重要且有用的技术。

我在XSLT上花费了很多时间，发现它虽然在某些情况下是有用的工具，但绝对不能解决所有问题。当它用于机器可读的XML输入/输出的数据转换时，它对于B2B而言效果很好。我不认为您在陈述其局限性时走错了路。使我最沮丧的一件事是XSLT实现的细微差别。

也许您应该看看其他可用的标记语言。我相信Jeff就有关堆栈溢出的主题做了一篇文章。

HTML是人道标记语言吗？

我来看看他写了什么。您可能会找到一个“开箱即用”的软件，它可以满足您的要求，或者至少非常接近，而不是从头开始编写自己的东西。

我目前负责从公共站点抓取数据（是的，我知道）。值得庆幸的是，它符合xhtml，因此我可以使用xslt来收集所需的数据。最终的解决方案可读，干净，并且在需要时易于更改。完善！

我以前使用过XSLT。在我用C＃重写它之前，这组6个.xslt文件（从一个大文件中重构出来）大约有2750行。目前，C＃代码为4000行，其中包含很多逻辑。我什至不想考虑用XSLT写什么。

当我意识到没有XPATH 2.0严重损害了我的进步时，我就放弃了。

要回答您的三个问题：

1. 几年前，我曾经使用过XSLT。
2. 我确实相信XSLT在某些情况下可能是正确的解决方案。（永远不要把话说绝了）
3. 我倾向于同意您的评价，即它对于“简单”转换最有用。但是我认为，只要您对XSLT有很好的了解，就有必要将其用于更大的任务，例如将网站转换为XML转换为HTML。

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

xslt真正发挥作用的地方之一就是生成报告。我发现有一个两步过程，第一步将报告数据导出为xml文件，第二步使用xslt从xml生成可视报告。这样可以生成漂亮的可视报告，同时在需要时仍保留原始数据作为验证机制。

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

是的，这是一条学习曲线，但是您就有了一个强大的工具来处理XML。您甚至可以在XSLT上使用XSLT（有时可能会有用）。

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

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

我个人喜欢XSLT，您可能需要给出简化的语法（没有显式模板，只有带有几个XSLT标记的常规旧HTML文件，可向其中吐出值），但这并不适合所有人。

也许您只想为您的作者提供一个简单的Wiki或Markdown界面。也有相应的库，如果XSLT对您不起作用，则XML也可能对它们不起作用。

XSLT并不是xml转换的最终结果。但是，很难根据给出的信息来判断这是否是解决问题的最佳方法，或者是否还有其他更有效且可维护的方法。您说作者可以以简化格式输入内容-什么格式？文字框？您将其转换为哪种HTML？要判断XSLT是否是适合该工作的工具，将有助于更详细地了解此转换的功能。

我喜欢仅使用XSLT来更改XML文档的树形结构。我发现做任何与文本处理有关的事情并将其委托给我可能在将XSLT应用于XML文档之前或之后运行的自定义脚本都很麻烦。

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