David Berlind‧唐慧文　　2005/01/07

全球資訊網上的聯合供稿(Web syndication)技術種類繁多。一如諺語所述的情況：標準最棒的地方在於標準太多了。

若真要把RSS 1.0、RSS 2.0(其實接續的不是RSS 1.0版，而是0.94版)、Atom和其他林林總總沾得上邊的網際網路聯合供稿技術理出個頭緒，恐怕需要做碩士論文級的研究。如果在規格的層次上就有問題、而且沒辦法解決的話(依我之見有些衝突是被新聞界誇大了)，那麼我們怎能指望第一線的應用會變得容易上手？本文將討論使用者設法把現有技術湊合著用的情形。

我碰到的一個RSS 2.0問題是，網路出版者通常使用不同的慣例，來刊登以RSS(真簡單聯合供稿)系統傳送的資訊。雖然這種彈性正是RSS 2.0最棒的優點之一，但如此一來，把多重RSS feeds標準化以便匯整呈現的負擔，就轉移到閱聽者這一端。儘管終端使用者應用程式(包括RSS閱讀器在內)通常內含人工智慧，可補救所處理檔案格式紊亂不一的問題(這也意味處理RSS的應用軟體前景相當不錯)，但我懷疑RSS會不會也證明軟體商要兌現諾言極為困難 -- 他們承諾提供為平常人開發的軟體，讓技術生手只用游標和滑鼠點選和拖曳，也能打造出複雜的、交易性(transactional)、伺服器端的應用。

畢竟，RSS是當今最能展現可延伸標示語言(XML)對普羅大眾有何用處的範例，也象徵大多數人與XML最接近的接觸。基於RSS的人氣日盛，大有可能演變成所有資料(不論結構嚴謹或鬆散)賴以採集的主要方式 -- 不論用途僅為瀏覽最新的網誌(Weblog)更新內容、檢索電子郵件(嘿，那不就終結垃圾郵件了嗎？)，或是透過複雜的工作流程傳遞交易資料。就此而論，RSS也可能被當作「點選式程式設計」(point-and-click programming)的一大試金石。

為了鼓勵透過ZDNet網誌領域進行線上協同作業，我們已建立一個內部的Wiki。日後或許內容會更豐富，但目前我們的Wiki首頁比較像是共享的書籤陳列室。我倒是建了一個次級網頁，展現出多重使用者系統的威力：在上面可把我所屬工作群組必須追蹤的網誌一覽無遺。我用Twiki標題外掛程式把以RSS為基礎的聯合發稿內容匯整到同一網頁，基本上該網頁相當於在網誌領域的一個角落設立入口網站，以便我們觀察我認為不該遺漏的網誌。我稱之為我們的雷達。

我加入擷取自Robert Scoble、Jonathan Schwartz、Tim Bray、Bob Frankston、Slashdot、Groklaw等網誌的內容，不久之後，ZDNet.com副總裁Stephen Howard-Sarin又在這個網頁添加了一些，取自於Dan Bricklin、Jon Udell、Dan Gillmor、Phil Windley、Doc Searls等人的網誌。儘管這還稱不上是「點選式伺服器端程式設計」，我認為已十分接近。

但我不滿意這個外掛程式預設的內容擷取格式，以及在網頁上呈現的方式。所以，為牽就我們的需要，我在外掛程式之外添加了一些選擇參數(optional parameters)，以確定最後顯示出來的網頁是純文字(為了效能起見)，而且只從各種內容來源擷取最新的五則標題。以圖示來呈現這類選擇參數、自動產生編碼，並且把程式碼嵌入網頁，這些正是我期待「點選式程式設計」能夠為我代勞的事，而不是凡事都得用硬碼(hard-coding)方式來做(我目前的作法)。

在Wiki普遍成為政治正確的作法之際，Howard-Sarin也在添加網誌內容時仿效我採用的格式。由於欠缺更簡單易用的工具，他只用剪貼方式把程式碼拷貝過來，然後提供不可或缺的替代品。對一群非專業程式設計者來說，能做到這種地步已經很不錯了吧？短短幾個鐘頭，我們兩人同心協力製作了一個入口網站，提供有意義的資訊，而且會隨每次網頁重新整理更新內容。現在，就等其他ZDNet使用者共襄盛舉，把他們喜愛的、不重複的網路內容丟進這個網頁即可。

