最突出的显著问题之一是 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 元素)。