根据我在奥斯陆所见，声明式 XML 将发挥关键作用。 我是否可以期望使用大量设计者生成的 XML 来创建现实世界的应用程序？ 只是知道我还没有研究过这个。 如果您研究过这个主题，我会很欣赏您的观点。
一些背景...
每当我深入了解任何 XML 支持的声明性技术（例如 Silverlight 和 WPF、ASP.NET 或 MSBuild）时，我似乎最终都会编辑大量原始 XML文本。 设计师很少能够满足我的需求。
一方面，我实在看不出人类和机器可读性之间有更好的折衷，而且公平地说，XML 编辑体验随着每次的化身而变得更好。
另一方面，我还没有发现 XML 适合其某些用途。 特别是在表达逻辑、重构和可测试性方面。 可能是设计者太弱，或者是XML太具有表现力，或者是我，脾气太暴躁，被对象和方法宠坏了。
Based on what I've seen on Oslo, declarative XML will have a key role. Can I expect to be mucking around a lot of designer generated XML to create real world applications? Just know I haven't researched this. I would just appreaciate your perspective if you have examined the subject.
Some background...
Whenever I dig just under the skin of any XML backed declarative technology (such as Silverlight and WPF, ASP.NET, or MSBuild) it seems I end up editing a lot of raw XML text. The designers are seldom expressive enough for my needs.
One one hand I can't really see better compromise between human and machine readability, and to be fair, the XML editing experience gets better with each incarnation.
On the other hand I havn't found XML ideal for some of its usages. Especially when it comes to expressing logic, and for refactoring and testability. May it be the designers are too weak, or the XML too expressive, or I, too grumpy and spoiled by objects and methods.
发布评论
评论（2）
我倾向于成为一个有点可疑的 XML 拥护者。 尽管我每天都使用它，并且基于 XML 的 Web 服务已经成为我职业生涯的很大一部分（也是我写的书的基础），但我认为它被广泛过度使用。 我倾向于认为你的工具箱里应该有很多工具，并且你应该使用最好的工具来完成工作。 对于很多事情来说，XML 都是一个很好的解决方案。 但有很多事情并不是这样，有些事情可能是一个糟糕的选择。
正如有些人热衷于批评和回避 XML，有些人也热衷于（或者更热衷于）赞扬和使用它。 在您上面随意提到的情况下，您大部分讨论的是基于网络的技术。 在这些情况下，您通常已经有了可用的 XML 解析器和/或 DOM 操纵器，因此使用它没有什么坏处。 您还没有增加复杂性，因为它已经存在了。 闪光& AIR 大量使用 XML 来实现功能，但它们的目标环境是解析 XML 式标记（如果不是 XML 本身，则为 HTML 或 XHTML）是每个应用程序的核心部分。 对于这些技术，引入不同类型的数据表达语言将会增加复杂性。 使用 XML 非常有意义。
这是一个例子...这里讨论的语言是 Perl，因为这是我主要使用的语言，但它的 Perl 方面与要点无关：我一直在研究转储深层数据的现有模块的扩展结构。 对于很多事情都很有用——序列化、跨平台的可移植性等等。也是一种流行的调试工具。 我想要扩展它的原因是，真正大型且复杂的结构（例如由 ORM 或 MOP 框架生成的结构）可能会变得非常复杂。 所以我的第一个想法是制作一个扩展，让我能够以一种我可以控制的方式将数据转换为 HTML。 然后我想，如果我可以创建显示各种元素以及哪些元素链接到哪些元素等的图表，那就太好了。然后我突然想到，如果我选择合理的中性格式，我应该能够相当容易地得出这两者。
那个格式？ XML。 在这种情况下，为什么它一定比本机 Perl 序列化结构更好，或者比使用不同的临时表示（例如 YAML 或 JSON）更好？ 因为如果我有有效的、格式良好的 XML，我可以轻松地使用 XSLT 将其转换为 (X)HTML 或 SVG。 如果需要，我还可以将其转换为纯文本（我已经有 XSLT 样式表，可以根据用户的选择选择发出 HTML 片段或干净地自动换行的纯文本）。
有很多方法可以解决这个特定问题，但是 XML 在这种情况下给我带来的优势使其成为首选（至少就我的偏好和需求而言）。 XSLT 是一个定义明确、文档齐全（好吧，对于 W3C 文档，您的看法可能会有所不同，但不乏有关该主题的书籍）工具，用于将 XML 转换为几乎任何内容。 对于这个特定问题，XML 的表现力加上我的最终目标格式（XHTML 和 SVG）本身就是 XML 这一事实，使其成为明确的选择。 另一方面，我曾多次（作为顾问）向客户或（作为公司员工/团队成员）向老板/团队推荐 XML 不用于某些任务。 有时原因很清楚——使用 XML 不会提高数据的（重）可用性，他们还没有在项目中使用 XML，这不是您应该引入该依赖项的那种事情，等等有时原因更为微妙； 如果您尝试决定如何存储/检索应用程序的配置，它真的需要采用 XML 格式吗？ 任何其他应用程序都不太可能需要读取/解析它，因此数据的可移植性/重用不是问题。 如果数据本质上相当平坦，您可能可以使用键/值对文件进行管理。 如果数据更复杂和/或复杂，您可能可以使用 YAML。
一般来说，XML 是数据表达的最差选择，除非它是最佳选择。 JSON 和 YAML 也是如此，充分利用这些方法的最佳方法是熟悉并熟悉所有这些方法，并知道哪一个是最适合您当前工作的工具你。
I tend to make for a somewhat dubious champion of XML. Despite the fact that I use it daily, and that XML-based webservices have been a large part of my career (and the basis for the book I wrote), I think it is widely over-used. I tend to belong to the school-of-thought that believes you should have many tools in your toolbox, and you should use the best tool for the job. There are a lot of things for which XML is an excellent solution. But there are plenty of things for which it isn't, and some for which it's probably a terrible choice.
Just as some people are zealous in their criticism and avoidance of XML, some people are just as zealous (or more so) in their praise and use of it. In the cases you refer to casually above, you're talking about web-based technologies for the most part. In these cases, you generally already have an XML parser and/or DOM manipulator already available to you, so there is no harm in making use of it. You haven't added to the complexity, because it was already there. Flash & AIR make heavy use of XML for functionality, but they are targeted to an environment where parsing XML-ish markup (if not XML itself, then HTML or XHTML) is a core part of every application. For these technologies, introducing a different sort of data-expression language would be what adds complexity. Using XML makes perfect sense.
Here's an example... the language in question here is Perl because that's what I use primarily, but the Perl-aspect of it is not relevant to the point: I've been working on an extension of an existing module that dumps deep data structures. Useful for tons of things-- serialization, portability across platforms, etc. Also a popular tool for debugging. My reason for wanting to extend it is that truly large and complex structures (such as those produced by ORM or MOP frameworks) can get pretty hairy. So my first thought was to just make an extension that let me convert the data to HTML in a way I could exercise some control over. Then I thought that it would be nifty if I could create diagrams showing the various elements and which is linked to which, etc. Then it occurred to me that if I chose a reasonable neutral format, I should be able to derive both of those fairly easily.
That format? XML. Why would it be necessarily better than the native Perl serialization structure in this case, or better than using a different interim representation (such as YAML or JSON)? Because if I have valid, well-formed XML I can easily use XSLT to turn that into (X)HTML or SVG. I can also turn it into plain text if I want (I have XSLT stylesheets already, that choose to emit HTML fragments or cleanly-word-wrapped plain text depending on user selection).
There are plenty of ways to solve this particular problem, but the advantage that XML gives me in this case makes it the preferred choice (at least, for my preferences and my needs). XSLT is a well-defined, well-documented (OK, your opinion may vary on that with regards to the W3C documentation, but there is no shortage of books on the subject) tool for transforming XML into, well, pretty much anything. For this particular problem, the expressiveness of XML combined with the fact that my ultimate target formats (XHTML and SVG) are themselves XML, made it the clear choice. On the other hand, there have been plenty of times when I've recommended (as a consultant) to a client or (as a company employee/team member) to a boss/team that XML should not be used for some task. Sometimes the reason is clear-- using XML wouldn't improve the (re-)usability of the data, they weren't using XML on the project yet and this wasn't the sort of thing you should introduce that dependency for, etc. Sometimes the reason is more subtle; if you are trying to decide how to store/retrieve your application's configuration, does it really need to be in XML? It's highly unlikely any other application will need to read/parse this, so portability/reuse of data isn't an issue. If the data is fairly flat in nature you can probably manage with a file of key/value pairs. If the data is more complicated and/or complex, you might be fine with YAML.
In general, XML is the worst choice for data expression, except when it's the best choice. The same can be said for JSON and YAML, and the best way to get the most out of any of these approaches is to be familiar and comfortable with all of them and know which one is the best tool for the job you have in front of you.
我认为问题中的神奇词是“声明性”。
具有任何灵活性的声明性技术都需要声明格式。 它必须有一种方法来验证声明在语法上是否正确。 它需要能够将底层数据结构序列化和反序列化为这种格式。 如果格式足够开放，可以直接构建生成、修改或处理声明的工具，那么这是非常有益的。
你可以看到这是怎么回事。
我认为您所看到的问题是真实存在的，但我不认为它们真的是 XML 问题。 嗯，不直接。 我认为真正的问题在于你所说的另一件事：这些声明性技术的设计工具不够强大。
这就是为什么它是一个 XML 问题：使用 JSON 作为产品序列化格式的开发人员不会允许自己思考“嘿，我不需要实现此功能，用户只需编辑 JSON 即可。 ”
我认为这就是问题所在。 这并不是说 XML 是一种不好的表示声明的格式。 正是XML的开放性非常诱人。 它为工具开发人员提供了一种将功能从工具中剔除的方法。
我认为这是一个社会问题，而不是技术问题。 这是一个棘手的问题。 如果 Microsoft 提出一种封闭格式而不是 XAML，我们可能会拥有更好的 WPF 工具。 但我们从开放格式中得到了太多，不能放弃它们。
I think the magic word in the question is "declarative."
A declarative technology with any flexibility requires a format for declarations. It has to have a way of validating that the declarations are syntactically correct. It needs to be able to serialize and deserialize the underlying data structures into and out of this format. It's very beneficial if the format is sufficiently open that it's straightforward to build tools that generate, modify, or process the declarations.
You can see where this is going.
I think the problems you're seeing are real, but I don't think they're really XML problems. Well, not directly. I think the real problem lies with the other thing you said: the design tools for these declarative technologies aren't powerful enough.
And here's why it is, kind of, an XML problem: no developer who was using JSON as his product's serialization format would allow himself to think "hey, I don't need to implement this feature, the user can just edit the JSON."
I think that's the problem right there. It's not that XML's a bad format for representing declarations. It's that XML's openness is very seductive. It gives tool developers a way to skate by on leaving functionality out of their tools.
I think that's a social problem, not a technical problem. And it's a tough problem. We'd probably have much better WPF tools if instead of XAML Microsoft had come up with a closed format. But we get too much from open formats to give them up.