我注定要用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问题:没有使用JSON作为产品的序列化格式的开发人员会允许自己思考“嘿,我不需要实现这个特性,用户可以编辑JSON。”

我想 那是 问题就在这里。XML并不是表示声明的错误格式。XML的开放性非常诱人。它为工具开发人员提供了一种在工具之外保留功能的方法。

我认为这是一个社会问题,不是技术问题。这是个棘手的问题。如果微软提出了一种封闭格式,而不是xaml,我们可能会有更好的wpf工具。但我们从开放格式中得到的东西太多了,不能放弃它们。