技巧：子元素内容对标记属性－－XML格式中的设计问题

技巧：子元素内容对标记属性 

－－XML 格式中的设计问题

David Mertz 博士（mertz@gnosis.cx）

演讲者，Gnosis Software, Inc.

2001 年 11 月

在本文中，developerWorks 专栏作家 David Mertz 就何时使用标记属性以及何时使用子元素内容来表示数据提出了一些建议。可以了解到设计 DTD、Schema 或（尤其是）XML 格式所要考虑的事项。您还可以了解到何时属性和内容是可互换的，何时不能。代码样本显示了这些选项。
关于 XML 的一件不同寻常的事情是，对于表示“这是数据”，它提供了几乎相同但又不完全相同的两种方式。一种表示数据值的方式是，将数据值放入子元素中；另一种方式是将数据值放入属性值中。通常，由于不能明确回答何时这两种方式要合适些，所以 XML 不是完全正交的（计算机科学中对这个词的理解是，“每个构造做一件事情，但没有其它构造做同一件事情”）。对于何时使用子元素以及何时使用属性，本文提供了一些指导性建议。

在交给您要遵守的 XML 方言规范的时候 — 即以 DTD 或者 W3C XML Schema，或者按非正式或按示例所描述的的方式给予您时，您就无须确定使用哪种数据去向哪儿。如果不需要做出选择，则不要理会本文中的建议。但是，开发人员通常需要为过程 设计要使用的、确切的 XML 方言。如果您处于这种情形，则继续读下去。

要记住的一件事情是，那些仅需要良好格式的 XML 文档和那些要求对于某些 DTD/Schema 有效的文档之间的区别。有效性是非常严格的；它允许您坚持以某种方式来表示和结构化某些数据。出于非常一致的原因，确保给定文档生产过程符合有效性需求需要更多的工作。这两种方法都有一些优点；强行使用 DTD 给元素／属性问题添加了复杂性，但在这两种情况中，需要做一些权衡。下面就讨论这些权衡。

数据次序重要吗？

如果希望用 DTD，则子元素是严格有序的，而属性是无序的。在仅强调格式良好的 XML 文档中，您可以随意摆弄次序；归根到底，在这种情况下，可以将任何标记以任何深度放入 任何其它标记中。在这两种情形中，通常属性适合于无序的数据。然而，对于带有 DTD 的 XML 文档，这种无序类型的数据几乎都需要使用属性。

例如，您可能有一个联系人的列表，其中，每个人都必须有姓名、年龄和电话号码。但是，将年龄放在电话号码 前并没有什么逻辑含义。因此，这些属性是无序的。在这种情况中，属性更具有直观性。比较清单 1 和清单 2 中简短的 XML 文档：

清单 1. 联系人的属性数据 <?xml version="1.0" ?>

<!DOCTYPE contacts SYSTEM "attrs.dtd" >
<contacts>
  <contact
     name="Jane Doe"
     age="74"
     telephone="555-3412" />
  <contact name="Chieu Win" telephone="555-8888" age="44" />
</contacts>

 清单 2. 联系人的子元素数据

 <?xml version="1.0" ?>

<!DOCTYPE contacts SYSTEM "subelem.dtd" >
<contacts>
  <contact>
    <name>Jane Doe</name>
    <age>74</age>
    <telephone>555-3412</telephone>
  </contact>
  <contact>
    <name>Chieu Win</name>
    <telephone>555-8888</telephone>
    <age>44</age>
  </contact>
</contacts>

想象一下由每个 XML 格式所暗示的 DTD。对于清单 1 中面向属性的格式，DTD 可能如清单 3 所示。

清单 3. 联系人文档的属性

DTD <!ELEMENT contacts (contact*)>
<!ELEMENT contact EMPTY>
<!ATTLIST contact name      CDATA #REQUIRED
                  age       CDATA #REQUIRED
                  telephone CDATA #REQUIRED >

做同样事情的面向子元素的 DTD 可能如清单 4 所示。

清单 4. 表示联系人文档的子元素

DTD <!ELEMENT contacts  (contact*)>
<!ELEMENT contact   (name,age,telephone)>
<!ELEMENT name      (#PCDATA)>
<!ELEMENT age       (#PCDATA)>
<!ELEMENT telephone (#PCDATA)>

清单 4 中，DTD 的明显问题是，清单 2 中的这个简单示例在该 DTD 下是无效的（即使它有我们希望的数据）。这些子元素次序是混乱的。副栏显示了如何可以使用带 DTD 的无序子元素。但除非另有一个令人信服的原因，否则，对于无序数据，最好使用属性风格。

多个数据出现在同一层上吗？

如果在一个对象中多次出现相同类型的数据，则子元素将是更好地选择。例如，在联系人列表案例中， contacts 对象包含许多 contact 对象。在这种情况下，很明显，应该在 contacts 元素的子元素中描述每个联系人。

然而，在实际情况中，开发人员常常会在制定修正期间逐渐偏离这一设计原则。这里，看一下它是如何发生的：首先，发现有一个 flizbam 附加在每个 Flazbar 后面（并且由数据来描述 flizbam）。好极了，这似乎是一个明显的选择，省去额外冗长的子元素，并为 Flazbar 标记创建 flizbam 属性。这样做不久 — 在为处理 Flazbar 编写好漂亮的生产代码后 — 发现在某些情况下 Flazbar 可以有两个 flizbam。这不是问题：对已安装的代码稍加改动，只需要更改 DTD，使其包含：

<!ATTLIST Flazbar flizbam   CDATA #REQUIRED
                  flizbam2  CDATA #IMPLIED>

有了这个修改后的代码，原来的 XML 文档仍然有效，而新代码也可以起作用。过一会儿，会发现第三个 flizbam……

很难避免被引入这个设计陷阱。数据和对象会随着时间而发展，单个事物会常常成为两个或多个事物。一些 XML 程序员由于这个原因而完全避开了属性，但我认为太过分了。我的建议是，在设计阶段，就单个数据是否在以后需要多个兄弟数据，要仔细考虑。如果未来有多个兄弟数据的合理的可能性，则从一开始就使用子元素。如果有理由确信数据对象将保持唯一，则坚持使用属性。

 需要保留空白吗？

在属性规范化后，可以依靠的属性中的每个记号是通过空白来与其邻居区分开来。但是那是您可依靠的 全部。对于开发人员，为了可读性，可以向长属性值添加垂直和水平空白，这不会有任何问题（事实上， 应该这样做）。但是，一旦那些可读的属性经过 XML 解析器，属性的布局可能与源 XML 稍微有些不同。

如果空白是重要的，则子元素是较佳的选择。例如，如果表示象源代码或诗歌这样空格确实很重要的内容，则坚持使用元素内容。

可读性重要吗？

理想情况下，XML 应该是计算机阅读的格式，而不是人类阅读的格式。但是，不管幸运不幸运，程序员也属于人类；并且对于可预见的未来，我们将花大量时间阅读、编写以及调试 XML 文件。阅读格式化成仅用于机器阅读的 XML 肯定是痛苦的（无空白或无意义的空白）。

从个人角度来讲，我发现阅读和编写面向属性的 XML 格式要比面向子元素的容易得多。再看一下上面的清单 1 和清单 2 来体会我所指的含义，没有一个是难以阅读的。但清单 1 的属性版本要更容易阅读些 — 而且也更易于编写，因为不必担心多变的子元素次序。

结束语

我已经指出了何处子元素或属性更适当的一些情况。记住了谈到的这些原则，就可以导致更清晰和更整洁的 XML 文档格式。遗憾的是，有时现实情况会涉及多种情形（指向相反的方向）。而且在许多时候，数据设计可足以导致以前动机失效。在可能的情况下，使用本文所给出的一些规则，但首先“使用（有见识的）共识”。

参考资料

请参加关于本文的论坛。

在 Extensible Markup Language (XML) 1.0“W3C 建议书”中有您了解有关 XML 确实需要的任何内容。当然，精确地理解这些含义需要一定的智慧。

XML Cover Pages 有一些关于 Using elements and attributes 的提示。那个页面还包含到一些文章的链接，每篇文章就在确定使用属性还是使用元素时，给出了使用何种标准的矛盾建议。那是我们程序员赚得大把钞票的原因！

查看属性和元素之间差别的一种方式是阅读 "Document-Centric" vs. "Data-Centric" 文档。

查阅在 developerWorks XML 专区上发布的其它 XML 提示。

关于作者 David Mertz 用完全非结构化的大脑写出关于结构化文档格式的文章。可以通过 mertz@gnosis.cx 与他联系；在http://gnosis.cx/publish/ 上有他日常所钻研的成果。