xml XSLT 值得吗？

Is XSLT worth it?

提问by nickf

A while ago, I started on a project where I designed a html-esque XML schema so that authors could write their content (educational course material) in a simplified format which would then be transformed into HTML via XSLT. I played around (struggled) with it for a while and got it to a very basic level but then was too annoyed by the limitations I was encountering (which may well have been limitations of my knowledge) and when I read a blog suggesting to ditch XSLT and just write your own XML-to-whatever parser in your language of choice, I eagerly jumped onto that and it's worked out brilliantly.

不久前，我开始了一个项目，在该项目中我设计了一个 html 式的 XML 模式，以便作者可以以简化的格式编写他们的内容（教育课程材料），然后通过 XSLT 将其转换为 HTML。我玩了（挣扎）了一段时间，并使其达到了一个非常基本的水平，但后来对我遇到的限制（这很可能是我的知识限制）以及当我阅读建议放弃的博客时感到非常恼火XSLT 并用您选择的语言编写您自己的 XML 到任何解析器，我急切地跳到它上面并且它的工作非常出色。

I'm still working on it to this day (I'm actually supposed to be working on it right now, instead of playing on SO), and I am seeing more and more things which make me think that the decision to ditch XSLT was a good one.

直到今天我仍在努力（实际上我现在应该在努力，而不是在 SO 上），而且我看到越来越多的事情让我认为放弃 XSLT 的决定是一个很好的。

I know that XSLT has its place, in that it is an accepted standard, and that if everyone is writing their own interpreters, 90% of them will end up on TheDailyWTF. But given that it is a functional style languageinstead of the procedural style which most programmers are familiar with, for someone embarking on a project such as my own, would you recommend they go down the path that I did, or stick it out with XSLT?

我知道 XSLT 有它的位置，因为它是一个公认的标准，如果每个人都在编写自己的解释器，那么 90% 的解释器最终都会使用TheDailyWTF。但是考虑到它是一种函数式风格的语言，而不是大多数程序员熟悉的程序式风格，对于像我这样的项目的人，你会建议他们沿着我所做的道路走下去，还是坚持使用 XSLT?

采纳答案by Steve Jessop

Advantages of XSLT:

XSLT 的优点：

• Domain-specific to XML, so for example no need to quote literal XML in the output.
• Supports XPath/XQuery, which can be a nice way to query DOMs, in the same way that regular expressions can be a nice way to query strings.
• Functional language.

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

Disadvantages of XSLT:

XSLT 的缺点：

• Can be obscenely verbose - you don't have to quote literal XML, which effectively means you do have to quote code. And not in a pretty way. But then again, it's not much worse than your typical SSI.
• Doesn't do certain things which most programmers take for granted. For instance string manipulation can be a chore. This can lead to "unfortunate moments" when novices design code, then frantically search the web for hints how to implement functions they assumed would just be there and didn't give themselves time to write.
• Functional language.

• 可能非常冗长 - 您不必引用文字 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.

顺便说一下，获得程序行为的一种方法是将多个变换链接在一起。在每一步之后，您都有一个全新的 DOM 可以处理，它反映了该步骤中的更改。一些 XSL 处理器具有扩展功能，可以在一次转换中有效地做到这一点，但我忘记了细节。

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.

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

Otherwise, I'd say that if your favourite programming language has a good DOM implementation supporting XPath and allowing you to build documents in a useful way, then there are few benefits to using XSLT. Bindings to libxml2 and gdome2 should do nicely, and there's no shame in sticking to general-purpose languages you know well.

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

Home-grown XML parsers are usually either incomplete (in which case you'll come unstuck some day) or else not much smaller than something you could have got off the shelf (in which case you're probably wasting your time), and give you any number of opportunities to introduce severe security issues around malicious input. Don't write one unless you know exactly what you gain by doing it. Which is not to say you can't write a parser for something simpler than XML as your input format, if you don't need everything that XML offers.

