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未必相同，也证实我倾向采取的解决办法是对的：

文章地址:   http://www.xinasp.com/html/yejiexinwen/zhanchangxinde/20061005/4152.shtml
TAG： 正是 优点 缺点