rss|标准
全球信息网上的联合供稿（Web syndication）技术种类繁多。一如谚语所述的情况：标准最棒的地方在于标准太多了。
若真要把RSS 1.0 、RSS 2.0 （其实接续的不是RSS 1.0 版，而是0.94版）、Atom和其他林林总总沾得上边的互联网联合供稿技术理出个头绪，恐怕需要做硕士论文级的研究。如果在规范的层次上就有问题、而且没办法解决的话（依我之见有些冲突是被新闻界夸大了），那么我们怎能指望第一线的应用会变得容易上手？本文将讨论使用者设法把现有技术凑合着用的情形。
我碰到的一个RSS 2.0 问题是，网络出版者通常使用不同的惯例，来刊登以RSS（Really Simple Syndication 真简单联合供稿）系统发送的信息。虽然这种弹性正是 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 U 戴尔、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未必相同，也证明我倾向采取的解决办法是对的：
“有关s 的一个常见的问题是与s 该怎么区分，不就是同样的东西吗？没错，在内容系统里是如此，但在其他的系统就不见得。在某些系统，s 是连上网志篇章的permalink.但在别的系统，每一个<ITEM>是全文的摘要，s 指向该文，而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 特有的弹性为什么会让企图在乱中求序的人士（比方说软件开发者）日子难过。毕竟，混乱本是互联网的常态。