什么时候不应该使用 XML(1)

80酷酷网    80kuku.com

  xml

 

当今计算世界趋向于任何所有正式规范和数据描述都使用 XML。本文作者 XML 的忠实拥护者 提出了一个亵渎神明的问题:“XML 极权主义是个好主意吗?在这篇观点性文章中,Terence ParrjGuru 的共同创始人,演示了 XML 形成的糟糕的人机界面。他还提出了一些问题,这些问题是让您自己决定 XML 是否甚至适合于项目的程序对程序接口所需。
记得剪贴前生活的样子吗?(正如我的朋友 Gary Funck 所说,如果您不是老到记不得的话……那么对您来说很好)。每个程序以不同方式存储数据,并且很少希望将大量数据送到另一个应用程序,当然肯定不会送到另一个正在运行的程序。在现代操作系统中,粘贴缓冲区以标准方式保持数据,而每个程序觉得合适,就可自由地解释缓冲区数据。例如,可以从数据库程序中剪切一段数据并有意义地粘贴到图形程序中。

类似的,在因特网上的程序之间和机器之间,有一种称之为 XML 的共享数据的标准方式。如果没有 XML 或类似标准,那么两个程序就不可能共享信息 出于数据可移植性,用来格式化数据的基本语法必须相同。当然,您可能无法解释这些数据,但至少能将它们读入。看一下如 SOAP XBean 这样的技术,了解 XML 是如何促进互操作性的(请参阅参考资料)。

既然就这个问题我们已经达成了共识,即,XML 是,还是应该是,程序数据互换的公共语言,那么我想反过来讨论一下:什么时候使用 XML 没有意义?首先,需要提醒您的是,XML 看起来象什么以及它与其它数据格式有何不同。如果在这种背景条件下,那么当确定项目数据格式时,我提出一系列可以证明是有用的问题。最后,我将演示我的主要建议:XML 形成了糟糕的人机界面。

您说“date-uh”,我说dat-uh”
XML
是一种突出数据结构的手段,对于计算机程序,可使它检查该数据更容易。当然,它不是第一种数据格式。古老的逗号分割值(CSV)格式一直使用了几十年来描述成行的数据。例如,这里有可能描述三个日期记录的三行整数:


8, 17, 1964
12, 30, 1975
9, 1, 1970



CSV
在可读性和实现简单性方面很难被击败(想必您必须在第一节计算机课编写程序来读取 CSV 数据)。问题是 CSV 实行严格的数据次序,并且 CSV 不能方便地描述嵌套结构和不同类型的元素。添加花括号以表示嵌套、聚合数据(如 C VRML 中)的做法改善了可表达性,同时使数据具有可读性。例如,要将每行数据与一个标识符相关联,您可能编写:


{{8, 17, 1964}, instructor}
{{12, 30, 1975}, student}
{{9, 1, 1970}, student}



这种格式仍然相当易于进行语法分析,但它继续实行严格的数据次序。解决次序局限性的方法是标记所有数据,譬如:


{date={m=8, d=17, y=1964}, title=instructor}
{date={d=30, m=12, y=1975}, title=student}
{title=student, date={m=9, d=1, y=1970}}



虽然现在数据是位置无关的(您可以看见我已经将一些元素弄混了),但冗余的标签增加了存储成本并使得更难对它进行语法分析。

当前,我们大多数会按如下以 XML 形式编码数据:


<record>
   <date><m>8</m> <d>17</d> <y>1964</y></date> <title>instructor</title>
</record>
<record>
   <date><d>30</d> <m>12</m>, <y>1975</y></date> <title>student</title>
</record>
<record>
   <title>student</title> <date><m>9</m> <d>1</d> <y>1970</y></date>
</record>



我的观点是有无数的描述格式(语言),带有不同程度的可读性、实现的方便、效率、普遍性和表示方式等等。虽然如此, 我们还是要迅速地集中于完全的 XML 格式的支配。

XML
复杂性和程序间通信
Web
的蓬勃发展和对 HTML 的普遍熟悉把我们领向 XML,它实际只是另一种结构化数据格式。遗憾的是,我们对数据标记得越多,对计算机时间和空间效率的影响就越大。另一方面,数据是任何带 XML 语法分析器的程序都可以读取的标准形式。针对不同情况,需要在简单性和标准化之间解决折衷。当拿不定主意时,也许应该使用 XML。另一个显而易见的规则是,如果您的数据是高度结构化的,那么用 XML。例如,当将 jGuru FAQ 内容(请参阅参考资料 )导出到我们的伙伴时,提供 XML 数据文件。相反,如果数据不是那么复杂,XML 也许不是最好的选择。通过提一些简单的问题,通常可以为您的程序在 XML 和另一种数据格式之间做出决定。对于本节中四个问题里的任何一个,如果您回答,您可以考虑用更简单的格式来替换标准的 XML 数据。

