XSLT 值得吗？[已结束]

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

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

• MSDN 文档
• CSharpFriends：教程

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

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

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

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

此外，来自C++背景，这是一门非常有趣和有趣的语言。

我认为，作为将XML从一种格式转换为另一种格式的工具，它非常棒。但是，这并不是定义将 XML 作为输入并输出 Something 的算法的唯一方法。如果你的算法足够复杂，那么输入是XML的事实就变得与你选择的工具无关了 - 即在C++ / Python /其他任何东西中滚动你自己的工具。

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

XSLT 并不是 xml 转换的最终目的。但是，很难根据提供的信息来判断它是否是解决问题的最佳方法，或者是否有其他更有效和可维护的方法。你说作者可以用简化的格式输入他们的内容——什么格式？文本框？你把它转换成什么样的html？ 要判断 XSLT 是否是适合这项工作的工具，更详细地了解此转换的特征会有所帮助。

我花了很多时间在 XSLT 上，发现虽然它在某些情况下是一个有用的工具，但它绝对不是全部的。当它用于机器可读的 XML 输入/输出的数据转换时，它非常适合 B2B 目的。我不认为你在陈述它的局限性时走错了路。最让我感到沮丧的一件事是 XSLT 实现中的细微差别。

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

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

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

我记得当标准新发布时，围绕 XSLT 的所有炒作。能够使用“简单”转换构建整个 HTML UI 的所有兴奋。

让我们面对现实吧，它很难使用，几乎不可能调试，而且速度通常慢得令人难以忍受。最终结果几乎总是古怪且不太理想。

我宁愿啃掉自己的腿，也不愿使用 XSLT，而有更好的方法可以做事。它仍然有它的位置，它适用于简单的转换任务。

我喜欢只使用 XSLT 来更改 XML 文档的树结构。我发现做任何与文本处理相关的工作，并将其降级为自定义脚本，我可能会在将 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 中）或一些类似的方法，使用一种标记（尖括号）作为输出格式（HTML），使用另一种标记（如 <%...%>）作为元数据，我们会做得更好。XSLT 最令人困惑的是它是用 XML 编写的，并且从 XML 转换为 XML......很难将所有 3 个不同的 XML 文档都直接记在脑海中。

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

但是，如果您拥有更简单的数据：您有一种 XML 格式的数据，并且想要对其进行简单的更改 -- 不是完整的页面描述 DSL，而是一些简单直接的修改，那么 XSLT 是实现此目的的极好工具。它的声明性（而不是程序性）性质实际上是实现此目的的优势。

——迈克尔·彻姆赛德

XSLT的优点：

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

XSLT的缺点：

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

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

因此，如果您的代码主要是输出，并且没有太多逻辑，那么 XSLT 可能是一种非常简洁的表达方式。如果有很多逻辑，但主要是 XSLT 内置的表单（选择所有看起来像废话的元素，并且每个元素都输出废话），那么它可能是一个相当友好的环境。如果您喜欢始终以 XML 的方式思考，那么请尝试一下 XSLT 2。

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

自研的XML解析器通常要么是不完整的（在这种情况下，总有一天你会被解开），要么不会比你本来可以下架的东西小多少（在这种情况下，你可能会浪费你的时间），并给你很多机会来引入严重的安全问题。除非你确切地知道你从中得到什么，否则不要写一个。这并不是说，如果你不需要XML提供的一切，你就不能为比XML更简单的东西编写一个解析器作为你的输入格式。

这取决于你需要它做什么。它的主要优点是转换的易于维护性，编写自己的解析器通常会消除这一点。话虽如此，有时系统又小又简单，真的不需要“花哨”的解决方案。只要基于代码的构建器是可替换的，而无需更改其他代码，这没什么大不了的。

至于XSL的丑陋，是的，它很丑陋。是的，这需要一些时间来适应。但是一旦你掌握了它的窍门（应该不需要很长时间的IMO），它实际上是一帆风顺的。根据我的经验，编译的转换运行得非常快，你当然可以调试它们。

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

是的，在你学习的时候，这是一种痛苦，但大部分的痛苦都与熟悉有关。随着语言的学习，疼痛确实会减轻。

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

XSLT 很难使用，但一旦你征服了它，你就会对 DOM 和模式有一个非常透彻的理解。如果你也是XPath，那么你就会在学习函数式编程的路上，这将接触到解决问题的新技术和新方法。在某些情况下，连续转换比程序解决方案更强大。

我目前的任务是从公共站点抓取数据（是的，我知道）。值得庆幸的是，它符合 xhtml，所以我能够使用 xslt 来收集我需要的数据。由此产生的解决方案可读性强，干净，并且如果需要，易于更改。完善！

如此多的消极情绪！

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

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

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

处理 XSLT 一定比开发自己的内部方法更好。至少 XSLT 是一个标准，你可以雇用它，如果它真的对你的团队来说是一个问题，它自然会让你的大部分团队只使用 XML。

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

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

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