可是，還有個問題。有些內容無法正常顯示，害得我耗費比原訂計畫更多的時間。比方說，Jonathan Schwartz網誌裡的每一篇內容，都以異於他人的方式呈現 -- 在他以XML為格式的內容中，每一篇不重複的網誌內容(稱為一個item) 都省略連結欄(link field)。大多數的內容，例如擷取自ZDNet的本文，都用連結欄來儲存通用資源識別碼(URI)，以直接連上個別的item(就本文為例，指的是一篇新聞報導，而不是網誌裡的一則日誌)。省略掉連結欄，Schwartz依賴GUID (全域唯一性識別碼，讀音「gwid」) 欄附帶的選項(稱為「permalink」)，來儲存常駐的連結，以連上個別的網誌文章。這麼做是有道理的，因為要跨越整個網際網路連上某則特定的內容，使用專屬的連結是你所能找到、最獨一無二的方法。或許你能想出別的辦法，但何必花這個腦筋呢？基於此理，幾乎人人都把導向自己每則內容的直接連結存在GUID裡。對許多人來說，這意味在GUID裡找到的資料，與在連結欄(若他們採用的話)裡尋得的資料，是一模一樣的。

這些很重要嗎？嗯，就我而言，我覺得很重要，因為我試著想出一種可輕易重複使用的外掛程式參數組合(用「點選式程式設計」術語會稱之為「物件」，但我要等到親眼目睹才會信以為真) ，來建置我們的入口網頁，而那套組合要能夠用同一方式對待本網頁所觀測的各個內容來源。如果某物件在「普通人用的點選式程式設計」現實世界裡只是偶爾才管用，那麼沒多久，一般人就會棄滑鼠投降。

參照TWiki文件編寫採用連結欄的範例，我開始嘗試用它來提供入口網站使用者一個可回歸原始內容出處的連結。這很合理，不是嗎？然而，一旦連結欄被省略，如同Schwartz網誌的情況，即便我在入口網頁上一一附上連結，也不過是死的連結。為了研究這個問題，我進一步探討RSS的弱點 -- 我不認為其他只為體驗網路聯合供稿威力的使用者必須探究得這麼深入。我發現，如果Schwartz的網誌把每則內容專屬的URI存進GUID的話(他是這麼做的)，那麼我就可以倚賴GUID的目錄把使用者導回內容的原始出處。就可重複利用的能力而論，我考慮把這種作法全面套用在我們監看的所有內容上。

以下這一段是RSS 2.0的規格範例，由此可說明連結與GUID未必相同，也證明我傾向採取的解決辦法是對的：

「有關<guid>s的一個常見的問題是與<link>s該怎麼區分，不就是同樣的東西嗎？沒錯，在內容系統裡是如此，但在其他的系統就不見得。在某些系統，<link>s是連上網誌篇章的permalink。但在別的系統，每一個<item>是全文的摘要，<link>s指向該文，而<guid>s則是連上該則網誌內容的permalink。不論在什麼情況下，都建議你提供guid，並儘可能讓它以permalink呈現。這麼做可避免匯整器重複擷取相同的item，儘管這些item可能因為有修改過而有所不同。」

以上是專家建議的最佳範例，無疑是大勢所趨，也隱約暴露出許多內容供應系統依循不同慣例的問題。這正是我遭遇的問題。現在，可重複利用性已被判出局，而我甚至還沒開始嘗試用滑鼠作「點選式程式設計」咧。就每一個我加進入口網頁的內容來源而言，現在我會先研究它的XML，再決定該用哪一套參數。

但GUID相對於link的問題，並不是我們面對的唯一挑戰。

有些內容供應feeds，像是Dave Winer的Scripting News，也丟出一個變化球。Winer的網誌文章不附標題。這是個麻煩，因為要建置含20多個出處、一目瞭然的入口網站，我們決定最簡單的作法便是只顯示item的標題，然後附上導向全文的連結(使用前文提到的item連結或GUID，視哪一種比較適用而定)。但是，就Winer的XML來說，能擷取的東西有限。沒標題可選，只能擷取其他三種 -- GUID、item的發表日期(pubDate)、或是item(敘述)的全文。但item的全文長度從寥寥數字到堂堂數段不等，沒道理拿它來當作超文字連結(hyperlink)。

