本文主要是介绍使用 XML: 扩展 RSS 的能力，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
相对于它的受欢迎程度，RSS 标准惊人的简单，甚至可以说有限。RSS 没有假装能做很多东西，但被设计成能够通过 RSS 模块扩展。本文介绍了三种流行的 RSS 扩展，并说明如何设计您自己的扩展。
RSS 简单却并不有限
RSS 这个缩写词有很多含义：真正简单的联合（Really Simple Syndication）、丰富站点摘要（Rich Site Summary）、RDF 站点摘要（ RDF Site Summary），可能还有其他的说法。实际上，RSS 就是在越来越多的网站（包括 developerWorks）上出现的那个桔红色按钮。
通过 RSS 提要可以订阅站点并在更新的时候得到通知。RSS 和电子邮件订阅有两个重要的区别：
- RSS 需要特定的客户机，即 RSS 阅读器，不过将逐渐包括到 Web 浏览器中。
- RSS 保护用户的秘密，与电子邮件不同，不用在站点上交换个人信息。
RSS 101
编写您的第一个 RSS 文件再简单不过了。根 RSS 元素称为 rss（非常合适）。后面紧跟着的是 channel 元素。
channel 元素首先包含关于新闻提要的描述。它至少要包括一个提要标题（title）、到相关网站的链接（link）和提要描述（description）。
其他元素是可选的。最常用的有提要语言（language）、发布日期（pubDate）、分类（category）和有效期（ttl），即频道缓存的分钟数。
经常还会包括 docs 元素，这个元素有点特殊。docs 元素指向 RSS 文档，因此必须与每个 RSS 文档的值相同。
频道描述之后是一个 item 元素列表，每项代表一个新闻事件。
什么称得上新闻？这取决于站点和应用程序。对于一般的网站，项（item）可能表示页面的一次重要更新；对于播客（podcast），就是一段新的插话；对于网络监控应用程序，就是一次网络警报；对于论坛，就是一个新的帖子。
item 的内容与频道本身类似：title、link 和 description。可能有更详细的日期、到多媒体内容的链接（enclosure）、来源和注释。
要在描述中包含 HTML 标记必须对其进行转义（通常使用 CDATA 节）。
值得注意的是 guid 元素，一个特殊的标识符。表示的时候，RSS 依靠它标识新的项。如果没有 GUID，阅读器必须比较项标题和内容来查找新的项。
清单 1 给出了 RSS 提要的一个例子：
清单 1. RSS 提要
|
为了订阅提要，访问者需要一个 RSS 阅读器。简言之，阅读器定期下载 RSS 文件，如果发现新项就通知用户。
两种主流浏览器中内置了 RSS 阅读器：Firefox 1.5、Internet Explorer 7，Safari 也带有一个 RSS 阅读器。还有独立的阅读器，比如 NewsGator 的阅读器。此外，对于那些不喜欢安装新软件的人来说，可以通过聚合站点（如 Google Reader 和 NetVibes）阅读提要。甚至还有 RSS 和电子邮件之间的桥梁，如 Zookoda。
除了本节所述的之外，RSS 还定义了其他元素。完整的规范请参阅 参考资料。
RSS 的能力
一句话，需要共享信息或者通知用户的宿主应用程序或网站能够从 RSS 提要中获益。事实上，RSS 的应用像野火一样蔓延得很快。
大量的应用也带来了一些问题。一些开发人员抱怨说不得不把概念硬塞进项中，而后者的局限性太大。为了解决这种局限性，RSS 2.0 被设计成了一种可扩展的语言。规则很简单：RSS 元素本身没有名称空间（与 RSS 0.92 保持向后兼容），但是允许开发人员在自己的名称空间增加元素来扩展 RSS。
如果标记具有名称空间，RSS 阅读器就会尝试根据名称空间识别出扩展来。如果成功就能处理这些元素。否则简单地忽略这些元素。
因此，RSS 提供了一个基础，可以建立更强大的应用程序。这种机制的优点在于，对阅读器来说扩展是可选的，不能处理某个扩展的阅读器仍然可以有效地处理核心 RSS 规范。
关于名称空间的说明
在继续后面的讨论之前，我先来揭穿关于名称空间的一些神话。奇怪的是，W3C 发布名称空间推荐标准七年之后，仍然存在着很多误解，而且不幸的是，还体现在一些 RSS 阅读器没有正确地实现标准。
名称空间是为需要在一个核心元素集上扩展的词汇表设计的，比如 RSS。具体而言，如果两个不同的扩展使用意义有别的同一个 XML 元素，名称空间可以防止名称冲突。
由于扩展是独立开发的，出现重复使用的名称只是一个时间问题。比如 “key” 这个词。它可能是数据库中的键，也可能是加密中的密钥。
为了消除歧义，名称空间 将元素名分为本地名和名称空间统一资源标识符（URI）。名称空间 URI 是扩展的惟一标识符。就其自身而言，本地名不能保证是惟一的，但本地名和名称空间 URI 结合起来可以做到。
我假设大部分读者都熟悉名称空间的语法。简单地说，xmlns 属性声明一个前缀并将其和名称空间 URI 联系起来。然后前缀又把名称空间 URI 和本地名联系起来。本地名和前缀之间使用冒号作为分隔符。清单 2 是一个例子：
清单 2. 名称空间声明
|
实际上，名称空间有两点容易造成混乱：
- 标识符是 URI 而且多数时候就是一个 URL。
- 前缀和本地名的组合不能保证是惟一的。只有名称空间 URI 才能保证惟一性。
我将说明如何解决这两种错误。
首先，名称空间 URI。对于名称空间而言，URI 是严格的词汇表标识符而不是定义。因此，URI 指向何处没有关系。很多情况下，指向的源甚至不存在。
开发人员和用户虽然喜欢定义，但是他们认为在处理给定名称空间中的元素之前迫使应用程序下载文件是不能接受的。
很多应用程序在运行时仍然没有稳定的 Internet 连接。即便有 Internet 连接，下载文件会降低其速度，这一点也不总是允许的。况且如果网站（暂时）不能用怎么办？
此外，对于名称空间来说，需要的仅仅是一个标识符。
为什么用前缀呢？在每个标记上添上 URI 会增加文档的长度。于是引入了前缀作为缩短 URI 的一种办法。但是，前缀不能保证是惟一的（如果本地名不能保证这一点，有什么理由相信前缀会是惟一的，尤其是给出的前缀通常很短），所以必须引用 URI。
这就引出了 URI 的特殊性质，它们可作为惟一的标识符是因为大部分 URI 是 URL，而 URL 包含域名。只要使用自己拥有的域名定义名称空间就能保证惟一性，因为没有其他组织注册同一个域。
三种流行的扩展
为了具体了解扩展的工作原理，我们来看看三种常见的 RSS 扩展：
- 用于元数据的 Dublin Core
- 用于播客的 iTunes
- 扩展了扩展的 Syndicated Photography
Dublin Core
Dublin Core 是一组元数据元素，最早是 RFC2413 定义的。Dublin Core 是资源搜索的最小元数据集。已经被用于 HTML（META 元素中）和各种 XML 词汇表。
Dublin Core 中的一些元素与 RSS 元素相同（比如 language），这是不可避免的，因为它是在 RSS 之前诞生的。但是这些重复也很有用，因为可以在频道或项上增加 Dublin Core 扩展。比如，RSS copyright 元素只能出现在频道层，但是可以把 Dublin Core rights 附加到每个项上。
Dublin Core 名称空间是 http://purl.org/dc/elements/1.1/。
清单 3 中的例子在 RSS 中使用了 Dublin Core：
清单 3. RSS 中的 Dublin Core
|
Dublin Core 扩展表明即使与 RSS 类似的元素也有自身的价值，可以提供更多的选择。
iTunes Music Store
iTunes 通过其 iTunes Music Store 提供了对播客的直接访问。为了在存储中集成播客，iTunes 用名称空间 http://www.itunes.com/dtds/podcast-1.0.dtd 定义了一个扩展。
iTunes 扩展非常值得注意，因为：
- 在定义不同的时候，它没有逃避重新定义与 RSS 类似的元素（比如
itunes:image，iTunes 需要 300×300 像素的图像，而 RSS 规定最大宽度为 144）。 - 定义了新元素来增强用户的可访问性（比如
itunes:duration提供了播客的播放时间，而 RSS 只提供了文件长度）。
清单 4 中的 RSS 例子使用了 iTunes 扩展：
清单 4. 带有 iTunes 扩展的 RSS 提要
|
Syndicated Photography
Photocasting 意思是通过 RSS 提要分发照片。它与播客的原理相似，但传播的是图像而不是声音。初看起来，要用 RSS 提要分发照片，似乎使用 enclosure 元素就足够了。
聪明的照片浏览者首先下载缩略图，然后只下载用户请求的照片。但这不是 enclosure 的行为方式，因此 Pheed 只得定义包含这两个标记的扩展：photo:thumbnail（下载快的小图像）和 photo:imgsrc（完整的图像）。Pheed 是一个 RSS 聚合程序，为多媒体文档如图像提供了专门的支持。
有趣的是，照片也需要元数据，于是 Pheed 选择了 Dublin Core。因此，照片扩展建立在另一个扩展的基础上。避免了重复劳动因而提高了效率。
清单 5 是照片提要的一个例子。要注意其中声明了两个名称空间：
清单 5. 带有 Syndicated Photography 扩展的 RSS 提要
|
定义自己的扩展
如果发现希望 RSS 再增加一项功能该怎么办？
- 要确保还不存在您需要的扩展。不要重新发明轮子，这会给 RSS 阅读器带来痛苦。
- 如果发现仍然需要开发自己的扩展，一定要遵循正确使用名称空间的规则。
- 如果根本不合适，不要害怕重新定义已有的元素（比如
itunes:image与 RSS 自己的image虽然类似但不相同）。超负荷使用元素只能造成混乱。
RSS 是一种灵活的格式，但更重要的是，它可以作为很多需要广播或窄播（narrowcast）的应用程序的基础。感谢扩展机制，它的用处简直太大了。
  |
