如果 清单 6 看起来眼熟，这是因为 Atom Entry 元素没有提供发送的数据所需的所有字段，所以这个条目的大部分是来自上面示例的 XHTML 代码，这些代码包围在 <content/> 标记中。我可以改变 published 和 author 字段的用途，但是这意义不大，而且这实际上是对 published 字段的错误使用，这个字段应该是这个条目的发布日期，而不是它包含的数据的日期。我可以创建自己的名称空间，从而用额外的字段扩展 Atom Entry，但是现有的聚合器或 feed 阅读器都不能使用此信息，因此使它不可见，所以是没有意义的。可以简单地将 XHTML 代码包装在 Atom envelope 中，从而给应用程序添加联合支持，但是从纯粹的面向数据角度来看，Atom 没有给我提供任何好处。当需要将数据传入和传出我的应用程序时，用 Atom Entry 包装数据并使用 Atom Publishing Protocol（参见 参考资料）可能是有好处的。注意，如果要使用 Atom，那么这对数据格式选择会有一些限制：Atom <content/> 标记只能容纳三种类型的数据：文本（可以是 JSON 格式）、HTML（其中的所有实体都要经过转义）或 XHTML。还没有在不需要扩展 Atom 的情况下在 Atom 中嵌入任意 XML 内容的方法，但是可以为不能嵌入的数据提供链接。所以，如果希望为自己的数据提供联合流，那么一定要考虑清楚，因为如果决定集成 Atom 功能，就会影响其他的数据格式决策。

回页首

结束语

在构建支持 Ajax 的 Web 站点或 Web 应用程序时，要做出许多决策。要采用什么数据格式就是决策之一，开发人员常常忽视这个问题，或者没有认真地全面考虑所有方面。在本文中，我尝试为这些问题提供一些思路，帮助您做出合理的决策。重申一下前面给出的经验性规则：

• 对于数据，使用 JSON
• 对于文档，使用 XML（如果没有明确的否定理由，就选用 XHTML）
• 为了联合（以及支持 Atom Publishing Protocol），将数据包装在 Atom 中

我尝试用一些示例来说明涉及到的权衡因素，并试图通过这些示例来论证我的经验性规则。但是，我没有证明任何规则，因为这些示例都是特殊情况，而且大多数现实场景都会出现例外。这些原则对我是有效的，也可能会帮您节省时间和精力。我希望能够有机会在以后的专栏文章中向您通报我利用这些原则建立实际站点的情况。我也非常希望能够了解您的成功经验、意见和建议。

(编辑:aniston)