XML 程式設計思想: 使用 Atom 格式連鎖新聞及其他內容(轉)

XML 程式設計思想: 使用 Atom 格式連鎖新聞及其他內容(轉)[@more@]

　　Web 上總有一些站點提供系列的文章、事件和其他記錄事項，用於分享和交叉引用。隨著 Web 很大一部分成為會話式的社群，社群中的很多人走到一起為這類交換和交叉引用開發一種基於 XML 的標準。Atom 就是這些努力的結晶，它是一種交換 Web 後設資料的格式和 API。Uche Ogbuji 在本文中介紹了 Atom。請在本文的 討論論壇上與作者和其他讀者分享您對本文的想法。

　　RSS之爭在 XML 社群中人所共知。Netscape 把這種輕量級的格式拼湊在一起用於連鎖，即把網站中傳輸的資訊聚集到門戶中。由於從這個低調的起點開始，甚至連這個縮寫詞的含義也受到了爭議。Weblogs 和下一代門戶已經使 Web 資源描述的交換成為一種普遍而重要的現象。各種流派的 RSS 統治著後設資料交換的世界，無休無止的 RSS 紛爭增加了風險。

　　長期捲入這場衝突的一位知名技術專家是 IBM Emerging Technology Group 的 Sam Ruby。2003 年中期，Ruby 提議 RRS 及相關連鎖格式的各方面的專家和使用者共同合作開發下一代格式。部分目的是建立一個顧及各種派別的標準，從而平息 RSS 紛爭。另一個目標是建立技術上更加完善的設計來代替不同的 RSS 風格，根據很多 RSS 使用者的實踐經驗對這種實用的設計進行折衷，使新的格式與 Web 的體系結構和文化協調一致。大批開發人員和作者爭相加入該專案，顯然是因為對 RSS 中無休無止的硝煙和陰謀感到失望，期望對所討論的技術問題出現一種新的解決方法。

　　該專案最初稱為 Echo，但由於商標問題而更名為 Atom。如 Atom Wiki 所宣稱的那樣，該專案要建立“連鎖、存檔和編輯情節式站點的規範”。我認為，Atom 處理領域的定義特徵不僅僅是自然分解成情節的 Web 站點，還包括那些與其他站點互動中具有會話性質的 Web 站點。情節往往帶有對其他站點上類似實體的交叉索引，Atom 就是為了把這類交換粘結在一起。

　　Atom 令人矚目有很多原因，最突出的一點是儘管作為一種社群規範，作為有史以來組織最為龐大的委員會磋商的結果，它仍保持了簡單性。Atom 包括 Syndication Format Specification（連鎖格式規範）（目前為 0.3 版，草案 2），它是表示 Web 資源資訊的 XML 格式；和 API Specification（API 規範）（目前為 0.9 版），基於 HTTP 檢索和修改 Web 資源資訊的一些約定。雖然目前只有 API 規範正式提交給了Internet 工程任務組（IETF），這兩種規範都採用 Internet Draft 的格式編寫，以期最終成為 RFC 標準。除了 XML 語法之外，Atom 還使用 Web Ontology Language (OWL)開發了 RDF 形式。本文中對 Atom 的介紹主要放在 XML 格式規範上，但在適當的地方也會涉及到 API。所有的 Atom 規範仍在積極地開發之中，在標準化之前還可能發生變化，雖然基本的 Atom 風格很可能不變。

　　建立 Web 資源

　　假設您要創辦一份格律詩的 Web 雜誌，稱為 Stanza Web。您可以使用 Atom 更新站點、列出新的詩篇、文章和其他專輯、從相關的其他站點收集資訊。要做的第一步是上傳歡迎讀者的文章。為此，Atom API 規定要把內容包裝在由 Atom entry 元素組成的 XML 文件中，並把該文件作為 HTTP POST 訊息發給特定 URI PostURI上的 Web 伺服器。清單 1 就是一個這樣的 XML 文件。

　　清單 1. 傳送到 PostURI 建立入口的 Atom 條目

　　　　　　Uche Ogbuji　　<!-- May also contain a URL and e-mail address --&gt　　　<!-- Time in UTC --&gt　2004-06-01T10:11:12Z　　　

　

　　Atom 格式中的所有元素必須在名稱空間 中，或者是在根據擴充套件規則尚未設定的外部名稱空間中。 entry 元素必須包含以下子元素：

