不久前，我开始了一个项目，我设计了一个 html 式 XML 模式，以便作者可以以简化格式编写他们的内容（教育课程材料），然后通过 XSLT 将其转换为 HTML。我玩了（苦苦挣扎）了一段时间，并把它弄到了一个非常基本的水平，但后来对我遇到的限制（这很可能是我知识的限制）太恼火了，当我读到一篇建议放弃的博客时XSLT 并且只需使用您选择的语言编写您自己的 XML 到任何解析器，我急切地跳到了它上面，并且效果非常好。
直到今天我仍在努力（实际上我应该现在就在努力，而不是在 SO 上玩），而且我看到越来越多的事情让我认为放弃 XSLT 的决定是一个很好的。
我知道 XSLT 有它的位置，因为它是一个公认的标准，如果每个人都编写自己的解释器，90% 的人最终会使用TheDailyWTF。但是鉴于它是一种函数式风格的语言，而不是大多数程序员熟悉的过程式风格，对于像我这样从事项目的人来说，你会建议他们走我所做的道路，还是坚持使用 XSLT ?
如此多的消极情绪！
我已经使用 XSLT 好几年了，并且真的很喜欢它。您必须意识到的关键是它不是一种编程语言，它是一种模板语言（在这方面，我发现它比 asp.net /spit 优越得多）。
XML 是当今 Web 开发事实上的数据格式，无论是配置文件、原始数据还是内存表示。XSLT 和 XPath 为您提供了一种非常强大且非常有效的方法，可以将该数据转换为您可能喜欢的任何输出格式，立即为您提供将表示与数据分离的 MVC 方面。
然后是实用功能：清除命名空间、识别不同的模式定义、合并文档。
处理 XSLT肯定比开发自己的内部方法更好。至少 XSLT 是一个标准，并且您可以聘请它，如果这对您的团队来说真的是一个问题，那么很自然地会让您的大多数团队只使用 XML。
一个真实的用例：我刚刚编写了一个应用程序，它处理整个系统的内存中 XML 文档，并根据最终用户的请求转换为 JSON、HTML 或 XML。我有一个相当随机的请求作为 Excel 数据提供。一位前同事以编程方式做了类似的事情，但它需要几个类文件的模块，并且服务器安装了 MS Office！原来 Excel 有一个 XSD：3 小时内对基码影响最小的新功能。
就我个人而言，我认为这是我职业生涯中遇到的最干净的事情之一，我相信所有明显的问题（调试、字符串操作、编程结构）都归结为对工具的错误理解。
显然，我坚信这是“值得的”。
XSLT 的优点：
XSLT 的缺点：
顺便说一句，获得程序行为的一种方法是将多个变换链接在一起。在每个步骤之后，您都有一个全新的 DOM 可以处理，它反映了该步骤中的更改。一些 XSL 处理器具有扩展，可以在一次转换中有效地执行此操作，但我忘记了细节。
因此，如果您的代码主要是输出而没有太多逻辑，那么 XSLT 可以是一种非常简洁的表达方式。如果有很多逻辑，但主要是内置于 XSLT 的表单（选择所有看起来像 blah 的元素，并为每个元素输出 blah），那么它可能是一个非常友好的环境。如果您喜欢始终像 XML 一样思考，那么试试 XSLT 2。
否则，我会说，如果您最喜欢的编程语言具有支持 XPath 并允许您以有用的方式构建文档的良好 DOM 实现，那么使用 XSLT 几乎没有什么好处。与 libxml2 和 gdome2 的绑定应该做得很好，坚持使用您熟悉的通用语言并没有什么可耻的。
自制的 XML 解析器通常不是不完整的（在这种情况下，你总有一天会遇到困难），或者不会比你可以从现成的东西小很多（在这种情况下，你可能会浪费你的时间），并给出您有很多机会围绕恶意输入引入严重的安全问题。除非您确切地知道这样做会获得什么，否则不要写。这并不是说如果您不需要 XML 提供的所有内容，您就不能为比 XML 更简单的输入格式编写解析器。
我不得不承认这里有偏见，因为我以教授 XSLT 为生。但是，可能值得介绍一下我看到我的学生工作的领域。他们通常分为三组：出版、银行和网络。
到目前为止，许多答案可以概括为“它对创建网站没有好处”或“它不像语言 X”。许多技术人员在他们的职业生涯中没有接触过函数式/声明式语言。当我教学时，有经验的 Java/VB/C/等人是那些对语言有问题的人（变量是代数意义上的变量，而不是过程编程）。很多人都在这里回答——我从来没有接触过 Java，但我不会因此而费心批评这种语言。
在许多情况下，它不是创建网站的合适工具——通用编程语言可能更好。我经常需要获取非常大的 XML 文档并在 Web 上呈现它们；XSLT 使这变得微不足道。我在这个领域看到的学生倾向于处理数据集并在网络上展示它们。XSLT 肯定不是这个领域唯一适用的工具。然而，他们中的许多人正在使用 DOM 来执行此操作，而 XSLT 肯定不会那么痛苦。
我看到的银行业学生一般都使用 DataPower 盒子。这是一个 XML 设备，它用于在“说”不同 XML 方言的服务之间。在 XSLT 中从一种 XML 语言转换到另一种语言几乎是微不足道的，而且参加我的这门课程的学生人数正在增加。
我看到的最后一组学生来自出版背景（比如我）。这些人往往拥有大量的 XML 文档（相信我，作为一个行业的出版业正在深入研究 XML——技术出版业已经存在多年，而贸易出版业现在也已普及）。这些文档需要处理（这里想到的是 DocBook 到 ePub）。
上面有人评论说脚本往往低于 60 行，否则它们会变得笨拙。如果它确实变得笨拙，那么编码人员很可能还没有真正理解 - XSLT 是一种与许多其他语言非常不同的思维方式。如果你没有得到这种心态，那是行不通的。
它当然不是一种垂死的语言（我得到的工作量告诉我）。现在，在微软完成他们（非常晚的）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 自动链接到我们的错误跟踪器，错误按组件分组，并且所有内容的格式都完全一致. 上面的 XML 可以通过向我们的错误跟踪器查询版本之间发生的变化来自动生成。
我们发现 XSLT 有用的另一个地方实际上是在我们的核心产品中。有时在与第三方系统交互时，我们需要以某种方式处理复杂 HTML 页面中的数据。解析 HTML 很难看，所以我们通过TagSoup之类的东西提供数据（它生成正确的 SAX XML 事件，本质上让我们处理 HTML，就好像它是正确编写的 XML 一样）然后我们可以针对它运行一些 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（因为没有更好的选择），但不是为了演示，只是为了转换：
我编写了简短的 XSLT 转换来对我们的 maven pom.xml 文件进行大规模编辑。
我编写了一个转换管道以从 XMI（UML 图）生成 XML 模式。它工作了一段时间，但最终变得太复杂了，我们不得不把它从谷仓后面拿出来。
我使用转换来重构 XML 模式。
通过使用 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 提要、Atom 提要、RDF 描述符文件和站点地图的片段.
它不是灵丹妙药。有些事情它做得很好，也有些事情做得不好，就像编程的所有其他方面一样，这都是关于使用正确的工具来完成正确的工作。这是一个非常值得在您的工具箱中使用的工具，但只有在适当的时候才应该使用它。
我肯定会建议坚持下去。特别是如果您使用的是内置 XSLT 编辑、查看和调试工具的 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 之间进行转换的标准格式。因此，“架构师”（我指的是那些深思熟虑但显然从不编码的人）决定我们的前端将通过编写将数据转换为 XHTML 以显示的 XSLT 脚本来实现。
事实证明，这个选择是灾难性的。事实证明，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 序列化），然后通过 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 中最基本的数据处理之外的任何事情，那么可能有更好的解决方案。
另外值得注意的是，XSLT 的数据处理能力可以在 .NET 中使用自定义扩展函数进行扩展：
我仍然相信 XSLT 是有用的，但它是一种丑陋的语言，并且会导致可怕的不可读、不可维护的混乱。部分原因是 XML 的可读性不足以构成一种“语言”，部分原因是 XSLT 卡在声明性和过程性之间。话虽如此，我认为可以用正则表达式进行比较，当涉及到简单的定义明确的问题时，它有它的用途。
使用替代方法并在代码中解析 XML 可能同样令人讨厌，并且您确实希望使用某种 XML 编组/绑定技术（例如 Java 中的 JiBX）将您的 XML 直接转换为对象。
我为我的公司维护一个在线文档系统。作者使用 SGML（类似 xml 的语言）创建文档。然后将 SGML 与 XSLT 组合并转换为 HTML。
这使我们无需进行任何编码即可轻松更改文档布局。它只是改变 XSLT 的问题。
这对我们很有效。在我们的例子中，它是一个只读文档。用户没有与文档交互。
此外，通过使用 XSLT，您可以更接近您的问题域 (HTML)。我一直认为这是个好主意。
最后，如果您当前的系统工作正常，请不要管它。我绝不会建议破坏您现有的代码。如果我从头开始，我会使用 XSLT，但在你的情况下，我会使用你所拥有的。
它归结为你需要它。它的主要优势是转换的易于维护性，编写自己的解析器通常会消除这一点。话虽如此，有时系统又小又简单，真的不需要“花哨”的解决方案。只要您的基于代码的构建器是可替换的，而无需更改其他代码，没什么大不了的。
至于 XSL 的丑陋，是的，它很丑陋。是的，这需要一些时间来适应。但是一旦你掌握了它（不应该花很长时间IMO），它实际上是一帆风顺的。根据我的经验，编译后的转换运行得非常快，您当然可以调试它们。
如果您可以以声明式风格使用 XSLT（尽管我不完全同意它是声明式语言），那么我认为它是有用且富有表现力的。
我编写了使用 OO 语言（在我的例子中是 C#）来处理数据/处理层的 Web 应用程序，但输出的是 XML 而不是 HTML。然后，客户端可以将其作为数据 API 直接使用，或者由 XSLT 呈现为 HTML。因为 C# 输出的 XML 在结构上与这种用法兼容，所以一切都非常流畅，并且表示逻辑保持声明性。它比从 C# 发送标签更容易跟踪和更改。
但是，由于您在 XSLT 级别需要更多处理逻辑，因此它变得复杂和冗长 - 即使您“获得”了函数式样式。
当然，这些天我可能已经使用 RESTful 接口编写了这些 Web 应用程序——而且我认为 JSON 等数据“语言”在传统上由 XSLT 转换 XML 的领域正在获得牵引力。但就目前而言，XSLT 仍然是一项重要且有用的技术。
我在 XSLT 上花了很多时间，发现虽然它在某些情况下是一个有用的工具，但它绝对不是万能的。当它用于机器可读 XML 输入/输出的数据转换时，它非常适合 B2B 目的。我认为您在声明其局限性时没有走错路。最让我感到沮丧的事情之一是 XSLT 实现中的细微差别。
也许您应该看看其他一些可用的标记语言。我相信 Jeff 写了一篇关于 Stack Overflow 的文章。
我想看看他写的东西。您可能会找到一个“开箱即用”的软件包，或者至少非常接近，而不是从头开始编写自己的东西。
我目前的任务是从公共网站上抓取数据（是的，我知道）。谢天谢地，它符合 xhtml，所以我可以使用 xslt 来收集我需要的数据。生成的解决方案可读、干净且在需要时易于更改。完美的！
我以前使用过 XSLT。在我用 C# 重写之前，这组 6 个 .xslt 文件（从一个大文件中重构出来）大约有 2750 行。C# 代码目前有 4000 行，包含大量逻辑；我什至不想考虑用 XSLT 编写会需要什么。
当我意识到没有 XPATH 2.0 严重损害了我的进步时，我放弃了。
回答你的三个问题：
我相信许多开发人员不喜欢 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 转换为完整的 HTML 页面。事后看来，也许使用 XSLT 生成一个页面片段，该页面片段可以与使用服务器端脚本（例如 SSI）的其他片段组合在一起，这会解决我的许多问题。
可能的错误之一是通过使用 document() 函数导入 XHTML 或其他 XML 数据来尝试构建一个通用的页面布局来包围我的数据。
另一个错误是尝试执行编程操作，例如创建通用模板以在 XML 数据上生成表，其逻辑执行的操作包括对具有特定值的行使用不同的背景行颜色，并允许您指定要过滤掉的某些列。
更不用说尝试从似乎只能使用递归模板调用来解决的 XML 数据构造值的字符串列表。
我得到了什么？好吧，页面源是 XML 数据，可供查看者使用。数据和演示被巧妙地分开。
我会再做一次吗？可能不会，除非我真的想在静态页面上分离数据/表示。否则，我可能会编写一个 Rails 或 Java EE 应用程序，它可以使用模板生成 XML 视图或 HTML 视图——所有好处，但更自然的（对我而言）编程语言触手可及。
我喜欢将 XSLT 仅用于更改 XML 文档的树结构。我发现做任何与文本处理相关的事情并将其委托给我可能在将 XSLT 应用于 XML 文档之前或之后运行的自定义脚本都很麻烦。
XSLT 2.0 包含了更多的字符串函数，但我认为它不太适合该语言，并且 XSLT 2.0 的实现并不多。
我认为你做对了。以我的经验，XSLT 开发人员是最难招到的，因为它是一种无论是 Web 开发人员还是普通程序员都不会流行的语言。
因此，您最终不得不为“了解主流语言之外的语言的高级程序员”付费，但要购买一种可能不是该程序员最喜欢的语言。
我需要在这里使用 XSLT，因为有人认为解决给定问题是个好主意：我们需要从多个 XML 文件中提取一些数据，并将其连接到不同的输出格式中，以供不同的工具进行进一步处理。
首先，我认为 XSLT 是一个非常好的主意，因为它是您可以依赖的标准。这适用于简单的格式化任务，您的代码中不需要太多的编程逻辑或算法。
但是：这是一个相当多的学习曲线，因为它不是程序性的。如果你习惯了过程式编程（C、Java、Perl、PHP 等），你会错过很多常见的结构，或者你会想知道那些只是幸运的东西，有时未经训练的眼睛无法真正阅读。例如编写“可重用”代码：如果您需要在不同的地方一遍又一遍地做某事，在过程编程中，您可以定义一个函数来执行此操作。您也可以在 XSLT 中实现这样的目标，但它需要编写更多代码，并且不像普通函数那样可读/可理解。
我遇到的主要问题是，到目前为止，许多具有程序背景的人都在研究 XSLT 文件，几乎每个人都只是“模仿”他需要的东西。
所以作为一个结论：我不再将 XSLT 视为“终极”解决方案。事实上，在 XSLT 中读或写一些结构是很痛苦的。在大多数情况下，您必须考虑应用程序： 对于简单的转换，我可能会再次使用 XSLT。但是对于更复杂的软件我不会再用了。
谈到互操作性，XML 是一种信息存储标准。很多工具都以 XML 格式生成输出，还有什么比在您的应用程序中嵌入浏览器并格式化 XML 并将其放入浏览器中更好（或更简单）的方式来呈现它。
我确实广泛使用了 XSLT……几个小时。对于更改元素名称或过滤输入文档（剥离不需要的东西）等事情来说，这很酷。
其他任何事情都会很快变得复杂。这继承了复杂性，加上缺少从任何其他编程语言中使用的大多数东西（如变量）以及使 XPath 表达式不可读的简单方法，真的很受伤。
最后，XSLT 遭受了分裂：程序员不喜欢它，因为它的局限性，其他人根本无法使用它（例如，网页设计师或任何其他非程序员类型）。
如果 XSLT 被提升为某种用于 XML 的 SQL，那么情况会有些不同。首先，人们甚至不会费心去看它。那些这样做的人不会对疼痛感到惊讶。
我认为这个概念是合理的，也许执行并不像它可能的那样“干净”。
但是我认为它应该被视为一种工具，在每种情况下都使用它可能并不明智，但是在解决解决方案时永远不应该忽视工具。
我看到了非常好的 XSLT，也看到了非常糟糕的 XSLT 使用，我认为其中一些可能取决于开发人员的技能。我认为它需要开发人员同时考虑多个领域。
是未来吗？也许不是，也许有更好的解决方案..
我不知道会出现什么新技术，但至少最好学习它，增加自己的工具集肯定不是坏事吗？
我使用 XSLT 来纠正非常复杂的 xml 文件中的错误。因此，我没有处理 xml 中的错误，而是使用 xslt 来纠正它们。
这很棒。因为该语言非常强大并且适合 xml 用例。为了用一种常用的编程语言做同样的事情，每次出现新的风格时，我都需要很长时间来调整我的代码。
在不让微软决定要更改哪些内容的情况下迁移 Visual Studio 解决方案也很有用。所以转换一种解决方案。检查发生了什么变化。还原您不想更改的内容并运行 xslt 脚本对所有文件执行此工作。
所以我从来没有用它来做网络演示或类似的东西，但它可以帮助我解决基于 xml 的问题。为了解决这些问题，它真的非常强大，非常值得一看。
就纯粹的生产力而言，您最好使用其中一个 jQuery 风格的库 - pyQuery、phpQuery 等。大多数 XML 库都很糟糕，XSLT 本质上只是另一个打包为成熟语言但没有一套像样的工具的 XML 库. jQuery 使得以您选择的语言遍历和操作 XML 样式数据变得异常容易。
我在使用 XSLT 方面有过相当不错的体验，但我并没有转换成 HTML。可能是 XSLT-HTML 组合很难完成。
XSLT 1.0 是最便携的代码之一，至少在台式机和服务器计算机上是这样。因为它在大多数这些系统上都有一个（通常是多个）运行时：
这使得它非常适合构建一些需要便携性和轻量级/无需安装的应用程序。
此外，XSLT 只需要一个运行时（不需要编译器），您可以使用任何文本编辑器创建代码。因此，您可以从任何桌面轻松创建程序（好吧，一旦您掌握了语言）。