自己开发的 XML 解析器通常要么不完整（在这种情况下你有一天会解脱）或者比你可以下架的东西小很多（在这种情况下你可能会浪费你的时间），并给出您有很多机会围绕恶意输入引入严重的安全问题。除非您确切地知道这样做会获得什么，否则不要写。这并不是说，如果您不需要 XML 提供的所有内容，您就不能为比 XML 更简单的内容编写解析器作为输入格式。

回答by annakata

So much negativity!

这么多负面！

I've been using XSLT for a good few years now, and genuinely love it. The key thing you have to realise is that it's not a programming language it's a templating language(and in this respect I find it indescribably superior to asp.net /spit).

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

XML is the de facto data format of web development today, be it config files, raw data or in memory reprsentation. XSLT and XPath give you an enormouslypowerful and very efficient way to transform that data into any output format you might like, instantly giving you that MVC aspect of separating the presentation from the data.

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

Then there's the utility abilities: washing out namespaces, recognising disparate schema definitions, merging documents.

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

It mustbe better to deal with XSLT than developing your own in-house methods. At least XSLT is a standard and something you could hire for, and if it's ever really a problem for your team it's very nature would let you keep most of your team working with just XML.

它必须是更好地应对XSLT比开发自己的内部方法。至少 XSLT 是一个标准并且您可以雇用它，如果这对您的团队来说真的是一个问题，那么您的团队中的大部分人就可以只使用 XML。

A real world use case: I just wrote an app which handles in-memory XML docs throughout the system, and transforms to JSON, HTML, or XML as requested by the end user. I had a fairly random request to provide as Excel data. A former colleague had done something similar programatically but it required a module of a few class files and that the server had MS Office installed! Turns out Excel has an XSD: new functionality with minimum basecode impact in 3 hours.

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

Personally I think it's one of the cleanest things I've encountered in my career, and I believe all of it's apparent issues (debugging, string manipulation, programming structures) are down to a flawed understanding of the tool.

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

Obviously, I strongly believe it is "worth it".

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

回答by Nic Gibson

I have to admit a bias here because I teach XSLT for a living. But, it might be worth covering off the areas that I see my students working in. They split into three groups generally: publishing, banking and web.

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

Many of the answers so far could be summarised as "it's no good for creating websites" or "it's nothing like language X". Many tech folks go through their careers with no exposure to functional/declarative languages. When I'm teaching, the experienced Java/VB/C/etc folk are the ones who have issues with the language (variables are variables in the sense of algebra not procedural programming for example). That's many of the people answering here - I've never gotten on with Java but I'm not going to bother to critique the language because of that.

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

In many circumstances it is an inappropriate tool for creating websites - a general purpose programming language may be better. I often need to take very large XML documents and present them on the web; XSLT makes that trivial. The students I see in this space tend to be processing data sets and presenting them on the web. XSLT is certainly not the only applicable tool in this space. However, many of them are using the DOM to do this and XSLT is certainly less painful.

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

The banking students I see use a DataPower box in general. This is an XML appliance and it's used to sit between services 'speaking' different XML dialects. Transformation from one XML language to another is almost trivial in XSLT and the number of students attending my courses on this are increasing.

我看到的银行业学生通常使用 DataPower 盒子。这是一个 XML 设备，用于位于“说”不同 XML 方言的服务之间。在 XSLT 中，从一种 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).

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

Someone above commented that scripts tend to be below 60 lines or they become unwieldy. If it does become unwieldy, the odds are the coder hasn't really got the idea - XSLT is a very different mindset from many other languages. If you don't get the mindset it won't work.

上面有人评论说，脚本往往低于 60 行，否则就会变得笨拙。如果它确实变得笨拙，很可能是编码人员没有真正理解这个想法 - 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.

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

回答by Adam Batkin

We use XSLT extensively for things like documentation, and making some complex configuration settings user-serviceable.

我们将 XSLT 广泛用于文档等方面，并使一些复杂的配置设置可供用户使用。

For documentation, we use a lot of DocBook, which is an XML-based format. This lets us store and manage our documentation with all of our source code, since the files are plain text. With XSLT, we can easily build our own documentation formats, allowing us to both autogenerate the content in a generic way, and make the content more readable. For example, when we publish release notes, we can create XML that looks something like:

