若真要把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不会，也无此必要。他和别人的网志之所以可读性高，与附标题的新闻报导与众不同，就是因为网志就像日记一般。这些网志有许多篇章是想到什么就援笔立就，若是作者必须停下来先为每一篇定个标题，可能就跟不上奔驰的思绪。这些是特例。另
