Atom 1.0 Syndication Format 概述流行的 Web 内容联合格式是如何构成的 |
|
级别: 初级
James Snell, 软件工程师, IBM
2005 年 8 月 22 日
从技术角度来看流行的 Atom Syndication Format。本文将讨论 Atom 与其他联合格式相比在技术上的优势,并通过几个典型的例子加以说明。
在 Internet 上,Web 内容联合是防火墙后面日渐重要的一个领域。一旦 bolg 爱好者的独有领地和在线新闻网站演变成基于 Web 的服务和内容发布的下一代平台,会怎么样呢?虽然联合技术(syndication technology)的采用突飞猛进,但这些技术一直都面临着技术问题、意义不明确和互操作性的挑战,这些为紧跟新潮流的软件开发人员和消费者带来了困难。为了解决这些问题,联合技术社区的成员走到了一起,他们共同分享经验,定义了 Atom Syndication Format 和 Atom Publishing Protocol 标准(请参阅 参考资料)。2005 年 7 月 15 日,第一个规范 Atom Syndication 正式面世。
本文假设您对内容联合和已有的规范家族至少有基本的了解。阅读本文时,建议手头上准备一份 Atom 1.0 格式规范的副本,以便作为所讨论的各种元素的交叉参考。
必须指出的是,本文中的讨论没有任何贬低 RSS 的目的。我们的目的是说明相对于现有的联合格式规范家族,Atom 格式带来了哪些改进,强调 Atom 格式所固有的长处。
一个简单的例子
只要使用 RSS 规范系列产品做过内容联合,任何人都很容易掌握 Atom 1.0。不过 Atom 在很多重要的方面都与 RSS 不同。清单 1 给出了一个简单的 Atom 1.0 feed 的例子。
|
Atom 要求每个提要(feed)和记录(entry)都包括三个元素:
)。 此外,Atom 花费很多时间精心描述了一种健壮、灵活、一致的内容模型,该模型能够支持普通文本、不严格的 HTML、结构良好的 XHTML、任意的 XML、base-64 编码的二进制内容、指向没有直接包含在提要(feed)中的内容的 URI 指针,等等。相比之下,由于不考虑使用非标准的名称空间扩展以及已实现的不一致的名称空间扩展,RSS 只能处理普通文本和不严格的 HTML 内容。
Atom 还提供了定义良好的可扩展模型,该模型提供了添加受 RSS 支持的新元数据和内容的类似分散动态机制,但采用的方法便于保证实现之间的互操作性。比如,Atom 明确说明文档中什么地方能够和不能使用扩展元素、什么样的扩展是语言敏感的(因此要受 xml:lang
属性的影响)、Atom 实现遇到不认识的扩展元素时必须如何应对。
最后,Atom 为核心名称空间中的各种必需和可选元数据元素提供了严格定义。比如,Atom 定义了 author
元素,这是一个复杂结构,包括姓名、邮件地址(按照 RFC 2822 的定义)以及与作者有某种联系的资源标识符(比如作者主页的 URI)。
提要(feed)或记录(entry)可以有多个 author
元素,零个或多个 contributor
元素。这些元素表示可能对提要(feed)或记录(entry)的生产作出贡献的个人,但是不能按照输入级别确定作者(如音频工程师、编辑、软件开发人员等)。author
和 contributor
元素都是可扩展的,只要自己认为合适,内容的生产者可以提供关于作者或者参与者更详细的信息。相比之下,RSS 只规定了更加严格的 author
元素,这类元素只能在每个记录中出现一次,而且只能表示电子邮件地址。
|
Atom 1.0 新增的标准特性包括:
xml:base
支持相对 URI。 xml:lang
增强了国际化。 总之,Atom 内建的种种特性是这种格式能够支持更广泛的联合应用,并克服了现有联合标准家族中普遍存在的很多技术不足。
|
支持 enclosure 标签
在 Weblog 和新闻内容联合之外,联合技术正在发展中的一种最流行的应用是播客(podcasting)。播客是发布录制的数据音频文件的数据提要(feed),可自动下载和复制到用户的便携式媒体设备上。目前,播客是通过 RSS 2.0 的 enclosure
标签实现的,如清单 3 所示。
|
虽然播客迅速盛行,但 RSS 2.0 enclosure 标签至少有一个很突出的局限性,播客们对这一局限性非常讨厌:RSS 只允许每个记录存在一个 enclosure
标签。这意味着对那些希望让自己的音频能以多种格式(如 MP3、BitTorrent 或 WMA)下载的播客生产者,必须为每种格式提供单独的提要(feed)。但是 Atom 允许一个记录中包含多个 enclosure,每个 enclosure 都有相关的媒体 type
属性,这样播客制作者就可以在一个提要(feed)中包含所有发布格式。
作为一个例子,可以考虑 IT Conversations(请参阅 参考资料)提供的播客提要(feed)列表。因为 IT Conversations 播客是以多种格式提供的,潜在的订阅者必须在至少 73 种带有 enclosure 的 RSS 提要(feed)(不包括列出的 37 种纯文本提要(feed))中进行选择。使用 Atom enclosure,只要在每个 Atom 记录(entry)中包括两个 enclosure 链接,IT Conversations 就可以把提要(feed)数减少一半。提要(feed)的减少可以降低内容发布者和内容订阅者的复杂度。
|
Atom enclosure 并不是只能用来发布音频内容。Enclosure 链接可以引用任何类型的资源。比如,清单 5 在一个记录中使用多个 enclosure 来引用可通过 FTP 访问的 PDF 文档的翻译版本。hreflang
属性表示每个 PDF 文档被翻译成的语言。
|
除非在提要(feed)中引入非标准名称空间扩展,否则 RSS 2.0 不可能支持 清单 5 中的格式。原因是多方面的:
Atom link
元素的另一个重要特点是,使 enclosure 不仅能把可下载文件与记录关联在一起,还可以为其他类型的资源规定有意义的链接:
—— 表示提要(feed)或记录(entry)的替代版本(如 weblog 主页)。
—— 表示记录(entry)内容中以某种形式描述的资源。
—— 表示和提要(feed)或记录(entry)等价的资源,一般来说,它允许提要(feed)或记录(entry)成为自参考的,从而能实现更灵活的自动发现机制。
—— 表示提供提要(feed)或记录(entry)所含信息的资源。比如,如果通过在线聚合服务来发布记录,那么可以使用 via
链接来标识该聚合程序,代替目前让聚合程序重写 RSS 的 link
元素的一般做法。 这些内建的链接关系是为提要(feed)中可能使用的最常见、最一般的链接类型设计的。可使用完全限定的 URI 来动态定义新的联系类型。稍后将通过一个例子进一步讨论 link 元素的可扩展性。
|
基于引用的内容
除了 link 和 enclosure 外,Atom 还支持通过 URI 引用记录内容。清单 6 显示了一个图片 weblog 的 Atom 提要(feed)。content
元素引用 bolg 中的每一幅图片,summary
元素提供了图像标题。
|
这种基于引用的内容(content-by-reference)机制提供了一种非常灵活的机制,可用于扩展通过 Atom 联合的内容类型。
比如,人们常常讨论使用联合模型来发布软件升级的想法。这样做的话,链接到包含软件升级、描述升级的网页的可下载文件会很有帮助。因为 Atom 明确区分了 link
和 content
元素的角色,创建这样的提要(feed)非常简单,不需要扩展核心 Atom 名称空间。
|
基于引用的内容的其他应用包括通常不适合静态嵌入到提要(feed)中的数据联合。这样的内容包括音频或视频的实时转播流、安全帐户信息或事务的链接和大型数据流。
|
|
扩展 Atom
当前联合技术的一大优势是开发人员能够用新的元数据类型扩展提要(feed)。Atom 工作组的主要目标之一就是定义良好的可扩展性模型,同时保留内容发布者和联合应用程序开发人员所期望的分散的、动态的可扩展机制,保持 Atom 实现之间的核心互操作性。
Atom 的扩展有两种方式,下面将分别举例说明:
名称空间扩展包括在核心 Atom 元素中混合使用新的 XML 元素和属性。比如,Atom 定义了描述记录创建和发布时刻的元素。不过,可以设想一个生成的内容必须在给定的时间点过期作废的应用程序(比如表示特价商品或者每周排名前十的列表)。Atom 没有提供用于规定超期时间的核心元素。但是可以在单独的名称空间中声明这样的元素,然后将它们包括到 Atom 提要(feed)中,如清单 9 所示。不关心 extension 扩展元素的消费者可以选择忽略它。
|
除了几个例外,可以在 Atom 文档中任何地方使用扩展元素和属性。比如,Atom 的日期结构,如 atom:updated
元素,可以包含 extension
属性,但是不能包含 extension
元素。
顺便提一下,由于 Atom 是通过正式 IETF 标准化过程定义的,人们常常误以为像 清单 9 中的 s:expires
元素这类扩展也必须经过同样正规和集中的过程来批准。绝对不是。Atom 扩展能够以完全分散、开放和非正式的方式定义,不需要任何 IETF 参与,但同时仍能保持互操作性。
链接关系扩展包括创建新的 link
元素和 rel
属性值,标识新的链接关系类型。link
元素将外部资源和提要(feed)或记录(entry)联系在一起,rel
属性表示链接的目的。通过创建新的链接关系,可以扩展 link
元素所能表达的联系类型。
比如,多数 weblog 软件包都支持读者为 blog 记录提交评注。这些注释本身可作为提要(feed)中的记录。清单 10 显示了我提议的一种链接扩展,它支持记录和相关注释间的双向链接。
|
清单 10 中创建了三种新的链接关系:
http://purl.org/syndication/thread/1.0/comments
—— 链接提要(feed)或记录(entry)和包含注释的 Atom 提要(feed)。 http://purl.org/syndication/thread/1.0/root
—— 链接注释提要(feed)和包含原始记录的提要(feed)。 http://purl.org/syndication/thread/1.0/in-reply-to
—— 链接注释记录和原始记录。 这种扩展仍然在积极地讨论和开发中,预计将不断地演化。
其他建议还包括表示提要(feed)历史、相关许可证、提供一种列表排序机制的提要(feed)扩展,更多的建议仍在讨论之中。其中一些扩展可能会最终成为 IETF Internet-Drafts 甚至 RFC,另一些则不会。随着开发人员不断发现新的和有趣的应用,可以预料随着时间的流逝将出现很多有用的扩展。只要稍加努力,在 Atom 中使用现有的大量 RSS 扩展是完全可能的。
|
结束语
2004 年 5 月,Uche Ogbuji 在 developerWorks 上发表了一篇 文章,对 Atom 的定义作了初步介绍。Uche 在文中写道,Atom 的主要目标之一是“创建比很多 RSS 流派技术上更坚实的设计,利用大量 RSS 用户的实践经验作出切合实际的设计决策,使这种新的格式与 Web 的体系结构和文化相适应”。虽然花了一些时间,通过大量仔细地讨论和艰苦的工作,包括 IETF 工作组的积极参与,Atom 1.0 实现了为 Web 内容联合提供一种简单、定义良好和没有歧义的格式的目标。
|
参考资料