XSLT值得吗？
前一段时间，我开始了一个项目，在那里我devise了一个html-esque的XML模式，以便作者能够以简化的格式编写他们的内容（教育课程材料），然后通过XSLT将其转换为HTML。 我玩了一段时间，并把它弄到一个非常基本的水平，但后来因为我遇到的限制而感到非常恼火（这可能是我的知识的限制），而且当我读博客时build议去沟XSLT，只要用你自己select的语言编写你自己的XML到任何parsing器，我就急于跳到这个语言上，并且出色地完成了。
我至今仍在努力（ 现在我应该正在努力，而不是在SO上 ），而且我看到越来越多的事情让我觉得决定放弃XSLT是一个好的。
我知道XSLT有其自身的地位，因为它是一个公认的标准，如果每个人都在写自己的口译人员，他们中的90％最终会在TheDailyWTF上出现 。 但是鉴于这是一种function性风格的语言，而不是大多数程序员熟悉的程序风格，对于像我自己这样开始项目的人， 你会推荐他们走下我所做的道路，还是用XSLT ？
XSLT的优点：
- 特定于域的XML，例如，不需要在输出中引用文字XML。
- 支持XPath / XQuery，这是一种查询DOM的好方法，正则expression式可以成为查询string的好方法。
- function语言。
XSLT的缺点：
- 可以是淫秽的冗长 – 你不必引用文字XML，这实际上意味着你必须引用代码。 而不是一个漂亮的方式。 但是再一次，它不比你的典型SSI差太多。
- 不要做大多数程序员认为理所当然的事情。 例如string操作可能是一件杂事。 当新手devise代码时，这可能会导致“不幸的时刻”，然后疯狂地searchnetworking提示如何实现他们认为只是在那里的function，没有时间写。
- function语言。
顺便获得程序行为的一种方式是将多个变换链接在一起。 在每一步之后，你都有一个全新的DOM来工作，这反映了这一步的变化。 一些XSL处理器有扩展，可以在一次转换中有效地做到这一点，但我忘记了细节。
所以，如果你的代码大部分是输出而不是很多的逻辑，那么XSLT可以是一个很好的expression方式。 如果有很多的逻辑，但主要是内置到XSLT的forms（select所有元素看起来像是等等，每个输出等等），它可能是一个相当友好的环境。 如果你喜欢随时想XML，那么就给XSLT 2一下。
否则，我会说，如果你最喜欢的编程语言有一个很好的支持XPath的DOM实现，并允许你以一种有用的方式构build文档，那么使用XSLT就没有什么好处了。 绑定到libxml2和gdome2应该很好，并且坚持使用你熟悉的通用语言并不是件难事。
本土化的XMLparsing器通常不完整（在这种情况下，你将会在某一天失去存储空间），否则就不会比你能够下架的东西（在这种情况下你可能正在浪费你的时间）小得多，你有任何机会围绕恶意input引入严重的安全问题。 不要写一个，除非你确切地知道你从中得到了什么。 如果你不需要XML提供的所有东西，那么就不能说你不能为比XML更简单的语法编写parsing器。
非常消极！
我已经使用XSLT好几年了，真的很喜欢它。 你必须意识到的关键是， 它不是一种编程语言，它是一种模板语言 （在这方面，我觉得它不可思议地优于asp.net / spit）。
XML是当今Web开发事实上的数据格式，无论是configuration文件，原始数据还是内存再分析。 XSLT和XPath为您提供了一种非常强大且非常高效的方法，可以将数据转换为您可能喜欢的任何输出格式，并即时为您提供从数据中分离演示的MVC方面。
然后是实用程序能力：清除命名空间，识别不同的模式定义，合并文档。
处理XSLT比开发自己的内部方法要好一些。 至lessXSLT是一个标准，你可以聘请一些东西，如果这对你的团队来说真的是一个问题，那么很自然就会让你的大部分团队只用XML。
一个真实世界的用例：我只写了一个应用程序，它在整个系统中处理内存中的XML文档，并根据最终用户的请求转换为JSON，HTML或XML。 我有一个相当随机的请求提供Excel数据。 以前的一位同事在编程上做了类似的事情，但是它需要一个包含less量类文件的模块，而且服务器上安装了MS Office！ 结果Excel有一个XSD：新function，在3小时内对基本代码的影响最小。
就我个人而言，我认为这是我在职业生涯中遇到的最干净的事情之一，我相信所有显而易见的问题（debugging，string处理，编程结构）都是对这个工具有缺陷的理解。
显然，我坚信这是“值得的”。
我不得不在这里承认一个偏见，因为我教XSLT谋生。 但是，这可能是值得我看到我的学生工作的地区。他们一般分为三类：出版，银行和networking。
到目前为止，许多答案可以概括为“创build网站没有好处”或“与X语言无关”。 许多技术人员在职业生涯中没有接触到function/陈述语言。 当我在教学时，经验丰富的Java / VB / C /等人就是那些对语言有问题的人（variables是代数意义上的variables而不是程序编程）。 这是很多人在这里回答 – 我从来没有使用Java，但我不打算因此而批评语言。
在许多情况下，它是创build网站的不恰当工具 – 通用编程语言可能会更好。 我经常需要将非常大的XML文档呈现在网页上; XSLT使这个微不足道。 我在这个领域看到的学生倾向于处理数据集并在networking上呈现。 XSLT当然不是这个领域唯一适用的工具。 然而，他们中的许多人正在使用DOM来做到这一点，XSLT肯定不那么痛苦。
我看到的银行学生通常使用DataPower框。 这是一个XML设备，它被用于坐在服务“说话”不同的XML方言之间。 从一种XML语言到另一种XML语言的转换在XSLT中几乎是微不足道的，参加我的课程的学生人数正在增加。
我看到的最后一批学生来自出版背景（像我一样）。 这些人倾向于在XML中拥有巨大的文档（相信我，出版业作为一个行业正在进入XML – 技术出版已经存在多年，贸易出版现在已经到了那里）。 这些文件需要进行处理（DocBook到ePub这里才浮现）。
上面有人评论说，脚本往往低于60行，或变得笨重。 如果它变得笨拙的话，编码人员的可能性并不是真的有这样的想法 – XSLT与其他许多语言的思维模式是截然不同的。 如果你没有得到的心态，它将无法正常工作。
这当然不是一个垂死的语言（我得到的工作量告诉我）。 现在，在微软完成XSLT 2的（非常晚的）实现之前，它有点“卡住”了。但是它仍然存在，从我的angular度来看似乎很强劲。
我们广泛地使用XSLT来处理文档等事情，并使一些复杂的configuration设置成为用户可用的。
对于文档，我们使用了很多DocBook，这是一种基于XML的格式。 这使我们可以存储和pipe理我们的所有源代码文档，因为这些文件是纯文本的。 借助XSLT，我们可以轻松构build自己的文档格式，从而使我们能够以通用方式自动生成内容，并使内容更具可读性。 例如，当我们发布发行说明时，我们可以创build如下所示的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按组件分组，并且所有事情的格式完全一致。 上面的XML可以通过查询我们的bug跟踪器来自动生成版本之间的变化。
我们发现XSLT有用的另一个地方实际上是我们的核心产品。 有时，当与第三方系统连接时，我们需要以某种方式在复杂的HTML页面中处理数据。 所以我们通过类似于TagSoup （它产生适当的SAX XML事件，本质上让我们处理HTML，就好像它是正确写入的XML）一样的东西来提供数据，然后我们可以运行一些XSLT来对付它，数据转换成我们实际可以使用的“已知稳定”格式。 通过把这个转换分离出来成为一个XSLT文件，这意味着如果当HTML格式发生变化时，应用程序本身不需要升级，相反，最终用户可以自己编辑XSLT文件，也可以通过电子邮件他们是一个更新的XSLT文件，而不需要升级整个系统。
我想说，对于Web项目来说，现在有比XSLT更好的方式来处理视图方面，但作为一种技术，XSLT肯定是有用的。 这不是世界上最容易使用的语言，但绝对不是死的，从我的angular度来看还是有很多好用的。
XSLT是声明式编程语言的一个例子。
声明性编程语言的其他例子包括正则expression式，Prolog和SQL。 所有这些都具有很强的performance力和紧凑性，而且通常devise得非常好，而且function强大。
然而，软件开发人员通常讨厌这样的语言，因为它们与更主stream的面向对象程序或程序语言是截然不同的，他们很难学习和debugging。 它们紧凑的性质一般很容易在不经意间造成很大的伤害。
所以尽pipeXSLT是将数据合并到表示中的有效机制，但它在易用性部门中失败了。 我相信这就是为什么它没有真正的抓住。
当标准刚刚发布的时候，我记得所有关于XSLT的宣传。 所有的兴奋都可以通过一个简单的转换来构build一个完整的HTML UI。
让我们面对它，这是很难使用，几乎不可能debugging，往往难以忍受的慢。 最终的结果几乎总是古怪而不甚理想。
我会更快地啃掉自己的腿，而不是使用XSLT，而有更好的方法来做事。 它仍然有它的地方，它对于简单的变换任务是有好处的。
我已经广泛地使用XSLT（也包括XQuery）来生成各种各样的东西 – 生成C ++代码作为构build过程的一部分，从doc注释生成文档，以及在一般的应用程序中使用XML，尤其是XHTML 。 特别是代码生成器超过了10,000行的XSLT 2.0代码，散布在大约十几个单独的文件中（它为客户端，远程代理/存根，COM封装器，.NET封装器，ORM做了许多事情）一些）。 我inheritance了另外一个不太了解语言的人，因此老一点的东西相当混乱。 我们写的新东西大多保持清晰可读，但是我不记得有什么特别的问题可以实现。 这当然不比C ++更难。
说到版本，处理XSLT 2.0肯定有助于保持理智，但对于简单的转换，1.0仍然可以。 在它的利基，它是一个非常方便的工具，并从特定的领域特定的function（最重要的是，通过模板匹配的dynamic调度），你的生产力很难匹配。 尽pipeXSLT的基于XML的语法有一定的歧义性，但是在LINQ to XML（甚至在VB中使用XML文字）中的相同事情通常要长数倍。 然而，经常在某些情况下，由于不必要地使用XML而导致错误的结果。
总而言之，这是一个非常有用的工具，但它是一个非常专业化的工具，所以只要你正确地使用它并达到它的目的，它就是好的。 我真的希望有一个适当的本地.NET实现的XSLT 2.0。
我使用XSLT（缺乏更好的替代方法），但不是用于演示，仅用于转换：
-
我编写简短的XSLT转换来对我们的maven pom.xml文件进行批量编辑。
-
我已经编写了一个转换stream水线来从XMI（UML Diagram）生成XML Schema。 它工作了一段时间，但它终于太复杂了，我们不得不把它在谷仓后面。
-
我已经使用转换来重构XML模式。
-
我已经解决了XSLT中的一些限制，通过使用它来生成XSLT来完成真正的工作。 （曾经试过编写一个XSLT，它使用直到运行时才知道的命名空间来生成输出？）
我不断回来，因为它比我尝试过的其他方法更好地处理它正在处理的XML，这些方法似乎是不必要的损失或者只是误解了XML。 XSLT是不愉快的，但我发现使用氧气使它可以忍受。
也就是说，我正在调查使用Clojure （一个lisp）来执行XML的转换，但是我还没有得到足够的信息来知道这种方法是否会给我带来好处。
就我个人而言，我在完全不同的上下文中使用了XSLT。 我当时正在使用的计算机游戏使用了大量使用XML定义的UI页面。 在发布不久之后的一个主要的重构过程中，我们想要改变这些XML文档的结构。 我们使游戏的input格式遵循更好的和模式感知的结构。
XSLT似乎是旧格式翻译的最佳select – >新格式。 在两周之内，我们有数百页的从旧到新的转换。 我也能够使用它来提取我们的UI页面布局的大量信息。 我创build了哪些组件被embedded的列表，这些列表相对容易，然后使用XSLT写入我们的模式定义。
另外，来自C ++的背景，这是一个非常有趣和有趣的语言掌握。
我认为，作为将XML从一种格式转换为另一种格式的工具，这是太棒了。 但是，定义一个将XML作为input并输出Something的algorithm并不是唯一的方法。 如果你的algorithm足够复杂，那么input是XML的事实与你select的工具无关 – 也就是在C ++ / Python /里面自己编译。
具体到你的例子，我想最好的想法是创build你自己的XML-> XML转换，遵循你的业务逻辑。 接下来，写一个XSLT翻译器，它只是知道格式，并没有什么聪明的。 这可能是一个很好的中间地带，但完全取决于你在做什么。 在输出上使用XSLT转换器可以更容易地创build替代输出格式 – 可打印的，用于移动设备等。
是的，我用了很多。 通过使用不同的xslt文件，我可以使用相同的XML源创build多个polyglot（X）HTML文件（以不同的方式显示相同的数据），RSS提要，Atom提要，RDF描述符文件和站点地图片段。
这不是万能的。 有些事情做得很好，事情做得不好，像编程的所有其他方面一样，都是使用正确的工具来做正确的工作。 这是一个非常值得在工具箱中使用的工具，但只有在适当的情况下才能使用。
我肯定会build议坚持下去。 特别是如果您正在使用内置了用于XSLT的编辑，查看和debugging工具的Visual Studio。
是的，在你学习的时候，这是一种痛苦，但是大部分的痛苦是与熟悉有关。 当你学习这门语言时，疼痛会消失。
W3schools有两个特别值得的文章： http : //www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp
我发现XSLT相当困难。
我曾经有过一个与你描述的系统有点类似的系统。 我的公司指出，我们从“中间层”返回的数据是用XML表示的，页面是用HTML来表示的，这也可能是XHTML，再加上他们听说XSL是在XML之间转换的标准格式。 所以“架构师”（我指的是那些认为深度devise思想但明显从不代码的人）决定通过编写将数据转换成XHTML来显示的XSLT脚本来实现我们的前端层。
select结果是灾难性的。 事实certificate，XSLT是一个很难写的东西。 所以我们所有的页面都很难写和维护。 使用JSP（这是用Java语言编写的）或者一些类似的方法，使用输出格式（HTML）的一种标记（尖括号）和另一种标记（比如<％…） ％>）的元数据。 关于XSLT最令人困惑的是，它是用XML编写的，它从XML转换成XML ……想要把所有3种不同的XML文档保持一致是非常困难的。
您的情况稍有不同：不像我这样在XSLT中创build每个页面，只需要在XSLT中编写一个代码（从模板转换为显示的代码）。 但是，听起来你可能碰到了和我一样的困难。 我想说的是，试图解释一个简单的基于XML的DSL（域特定语言）就像你正在做的不是XSLT的强项之一。 （尽pipe它可以完成这项工作…毕竟，它是图灵完成！）
但是，如果您的数据更简单：您拥有一种XML格式的数据，并希望对其进行简单的更改，而不是完整的页面描述DSL，但是需要进行一些简单的直接修改，那么XSLT就是一个很好的工具。 这是声明性的（而不是程序性的）性质实际上是为此目的的一个优点。
Michael Chermside
XSLT很难处理，但是一旦你征服了它，你将对DOM和模式有一个非常透彻的理解。 如果你也是XPath的话，那么你在学习函数式编程的道路上，这将暴露出新的技术和解决问题的方法。 在某些情况下，连续转换比程序化解决scheme更为强大。
我广泛地使用XSLT来定制MVC风格的前端。 模型是“序列化”到XML（不通过XML序列化），然后通过xslt转换为HTML。 ASP.NET的优势在于与XPath的自然集成，以及更严格的格式要求（在xslt中比其他语言更容易推理文档结构）。
不幸的是，这个语言包含了一些限制（例如，转换另一个转换的输出的能力），这意味着偶尔会感到沮丧。
尽pipe如此，我们所看到的另一项技术并不是我现在所能提供的另一种技术，因此对于文档转换，我仍然会推荐它。
2004年的某个时候，我在一个非常类似的数据库系统之间的集成项目中使用了XML，XSD和XSLT。我不得不从零开始学习XSD和XSLT，但并不困难。 关于这些工具的好处是，它使我能够编写独立于数据的C ++代码，依靠XSD和XSLT来validation/validationXML文档。 更改数据格式，更改XSD和XSLT文档，而不是使用Xerces库的C ++代码。
感兴趣的是：主要的XSD是150KB，XSLT的平均大小是<5KB IIRC。
另一个很大的好处是XSD是XSLT所基于的规范文档。 两人和睦相处。 目前规范在软件开发中很less见。
虽然我没有太多的麻烦学习声明性的XSD和XSLT，但是我发现其他C / C ++程序员在调整声明方式方面遇到了很大的麻烦。 当他们看到这个时候，他们喃喃自语的程序，现在我明白了！ 他们继续（双关语）编写程序化的XSLT！ 问题是你必须学习XPath并理解XML的轴。 提醒我在编写C ++时习惯使用OO的C程序员。
我使用了这些工具，因为它们使我能够编写一个小型的C ++代码库，这个C ++代码库除了最基本的数据结构修改之外都是隔离的，而后者是DB结构的变化。 尽pipe我更喜欢C ++到任何其他语言，但我会使用我认为有益于软件项目的长期可行性。
我曾经认为XSLT是一个好主意。 我的意思是这是个好主意。
执行失败的地方。
随着时间的推移，我发现的问题是XML中的编程语言只是一个坏主意。 它使整个事情变得难以逾越。 具体而言，我认为XSLT是非常艰苦的学习，代码和理解。 function方面的XML只是让整个事情变得混乱。 在我的职业生涯中，我尝试了5次左右的学习，但并不坚持。
好吧，你可以'工具' – 我认为这是它的devise的一部分 – 但这是第二次失败：市场上所有的XSLT工具，很简单…废话！
XSLT规范将XSLT定义为“将XML文档转换为其他XML文档的语言”。 如果您正在尝试除XSLT中最基本的数据处理之外的任何事情，那么可能会有更好的解决scheme。
另外值得注意的是，XSLT的数据处理能力可以使用自定义扩展函数在.NET中进行扩展：
- MSDN文档
- CSharpFriends：教程
我为我的公司维护一个在线文档系统。 编写者在SGML中创build文档（类似于xml的语言）。 然后将SGML与XSLT结合并转换成HTML。
这使我们可以轻松地对文档布局进行更改，而无需进行任何编码。 它只是改变XSLT的一个问题。
这对我们很好。 在我们的例子中，它是一个只读文件。 用户不与文档进行交互。
另外，通过使用XSLT，您正在更接近您的问题域（HTML）。 我总是认为这是个好主意。
最后，如果您目前的系统正常工作，请保持独立。 我永远不会build议摧毁你现有的代码。 如果我从头开始，我会使用XSLT，但在你的情况下，我会使用你的。
这归结于你所需要的。 它的主要优点是转换的易维护性，编写自己的parsing器通常会消除这种情况。 有了这个说法，有时一个系统是小而简单的，真的不需要一个“奇特”的解决scheme。 只要你的代码生成器是可replace的，而不必更改其他代码，没有什么大不了的。
至于XSL的丑陋，是的，这是丑陋的。 是的，这需要一些习惯。 但一旦你掌握了它（不应该需要很长时间的海事组织），它实际上是一帆风顺的。 根据我的经验，编译转换的速度相当快，您当然可以debugging它们。
我仍然相信XSLT是有用的，但它是一个丑陋的语言，可能会导致一个可怕的，难以理解的，难以维护的混乱。 部分原因是由于XML不足以构成“语言”，部分原因是XSLT处于声明式和程序式之间。 话虽如此，我认为可以用正则expression式来进行比较，但对于简单的定义明确的问题来说却是有用的。
在代码中使用替代方法和parsingXML可能同样令人讨厌，而且您确实希望使用某种XML编组/绑定技术（例如Java中的JiBX），将XML直接转换为对象。
如果你可以在声明式风格中使用XSLT（尽pipe我不完全同意它是声明式语言），那么我认为这是有用的和expression性的。
我已经编写了使用OO语言的Web应用程序（在我的情况下是C＃）来处理数据/处理层，但输出XML而不是HTML。 然后这可以由客户端直接作为数据API使用，或者由XSLT呈现为HTML。 因为C＃输出的XML在结构上与这个用法相兼容，所以非常stream畅，expression逻辑保持声明。 比从C＃发送标签更容易跟踪和更改。
但是，由于您在XSLT级别需要更多的处理逻辑，所以它会变得复杂而冗长 – 即使您“获得”了function样式。
当然，现在我可能已经使用RESTful接口编写了这些Web应用程序 – 而且我认为像JSON这样的数据“语言”正在XML传统上被XSLT转换的领域获得了推动力。 但是现在XSLT仍然是一个重要且有用的技术。
我在XSLT上花了很多时间，发现它在某些情况下是一个有用的工具，但它绝对不是一个解决scheme。 当用于机器可读的XMLinput/输出的数据转换时，它可以很好地用于B2B目的。 我不认为你在陈述其局限性方面是错误的。 最令我沮丧的事情之一是XSLT实现中的细微差别。
也许你应该看看其他一些可用的标记语言。 我相信Jeff做了一篇关于Stack Overflow的文章。
HTML是一种人性化的标记语言吗？
我会看看他写的东西。 你也许可以find一个软件包，它可以“开箱即用”的方式做你想做的事情，或者至less非常接近，而不是从头开始编写自己的东西。
我目前的任务是从公共网站上抓取数据（是的，我知道）。 谢天谢地，它符合xhtml，所以我可以使用xslt来收集我需要的数据。 由此产生的解决scheme是可读的，干净，容易改变，如果需要的话。 完善！
我以前使用过XSLT。 在用C＃重写之前，一组6个.xslt文件（重构了一个大文件）大约是2750行。 C＃代码目前有4000行，包含大量的逻辑; 我甚至不想考虑在XSLT中写入什么内容。
我放弃的一点是，当我意识到没有XPATH 2.0显着地伤害了我的进步。
回答你的三个问题：
- 我几年前曾经使用过XSLT。
- 我相信XSLT在某些情况下可能是正确的解决scheme。 （永不说永不）
- 我倾向于同意你的评价，认为这对“简单”的转变是最有用的。 但是我认为，只要你理解了XSLT，就可以将它用于更大的任务，比如将XML转换成HTML的网站。
我相信许多开发人员不喜欢XSLT的原因是因为他们不了解它所基于的根本不同的范例。 但是随着最近对函数式编程的兴趣，我们可能会看到XSLT正在东山再起…
xslt真正闪耀的一个地方就是生成报告。 我发现这是一个2步骤的过程，第一步将报告数据导出为xml文件，第二步使用xslt从xml生成可视化报告。 这样可以提供良好的可视化报告，同时仍然保留原始数据作为validation机制，如果需要的话。
在以前的公司，我们用XML和XSLT做了很多。 XML和XSLT都很大。
是的，有一个学习曲线，但是你有一个强大的工具来处理XML。 而且你甚至可以在XSLT上使用XSLT（有时可能有用）。
性能也是一个问题（使用非常大的XML），但是您可以使用智能XSLT解决这个问题，并使用（生成的）XML进行一些预处理。
任何知晓XSLT的人都可以改变成品的外观，因为它没有被编译。
我个人喜欢XSLT，你可能想给简化的语法看一看（没有明确的模板，只是一个普通的旧的HTML文件，只有一些XSLT标签可以向其中添加值），但并不适合每个人。
也许你只是想给你的作者一个简单的Wiki或Markdown界面。 也有这样的库，如果XSLT不适合你，也许XML也不适合他们。
XSLT不是最终所有的XML转换。 但是，根据所给出的信息判断问题是否是解决问题的最佳scheme，或者是否还有其他更有效和可维护的方法，则很难进行判断。 你说作者可以用简化的格式input他们的内容 – 什么格式？ 文本框？ 你把它转换成什么样的html？ 为了判断XSLT是否是正确的工具，这将有助于更详细地了解这种转换的特点。
我喜欢只使用XSLT来更改XML文档的树结构。 我发现执行与文本处理相关的任何事情都很麻烦，并将其转化为可以在将XSLT应用于XML文档之前或之后运行的自定义脚本。
XSLT 2.0包含了更多的string函数，但是我认为它不适合这种语言，XSLT 2.0的实现也不多。