对于文档，我们使用了很多 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>

And then using XSLT (which transforms the above to DocBook) we end up with nice release notes (PDF or HTML usually) where bug IDs are automatically linked to our bug tracker, bugs are grouped by component, and the format of everything is perfectly consistent. And the above XML can be generated automatically by querying our bug tracker for what has changed between versions.

然后使用 XSLT（将上述内容转换为 DocBook）我们最终得到了不错的发行说明（通常为 PDF 或 HTML），其中错误 ID 自动链接到我们的错误跟踪器，错误按组件分组，并且所有内容的格式完全一致. 上面的 XML 可以通过查询我们的错误跟踪器来自动生成版本之间的变化。

The other place where we have found XSLT to be useful is actually in our core product. Sometimes when interfacing with third-party systems we need to somehow process data in a complex HTML page. Parsing HTML is ugly, so we feed the data through something like TagSoup(which generates proper SAX XML events, essentially letting us deal with the HTML as if it were properly written XML) and then we can run some XSLT against it, to turn the data into a "known stable" format that we can actually work with. By separating out that transformation into an XSLT file, that means that if and when the HTML format changes, the application itself does not need to be upgraded, instead the end-user can just edit the XSLT file themselves, or we can e-mail them an updated XSLT file without the entire system needing to be upgraded.

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

I would say that for web projects, there are better ways to handle the view side than XSLT today, but as a technology there are definitely uses for XSLT. It's not the easiest language in the world to use, but it is definitely not dead, and from my perspective still has lots of good uses.

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

回答by Bill Karwin

XSLT is an example of a declarative programminglanguage.

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.

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

However, software developers generally hate such languages, because they are so different from more mainstream OO or procedural languages that they're hard to learn and debug. Their compact nature generally makes it very easy to do a lot of damage inadvertently.

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

So while XSLT is an efficient mechanism to merge data into presentation, it fails in the ease-of-use department. I believe that's why it hasn't really caught on.

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

回答by Crusty

I remember all the hype around XSLT when the standard was newly released. All the excitement around being able built an entire HTML UI with a 'simple' transform.

我记得新发布标准时所有关于 XSLT 的炒作。能够通过“简单”转换构建整个 HTML UI 的所有兴奋。

Let's face it, it is hard to use, near impossible to debug, often unbearably slow. The end result is nearly always quirky and less than ideal.

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

I will sooner gnaw off my own leg than use an XSLT while there are better ways to do things. Still it has its places, its good for simple transform tasks.

我会比使用 XSLT 更快地咬断自己的腿，而有更好的方法来做事。它仍然有它的位置，它适用于简单的转换任务。

回答by Pavel Minaev

I've used XSLT (and also XQuery) extensively for various things - to generate C++ code as part of build process, to produce documentation from doc comments, and within an application that had to work with XML in general and XHTML in particular a lot. The code generator in particular was in excess of 10,000 lines of XSLT 2.0 code spread around about a dozen separate files (it did a lot of things - headers for clients, remoting proxies/stubs, COM wrappers, .NET wrappers, ORM - to name a few). I inherited it over another guy who didn't really understand the language well, and the older bits were consequently quite a mess. Newer stuff that we wrote was mostly kept sane and readable, however, and I do not recall any particular problems with achieving that. It was certainly not any harder than doing it for C++.

我已经将 XSLT（以及 XQuery）广泛用于各种用途 - 生成 C++ 代码作为构建过程的一部分，从文档注释中生成文档，以及在必须使用一般 XML 和 XHTML 的应用程序中，特别是很多. 特别是代码生成器超过 10,000 行 XSLT 2.0 代码，分布在大约十几个单独的文件中（它做了很多事情 - 客户端的标头、远程代理/存根、COM 包装器、.NET 包装器、ORM - 以命名一些）。我从另一个不太了解语言的人那里继承了它，因此旧的部分非常混乱。然而，我们编写的较新的东西大多保持理智和可读性，我不记得实现这一点有任何特别的问题。这当然并不比为 C++ 做更难。

