根据我在oslo上看到的情况，声明性xml将起到关键作用。我是否可以期望大量设计师生成的xml来创建真实的应用程序？只是知道我还没研究过。如果你仔细研究了这个问题，我会告诉你的看法。
一些背景…
每当我深入研究任何XML支持的声明性技术（如Silverlight和WPF、ASP.NET或msbuild）时，我似乎最终编辑了大量原始XML文本。设计师很少有足够的表现力来满足我的需要。
一方面，我真的看不出人和机器可读性之间有更好的折衷，而且公平地说，XML编辑的体验随着每一个化身而变得更好。
另一方面，我还没有发现XML对于它的某些用途是理想的。尤其是在表达逻辑、重构和可测试性方面。可能是设计者太弱，或者XML太富表现力，或者是我太暴躁，被对象和方法宠坏了。
最佳答案
我倾向于成为一个有点可疑的XML拥护者。尽管我每天都使用它，而且基于xml的web服务已经成为我职业生涯的一大部分（也是我写这本书的基础），但我认为它被广泛地过度使用。我倾向于属于那种认为你的工具箱里应该有很多工具的思想流派，你应该使用最好的工具来完成工作。有很多事情XML是一个很好的解决方案。但有很多事情不是这样的，有些事情可能是个糟糕的选择。
正如有些人热衷于批评和避免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吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/219572/