如果 清單 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 中
我嘗試用一些示例來說明涉及到的權衡因素，並試圖通過這些示例來論證我的經驗性規則。但是，我沒有證明任何規則，因為這些示例都是特殊情況，而且大多數現實場景都會出現例外。這些原則對我是有效的，也可能會幫您節省時間和精力。我希望能夠有機會在以後的專欄文章中向您通報我利用這些原則建立實際站點的情況。我也非常希望能夠了解您的成功經驗、意見和建議。