Speaking of versions, dealing with XSLT 2.0 definitely helps keep you sane, but 1.0 is still alright for simpler transforms. In its niche, it is an extremely handy tool, and the productivity you get from certain domain-specific features (most importantly, dynamic dispatch via template matching) is hard to match. Despite the perceived wordiness of XSLT's XML-based syntax, the same thing in LINQ to XML (even in VB with XML literals) was usually several times longer. Quite often, however, it gets undeserved flack because of unnecessary use of XML in some case in the first place.

说到版本，处理 XSLT 2.0 肯定有助于保持理智，但 1.0 仍然适用于更简单的转换。在它的细分市场中，它是一个非常方便的工具，您从某些特定于域的功能（最重要的是，通过模板匹配进行动态调度）获得的生产力是难以匹敌的。尽管可以感觉到 XSLT 的基于 XML 的语法冗长，但在 LINQ to XML（即使在具有 XML 文字的 VB 中）中的相同内容通常要长几倍。然而，很多时候，由于在某些情况下首先不必要地使用 XML，它会受到不应有的抨击。

To sum it up: it is an incredibly useful tool to have in one's toolbox, but it is a very specialized one, so it is good so long as you use it properly and for its intended purpose. I really wish there was a proper, native .NET implementation of XSLT 2.0.

总结一下：这是一个非常有用的工具，可以放在一个人的工具箱中，但它是一个非常专业的工具，所以只要你正确使用它并达到预期目的，它就很好。我真的希望有一个适当的、原生的 .NET 实现 XSLT 2.0。

回答by bendin

I use XSLT (for lack of better alternative), but not for presentation, just for transformation:

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

1. I write short XSLT transformations to do mass edits on our maven pom.xml files.

2. I've written a pipeline of transformations to generate XML Schemas from XMI (UML Diagram). It worked for a while, but it finally got too complex and we had to take it out behind the barn.

3. I've used transformations to refactor XML Schemas.

4. I've worked around some limitations in XSLT by using it to generate an XSLT to do the real work. (Ever tried to write an XSLT that produces an output using namespaces that aren't known until runtime?)

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

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

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

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

I keep coming back to it because it does a better job round-tripping the XML it's processing than other approaches I've tried, which have seemed needlessly lossy or simply misunderstand XML. XSLT is unpleasant, but I find using Oxygenmakes it bearable.

我一直回到它，因为与我尝试过的其他方法相比，它在往返处理它处理的 XML 方面做得更好，这些方法似乎不必要地有损或只是误解了 XML。XSLT 令人不快，但我发现使用Oxygen使其可以忍受。

That said, I'm investigating using Clojure(a lisp) to perform transformations of XML, but I haven't gotten far enough yet to know if that approach will bring me benefits.

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

回答by Tom Leys

Personally I used XSLT in a totally different context. The computer game that I was working on at the time used tons of UI pages defined using XML. During a major refactor shortly after a release we wanted to change the structure of these XML documents. We made the game's input format follow a much better and schema aware structure.

我个人在完全不同的上下文中使用 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.

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

Also, coming from a C++ background, it was a very fun and interesting language to master.

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

I think that as a tool to translate XML from one format to another it is fantastic. However, it is not the only way to define an algorithm that takes XML as an input and outputs Something. If your algorithm is sufficiently complex, the fact that the input is XML becomes irrelevant to your choice of tool - i.e roll your own in C++ / Python / whatever.

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

Specific to your example, I would imagine the best idea would be to create your own XML->XML convert that follows your business logic. Next, write a XSLT translator that just knows about formatting and does nothing clever. That might be a nice middle ground but it totally depends what you are doing. Having a XSLT translator on the output makes it easier to create alternative output formats - printable, for mobiles, etc.

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

回答by Alohci

Yes, I use it a lot. By using different xslt files, I can use the same XML source to create multiple polyglot (X)HTML files (presenting the same data in different ways), a RSS feed, an Atom feed, a RDF descriptor file and fragment of a site map.

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

It's not a panacea. There are things it does well, and things it doesn't do well, and like all other aspects of programming, it's all about using the right tool for the right job. It's a tool that's well worth having in your toolbox but it should used only when it's appropriate to do so.

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