|
参考资料
- 参与论坛讨论。
- RSS 简介（Vincent Lauria，developerWorks，2006 年 6 月）：了解 RSS 和其他提要阅读器。还可以了解 RSS 如此流行的原因及其优点，以及提要阅读器的选择。
- RSS 规范：可读性很强的规范。
- Atom 1.0 Syndication Format 概述（James Snell，developerWorks，2005 年 6 月）：Atom 可以作为 RSS 提要阅读器的替代品。
- iTunes extensions：阅读这份简单的规范，了解准备 RSS 提要的提交过程和技术问题。
- The Dublin Core：它是很多元数据标准的基础。
- Pheed extension that builds on Dublin Core：了解 Pheeds —— 包含其他少数摄影相关元素的 RSS 文档。
- IBM XML 1.1 认证：了解如何才能成为一名 IBM 认证的 XML 1.1 及相关技术的开发人员。
- XML：developerWorks XML 专区提供了各种技术文章、技巧、教程、标准和 IBM 红皮书。
- developerWorks 技术事件和网络广播：随时关注技术的最新进展。
关于作者
| ||
|
| | Benoît Marchal 是一位顾问和作家，居住在比利时 Namur。他撰写了 XML by Example、Applied XML Solutions 和 XML and the Enterprise。他创建了摄影播客 Declencheur。 |
这篇关于使用 XML: 扩展 RSS 的能力的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