XML
语法分析器所占比重远远超过了程序的其余部分?
如果编程任务和相关数据相当简单,那么为什么用庞大的 XML 语法分析器以及从结果树中拽出数据所必须的粘接代码,来增添您自己负担呢?请记住,您的目的是完成任务,而不是自己摆弄 DOM 树。程序中组件越多,越容易出现故障。现在,另一方面,如果程序中已经有 XML 语法分析器,那不妨使用它以便在程序中保持一致。

同样回想一下,大多数编程语言对于非 XML 数据格式有小的、内置的语法分析器。例如,Java 有标准方式来读入属性文件,还有易于从简单数据字符串抽出数据的 StreamTokenizer 类。

程序运行在小机器上还是在庞大的数据集上?
如果数据不是高度结构化/嵌套的,并且相对于您的机器是非常巨大的,那么应避免使用 XML,因为您可能需要额外的磁盘和内存存储器。回想 1993 年,我在超级计算中心工作,物理学者经常存储万亿字节的文件(每个文件有 10000 亿字节!)。把 XML 标记添加到数据将使那些文件变得实在太大。我敢说,将整个树放入内存,甚至对于当今的并行超级计算机,也是一项挑战。对 XML 标记进行语法分析的额外处理时间也会达到不可允许的程度。可以肯定,您很少需要模拟高能激光器合成流体动力学,但是甚至如日志这样的普通文件可能也会变得很大。

XML
数据格式阻碍您使用许多如 grepsedawk wc 这些基于行的工具了吗?
如果您使用 ls 而非 dir,那么您可能熟悉 Unix 基于行的工具,如 grep wc。我可以确切地说,没有 grep,那么我就是个废人,没有 sedawk wc,那么我感到十分无助(相信我,那会很糟糕)。按每行一条记录的方式将信息存储成与位置相关的数据,这比标记的 XML 数据有极大的优势,因为可以从命令行或用简单的脚本来对数据执行惊人的转换和操作。我不需要只是为了检查数据而去搭建一个开发环境并编写一个使用 XML 语法分析器。

考虑 jGuru 网站,它生成了许多日志和事务记录。我决定不带标记信息每行写出一条记录 行上项的位置决定了它是什么。例如,用这种形式将站点登录事件写入文件:

timestamp: user-id
因为格式是如此简单,我可以用所有 Unix 工具对数据进行操作。如果我想知道在今天用户 1290 已经登录了多少次,可以用如下命令:


$ grep 1290 login.log | wc -l



该命令过滤日志文件以查找任何包含 1290 的行,然后计算结果有多少行数。如果我想要今天所有用户登录的柱状图,可以调用以下命令:


$ awk '{print $2;}' login.log | sort | uniq -c | sort -r -n



不是每个人都这么熟悉 Unix 数据工具,但想说明的是,选择简单的数据格式让我不必借助程序就能够摆弄这些数据。

如果以如下方式使用 XML 记录存储了这些数据:


<login><timestamp>2001-04-06</timestamp><id>1290</id></login>



那么,不编写程序就很难摆弄那些数据。

您的程序是一次性的,一个真正唯一的应用程序吗?
您永远不能预测未来程序或数据会发生什么(只要询问一下来自 60 年代的 COBOL 程序员),但偶尔必须编写执行永远不会再出现的任务的程序。例如,如果在升级软件时,正在进一步处理数据库的模式,而该模式转换器可能不会再被用到,这是很正常的(虽然以后可能会借用一些代码)。当将信息从数据库转储以将它重构成新的模式时,您应该为执行速度和易于实现而优化,而不是为与 XML 保持一致。

语法不是语义
最后,就程序间通信而言,我想提醒您,语法不等于语义。数据的语义(含义)完全取决于应用程序。语法分析器只处理语法(格式)。考虑到所有人类语言都用完全相同的数据格式 字符串(句子)或声音流(讲话)。但是,如果您曾在巴黎以不说法语者来问路,会知道沟通远比要求同意通过口头表达来交流要困难得多(对于旅行者有用的提示:谈话时多用手比划;这好象有帮助)。

 



分享到
  • 微信分享
  • 新浪微博
  • QQ好友
  • QQ空间
点击: