第一步：正确使用不同的XML成分

　　最突出的显著问题之一是 XML 作者(从宽泛的意义上讲)将各种各样的内容都填塞到元素中。属性、处理指令 — 变成了过去时。

　　元素

　　元素在 XML 中最容易使用，很大程度上是因为 XML 作者倾向于完全 依靠元素。当然，这是错误 的，而且有很严重的副作用。XML 中的元素最适合表示具有某种层次结构或者可能 具有某种层次结构的数据(当然也有例外，不过这里讨论的是最佳用法)。首先举一个反例，人名(不含姓和中间名等)永远不可能有层次结构，它就是一个单词，如此而已。但是如果选择使用 name 元素，可能 也不错：至少能分解成名和姓，可能还有中间名、头衔和其他成分。因此下面这样使用元素实际上是不正确的：

　　< firstName>Bob< /firstName>

　　应该用：

　　< name firstName=”Bob” lastName=”Zemeckis” title=”Mr.” />

　　如果还不明白为何不在 name 元素中嵌套 firstName、lastName 以及 title 元素，请仔细阅读 上一段。下一节介绍 属性 时还将进一步讨论。

　　一般而言，如果一个元素不可能在文档的同一个地方出现多次(比如可能有家庭和办公两个不同类型的 address 元素，图书可能存在两个 author 元素)，则应尽量使用属性。并不是说每次使用元素时都必须 出现两次，仅仅是可以 出现两次。

　　元素最适合文本数据这种说法也不正确，很多例子中元素只有属性而没有文本内容(建议阅读讨论属性的 下一节)。最重要的是要记住 XML 不仅仅 有元素，还有其他结构。

　　属性

　　尽管看起来像是废话，但无论如何只能对单值数据使用 XML 属性。比方说，如果使用关于人的元素，那些关于这个人的单值信息就是潜在的属性。社会保障号码、ID，可能还有出生日期 — 都是合适的候选属性。

　　当然和其他规则相比，属性规则有更多的例外。实际上，我认为属性的应用和应该达到的程度相比少得多。开发人员往往喜欢元素比较清晰的外观：

　　< person>
　　< ssn>489098723< /ssn>

　　< /person>
 
　　但是这样做毫无意义 — 社会保障号码绝对是单值数据。更糟的是，这样把数字当成元素会影响性能。像这种情况下访问元素的子元素时，必须首先取得元素节点然后遍历所有的子元素节点。社会保障号码可能是第一个节点，但也可能是最后一个节点，不能确定。得到那个 节点的子元素后再访问其值，该例中包括一个文本节点。中间要经过多个步骤：

　　获得父节点(person 元素)。

　　访问父节点的子节点。

　　迭代寻找需要的子节点(ssn 元素)。

　　可能需要规范化这个新元素的文本节点以简化后续操作。

　　得到元素的子节点。

　　取得文本子节点的值。

　　使用属性的话就简单多了：

　　访问父节点(person 元素)。

　　访问属性。

　　迭代寻找需要的属性(ssn)。

　　取得属性值。

　　这种方法避免了规范化(属性只能有单一的文本值)，也不需要处理子元素。我发现访问元素的属性几乎总比访问特定的子元素快。因此性能上的优势很明显，特别是对于成千上万次迭代的情况。

　　我的观点是，尽管看起来不太好看，XML 应这样使用：

　　 < person ssn=”489098723″ firstName=”Bobby” lastName=”McKenza”>
　　< occupation>

　　< occupation-type status=”part-time” job=”author” />

　　< occupation-type status=”part-time” job=”programmer” />

　　< /occupation>

　　< address type=”home” street=”112 E. Harney Way” city=”New York” state=”NY” zip=”10012″ />

　　< !– etc… –>

　　< /person>
 
　　对大多数人来说可能有点奇怪，因为基本上所有信息都用属性表示。但是我相信这种方法更好，访问 10,000 或更多次时能够可观地提高效率(访问次数多可以将细微的性能改进叠加起来)。

　　处理指令

　　通常不使用处理指令或者 PI。但是，令人苦恼的是现在很多 XML 处理 API 要求把特殊代码或指令放在注释中、或者使用特殊的名称空间以及各种专用元素，甚至使用包含指令的元素。如果 XML 需要为处理 API 或者工具提供信息，这些信息就是处理指令，XML 有专门的机制。

　　以前肯定遇到过，特别是在 XSL 中：

　　< ?xml version=”1.0″?>
　　< ?xml-stylesheet href=”classic.xsl” type=”text/html”?>

　　< ?xml-stylesheet href=”alternate.xsl” type=”text/xml” alternate=”yes”?>

　　< article>

　　< !– etc … –>

　　< /article>
 
　　这里 PI 告诉 XSLT 处理程序应用于 XML 文档的样式表在哪里。不用考虑那些忽略该机制的 API(尽管首先想到的就是 JAXB)，应该充分利用该机制，无论如何要比下面这种方法强：

　　< ?xml version=”1.0″?>
　　< !– xml-stylesheet url=”classic.xsl” document-type=”text/html” –>

　　< !– xml-stylesheet url=”alternate.xsl” document-type=”text/xml” –>

　　< article>

　　< !– etc … –>

　　< /article>
 
　　我经常看到这样的代码。注释是没有意义的，使用注释并将其中的信息作为指令处理的 API 是危险的。Javadoc 和文档生成 API 使用注释，但至少作为文档而不是具有实际意义的指令使用。显然，如果选择的 API 要求这种标记，您可能继续使用，但应该认识到这并非按照 XML 本来的方式使用 XML。我相信 XML 规范的作者在这个问题上说得很明确了。

　　结束语

　　也许我早应该讨论这些问题，但我并不是 XML 纯粹论者。事实上我认为 XML 的很多东西愚蠢无聊、本末倒置或者是完全错误的。但是我的确 认为，既然选择使用 XML，一些基本的概念对于正确使用是必须的，否则何必选择 XML 呢?如果多值数据或者长数据不用元素，如果根本不使用属性，如果滥用或者不用处理指令，某个时候就会发现最好离开 XML 去编写自己的私有语言或解析器来处理您的数据。否则就得忍受 XML 的枷锁 — 冗长、奇形怪状的文档、编码问题等等 — 而没有任何好处 — 专用的高速解析器。

　　因此不要为了正确地使用 XML 或者取悦语义主宰者而考虑这些建议。对于您的编程生涯来说这些都不是恰当的理由。如果将其看作更有效地利用 XML、提高软件性能的办法，就是合情合理的了。继续前进吧，打破那些规则 —— 但必须有充分的理由!