• title
• 帶有 alternate 關係的 link
• modified

　　entry 還可以包含其他元素，如 id 、 contributor 和 content ，後者通常在定位 PostURI 時出現，就像本例這樣。

　　所有這些條目資訊在伺服器向客戶傳送關於已有資源的資訊時意義非常明顯，但是在定位 PostURI 時每個元素的作用在規範中沒有清楚地說明。 title 和 author 元素大概用於設定建立資源時的相關後設資料。 modified 元素向伺服器提供瞭如何給出條目時間戳的線索，儘管如果資源的時間戳是按照伺服器策略而非提交者的指令設定的，伺服器應該如何對這種情況作出反應沒有明確的規定。 link 大概是告訴伺服器如何為建立的資源構造 URI，以及為那個資源的表示（至少要有一種）指定什麼樣的 Intenet 媒體型別，雖然這樣會引起更加苛刻的策略問題。

　　content 元素可能用於建立所建立資源的主體。內容甚至可以是二進位制的形式，可以使用 MIME 的所有能力。在這個例子中，內容被設為 XHTML div 。如果上傳的資源最終將和更大的 Web 頁面結合起來顯示——Weblog 中很常見的情況——這是一種很好的辦法。其他情況下，可能合理的做法是在內容中傳送完整的 XHTML 文件（根元素為 html ）。當然傳送其他的內容格式也是完全有效的，如 HTML、普通文字、甚至影像或者音訊檔案。如果要這樣做，必須保證正確地設定各種不同的媒體型別屬性。

　　Atom 發現

　　現在新建的網站上已經有了一個歡迎頁面，您希望具有相同愛好的人能夠找到它。其中一些人可能想把您的 Atom 連鎖資訊放到他們自己的網站上。一些人則希望評論您的訊息。為了使 Atom 實現這類功能，可以更新 Web 站點並在 HTML 頭中增加一些特殊的 Atom 專用連結。清單 2 中的 HTML 片段說明了這些連結的用法。

　　清單 2. HTML 頭中用於發現 Atom 相關 URI 的連結

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ... 　　　

　　在 清單 2 中，第一個 link 元素（紅色）有一個聯絡值 service.post 提供了整個站點的 PostURI，通常用於建立新的文章。不同文章的網頁很可能有不同的 PostURI 連結以便建立那篇文章的評論。它可能還有一個連結 rel="service.edit" ，提供一個 EditURI。向這個 URI 傳送一個 HTTP GET 訊息就可以得到適合編輯的表示形式，然後使用 HTTP POST 傳送更新的內容。第二個 link 元素（藍色）有一個聯絡值 service.feed ，提供了 FeedURI。Atom 客戶可以傳送 HTTP GET 請求來檢索完整的 Atom 提要。

　　Atom API 規範中沒有直接處理安全問題，但預計會出現用於各種 Atom API 操作的支援基於 HTTP 驗證的實現。

　　Atom 提要

　　理想情況下，讀者會來到 Stanza Web，閱讀文章並決定是否會再回來看看。然後，他們可以讓 Atom 工具指向該站點閱讀其 Atom FeedURI。任何時候，您都可以訪問 FeedURI 檢索站點提要，通常表示最新的或者變更的後設資料。清單 3 給出了一份 Atom 格式的提要。

　　清單 3. 從 FeedURI 檢索的完整 Atom 提要

　　　　　2004-06-01T10:11:12Z　　　Uche Ogbuji　　　　　　　　　Uche Ogbuji　　　　　　2004-06-01T10:11:12Z　　　　　

　　　

　　最頂層的元素是 feed ，它包括新增文章的 entry 元素。 feed 的其他子元素傳達了關於整個站點的後設資料。帶有 rel="alternate" type="text/html" 的 link 作為替代表示給出了站點的可閱讀表示。Atom 工具也可使用 modified 元素確定站點的新內容是什麼時候增加的。

　　結束語

　　Atom 規範還需要大量的工作，仍有一些不足，比如關於個人的 URL 用元素的內容而非屬性表示。在 Atom 最終成為標準之前還有充分的時間修正這些問題。已經有幾種試驗性的 Atom 實現，倘若能夠貢獻您的才智，Atom 社群是非常開放的。不要忘記，如果本文引起了您的注意，請在 Thinking XML討論論壇 上提交您的想法。