根据我在 Oslo 看到的情况，声明性 XML 将发挥关键作用。我可以指望围绕大量设计人员生成的 XML 来创建真实世界的应用程序吗？只知道我没有研究过这个。如果您检查了该主题，我会欣赏您的观点。
一些背景...
每当我深入研究任何支持 XML 的声明性技术（例如 Silverlight 和 WPF、ASP.NET 或 MSBuild）时，我似乎最终都会编辑大量原始 XML 文本。设计师很少有足够的表达能力来满足我的需求。
一方面，我真的无法在人类和机器可读性之间找到更好的折衷方案，而且公平地说，XML 编辑体验会随着每个化身而变得更好。
另一方面，我还没有发现 XML 对它的某些用途来说是理想的。尤其是在表达逻辑、重构和可测试性方面。可能是设计者太软弱，或者 XML 表现力太强，或者我脾气暴躁，被对象和方法宠坏了。
我倾向于成为一个有点可疑的 XML 拥护者。尽管我每天都在使用它，并且基于 XML 的 Web 服务已成为我职业生涯的重要组成部分（也是我写这本书的基础），但我认为它被广泛过度使用。我倾向于相信你的工具箱里应该有很多工具，你应该使用最好的工具来完成工作。对于很多事情来说，XML 是一个很好的解决方案。但是有很多事情不是这样，有些事情可能是一个糟糕的选择。
就像有些人热衷于批评和回避 XML 一样，有些人同样热衷于（或更多地）赞美和使用它。在您上面随便提到的情况下，您所谈论的大部分是基于 Web 的技术。在这些情况下，您通常已经有一个 XML 解析器和/或 DOM 操作器可供您使用，因此使用它并没有什么坏处。你没有增加复杂性，因为它已经存在了。Flash 和 AIR 大量使用 XML 来实现功能，但它们的目标是解析 XML-ish 标记（如果不是 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 也是如此，充分利用这些方法的最佳方法是熟悉并熟悉所有这些方法，并知道哪一种是最适合您面前工作的工具你。
我认为问题中的神奇词是“声明性的”。
具有任何灵活性的声明性技术都需要声明格式。它必须有一种方法来验证声明在语法上是否正确。它需要能够序列化和反序列化底层数据结构进出这种格式。如果格式足够开放，可以直接构建生成、修改或处理声明的工具，这将非常有益。
你可以看到这是怎么回事。
我认为您看到的问题是真实的，但我认为它们并不是真正的 XML 问题。好吧，不是直接的。我认为真正的问题在于你所说的另一件事：这些声明性技术的设计工具不够强大。
这就是为什么它是一个 XML 问题的原因：使用 JSON 作为其产品的序列化格式的开发人员不会允许自己认为“嘿，我不需要实现这个功能，用户只需编辑 JSON。 "
我认为这就是问题所在。并不是说 XML 是一种不好的表示声明的格式。就是XML的开放性很诱人。它为工具开发人员提供了一种通过将功能排除在工具之外的方式来滑行。
我认为这是一个社会问题，而不是技术问题。这是一个棘手的问题。如果微软提出了一种封闭格式而不是 XAML，我们可能会拥有更好的 WPF 工具。但是我们从开放格式中得到了太多，无法放弃它们。