Thinking XML: 创建 XML 的好建议(3)_Xml教程

推荐：使用PHP和AJAX的XML编程(2)
　　基于 ACORD 人寿数据模型的场景 　　我们来考虑一个简单的人寿保险场景，在这个场景中，首先创建一个表示新保单的 XML 文档，然后查询和操纵这个文档，另外还将这个文档从一层移动到另

Henri 关于 Unicode 和字符处理的建议基本上是完全正确的。不过我认为“Avoid adding pretty-printing white space in character data”一节有点夸大其词。多数情况下，元素之间而不是带有字符数据的元素内部的精细打印是安全的。如 Henri 所述，清单 1 所示的如果以清单 2 的形式呈现通常是不安全的。

清单 1. XML 例子

<foo>bar</foo>

清单 2. 在字符数据中增加空白后的 XML 例子

<foo> 　bar </foo>

但通常以清单 3 的形式打印 XML 是安全的，输出结果如清单 4 所示。

清单 3. 另一个 XML 例子

<doc><foo>bar</foo></doc>

清单 4. 清单 3 中的 XML 在字符数据中增加了空格

<doc> 　<foo>bar</foo> </doc>

很多 XML 序列化工具能够理解相对安全和不安全的的打印格式。必须知道的是，如果在混合内容中增加空格，则清单 3 和 4 中所示的精细打印形式可能造成扭曲。如果使用模式制导的序列化，则可以避免这类问题。但在实践中，使用混合内容的多数词汇表对空白规范化没有这么敏感，因此不用过于担心精细打印。应该充分了解该问题，并知道没有办法关闭精细打印（最好默认不用精细打印）。Henri 提出了清单 5 所示的精细打印实践，但是我不同意，因为我认为那些难看的标记不容易理解。

清单 5. Henri Sivonen 建议但本文作者不同意的精细打印方式

<foo >bar</foo >

修道院的建议

现在换换档，本文要探讨的第二篇资料是 Simon St. Laurent 撰写的“Monastic XML”（请参阅参考资料）。这是一组小短文，围绕着如何充分利用 XML 而就处理和思考 XML 提出了一些建议。Simon 使用修道院和禁欲主义作为比喻，提出为 XML 增加不适应其简单文本根 (textual root) 的过多负担是危险的。 在“Marking-up at the foundation”中,他讨论了字符数据和标记（元素和属性）的本质作用。在“Naming things and reading names”中，他解释了为何一般标识符（也称为元素类型名）是一个重要的概念，应该作为标记信息结构的惟一关键成分。理想情况下，如果使用 XML 名称空间，关键就是统一名称（名称空间 URI 加上本地名），这种复杂化就是 Simon 在“Namespaces as opportunity”中厉声疾呼的原因之一。“Accepting the discipline of trees”揭示了 XML 一个不幸的秘密：尽管看起来 XML 的层次结构很容易扩展成图形结构，但实践证明用 XML 建模图有点困难。但目前为止，“Monastic XML”网站上最重要的建议是“优化标记的处理总是不成熟”。XML 是一种声明性技术，对很多开发人员来说，关于它的强大和不足有很多不实之词。那些尽量把 XML 设计和处理细节拉近的开发人员，从长期来看，通常使得处理更加困难。XML 成功的关键是关注需要抽象表示的信息的特点，将它与需要处理这些信息的系统的技术设计分离开来。

结束语

讨论 XML 最佳实践时总是有一些不同的观点，特别是在初期阶段，但听到不同的声音是一件好事。关于这个话题的参考资料很少，我将继续在本专栏中讨论它。如果对最佳实践有什么资料或者建议或者希望分享您的观点，请参加 Thinking XML 论坛上的讨论。

分享：论Asp与XML的关系
1、XML 是什么？ XML仅仅是一种数据存放格式，这种格式是一种文本（虽然XML规范中也提供了存放二进制数据的解决方案）。 事实上有很多文本格式都可以用来存放数据，例如大家所熟悉的.ini文