我以前用过 XSLT。在我用 C# 重写它之前，这组 6 个 .xslt 文件（从一个大文件重构而来）大约有 2750 行。C# 代码目前有 4000 行，包含大量逻辑;我什至不想考虑用 XSLT 编写什么。

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

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

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

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

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

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

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

回答您的三个问题：

1. 几年前我用过一次 XSLT。
2. 我确实相信 XSLT 在某些情况下可能是正确的解决方案。（永不言败）
3. 我倾向于同意你的评估，即它主要用于“简单”转换。但我认为，只要你对XSLT有很好的了解，就有理由将它用于更大的任务，比如将网站作为XML转换为HTML发布。

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

我使用 XSLT（因为缺乏更好的替代方案），但不是用于演示，只是为了转换：

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

2. 我编写了一个转换管道，用于从 XMI（UML 图）生成 XML 模式。它工作了一段时间，但最终变得太复杂了，我们不得不把它拿出来。

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

4. 我已经解决了 XSLT 中的一些限制，使用它来生成 XSLT 来执行实际工作。（有没有尝试过编写一个 XSLT，它使用在运行时之前未知的命名空间生成输出？

我不断回到它，因为它比我尝试过的其他方法更好地往返它正在处理的 XML，这些方法似乎毫无必要地丢失或只是误解了 XML。XSLT 令人不快，但我发现使用 Oxygen 可以忍受。

也就是说，我正在研究使用 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 按组件分组，并且所有内容的格式完全一致。上面的XML可以通过查询我们的bug跟踪器来自动生成，了解版本之间的变化。

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

我想说的是，对于 Web 项目来说，现在有比 XSLT 更好的方法来处理视图端，但作为一种技术，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 真正大放异彩的一个地方是生成报告。我发现这是一个 2 步过程，第一步将报告数据导出为 xml 文件，第二步使用 xslt 从 xml 生成可视化报告。这允许漂亮的可视化报告，同时在需要时仍将原始数据保留为验证机制。

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

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

尽管如此，它所赋予的易于实现的、强烈执行的关注点分离并不是我现在看到的另一种技术提供的东西——所以对于文档转换，它仍然是我推荐的东西。

如果你能以声明式风格使用 XSLT（尽管我不完全同意它是声明式语言），那么我认为它是有用且富有表现力的。

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

但是，由于您需要在 XSLT 级别使用更多的处理逻辑，因此即使您“获得”了函数样式，它也会变得复杂和冗长。

当然，现在我可能会使用 RESTful 接口编写这些 Web 应用程序 - 我认为数据“语言”（如 JSON）在传统上由 XSLT 转换的 XML 领域越来越受欢迎。但就目前而言，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++ 代码库，除了最基本的数据结构修改之外，它与所有代码库隔离开来，后者是数据库结构更改。尽管我更喜欢C++而不是任何其他语言，但我会使用我认为有用的语言来促进软件项目的长期生存能力。

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

失败的地方是执行。

随着时间的流逝，我发现的问题是，用XML编程语言只是一个坏主意。它使整个事情变得难以理解。具体来说，我认为 XSLT 很难学习、编码和理解。在功能方面之上的 XML 只会让整个事情变得过于混乱。在我的职业生涯中，我尝试过学习它大约 5 次，但它就是没有坚持下去。

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

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

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

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

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

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

到目前为止，许多答案可以概括为“它对创建网站没有好处”或“它与语言 X 完全不同”。许多技术人员在他们的职业生涯中没有接触过函数式/声明式语言。当我教书时，有经验的 Java/VB/C/etc 人员是那些对语言有问题的人（例如，变量是代数意义上的变量，而不是过程编程）。这是很多人在这里回答的问题——我从未接触过 Java，但我不会因此而费心去批评这门语言。

在许多情况下，它是创建网站的不合适工具 - 通用编程语言可能更好。我经常需要获取非常大的 XML 文档并将它们呈现在 Web 上;XSLT 使这变得微不足道。我在这个领域看到的学生倾向于处理数据集并将它们呈现在网络上。XSLT 当然不是该领域唯一适用的工具。然而，他们中的许多人都在使用 DOM 来做到这一点，而 XSLT 肯定不那么痛苦。

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

我看到的最后一批学生来自出版背景（像我一样）。这些人往往拥有大量的XML文档（相信我，出版业作为一个行业正在对XML非常感兴趣 - 技术出版已经存在多年了，而贸易出版现在正在实现）。这些文档需要处理（这里想到的是 DocBook 到 ePub）。

上面有人评论说，脚本往往低于 60 行，否则它们会变得笨拙。如果它确实变得笨拙，那么编码人员很可能还没有真正理解这个想法 - XSLT 是一种与许多其他语言截然不同的思维方式。如果你没有得到这种心态，它就行不通。

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

我个人喜欢 XSLT，您可能想看看简化的语法（没有显式模板，只是一个带有一些 XSLT 标签的常规旧 HTML 文件，可以将值吐入其中），但它并不适合所有人。

也许你只是想为你的作者提供一个简单的 Wiki 或 Markdown 界面。也有用于此的库，如果 XSLT 不适合您，也许 XML 也不适合它们。