如同Schwartz的網誌，Winer的GUID也是連上全文的URI。換言之，能供我們用來當連結的文字只剩下發表日期。顯然Mozilla.org對無標題item的感受和我們一樣。Firefox瀏覽器採用一種稱為Live Bookmarks的功能，用來追蹤RSS feeds；該瀏覽器在碰上無標題item時，為了產生可點選的內容連結選單，也提供發表日期作為連上原文的線索。事實上，在處理規格不一的RSS應用方面，Firefox的表現一級棒，就連碰上在同一網誌裡有的item附標題、有的又不附標題的John Robb頻道時，也能機動應變。把Robb的網誌加入Firefox的Live Bookmark後，產生的選單即顯示出Firefox從每一item就地選材，有的擷取發表日期，有的擷取標題。這印證前文所言，就網路聯合供稿而論，供應端所做的選擇，其衍生的後果一概由閱聽者這端承擔。換句話說，控制權從供應者這方轉移到內容出版者這方。值得注意的是，此現象似乎與全球資訊網的走向背道而馳。(基於Internet Explorer使用者眾多，和許多網站用Firefox無法正常顯示，以後見之明來看，即可驗證供應端總是會順應需求端來作調整。)

同理，再度驗證通常軟體會代使用者做複雜的決定和演算法，Dave Winer的網站內容匯整器也作了令人讚許的貢獻，就是把各式各樣的內容慣例標準化，形成單一介面，再透過該介面把源自不同頻道的文章攙雜在一起，按照匯整器擷取的時間倒序排列。比方說12點15分時，某頻道可能顯示出五則，但其中最早刊出的一則也許不比排在它前面、出自另一頻道的文章來得新。不過，不論是哪一則，都是根據終端使用者所在地的時區來顯示發表時間。網路匯整器可不可能自動判知終端使用者的時區，我不清楚；但就Firefox和Newsgator這類美國境內執行的RSS匯整器而言，是辦得到的。看出未來的成長空間了嗎？

起初，我暗地咒罵Winer竟然不附標題。但一旦開始追蹤Winer的網誌後，我就領悟到這種抉擇自有道理。他的網誌只是意識流似的日誌。人在思考時，會先下標題嗎？不會吧。Winer不會，也無此必要。他和別人的網誌之所以可讀性高，與附標題的新聞報導與眾不同，就是因為網誌就像日記一般。這些網誌有許多篇章是想到什麼就援筆立就，若是作者必須停下來先為每一篇定個標題，可能就跟不上奔馳的思緒。這些是特例。另一人氣鼎盛的網誌，作者是微軟的Robert Scoble，就不管每則篇幅多短，都一律冠上標題。以最近談微軟執行長Steve Ballmer評論蘋果iPod的那一則為例，標題幾乎與全文等長。如果他給網誌文章下的標題少一些，或根本不定標題，或許我們更能深入了解Scoble腦子裡的想法。

為了建置一套可重複利用的參數(以便別人只需剪剪貼貼即可)，我不得不緊盯著Winer的內容，我愈是瞪著它瞧，就愈發現自己掙扎於兩種選擇之間的取捨：該用發表日期作為我們TWiki架構入口網站的連結文字呢，還是乾脆把他的全文(儲存在各個item的敘述欄內)下載並顯示在我們的入口網頁呢？畢竟，我們內容顯示的程度僅止於最新的五則，而Winer每天定期刊出五則以上，所以若是列出一串發表日期，除了告知每一則何時刊出以外，提供的資訊聊勝於無。我們真正需要的訊息，是全文的內容為何。碰到Winer這種不附標題的內容，我們唯一的選擇，就是擷取全文(端視外掛程式允許的容量而定)。

事實上，一口氣完整的擷取(包括GUID、敘述、發表日期和某來源提供的其餘材料)，逐漸看來是最適合我們入口網站的通用方法。就這麼搞定。我總算可以回頭做我日常的工作了吧？哎，還不行。

誠如Winer告訴我的，那種作法可能也行不通，因為和許多網誌不同，新聞網站通常在每篇報導的敘述欄裡提供摘要，而不是完整的全文。更糟的是，就算也把敘述抓過來，我發現TWiki的標題外掛程式無法處理超文字標示語言（HTML）格式，而網路新聞幾乎清一色都用這種格式編寫。

這個實驗計畫就像舊時卡通裡會漏水的水壩。就在你以為所有的漏洞都堵好了的時候，另一處漏水又泉湧而出。最後我只好許願，但求聰明人發明只要點選一下就可解決問題的辦法，就像軟體開發業者向來承諾的那般。只是，就現在的進步速度來看，我懷疑那可能要再苦等數年。

但本文仍算是一篇談論RSS優點的報導 -- 也附帶闡述RSS特有的彈性為什麼會讓企圖在亂中求序的人士(比方說軟體開發者)日子難過。畢竟，混亂本是網際網路的常態。