为网页内容添加结构和语义的hAtom微格式

来回顾一下我们之前讨论过的微格式：rel-系列， XFN，hCard 和 hCalendar。

非常酷的微格式：XFN规范

我们这次来讨论hAtom微格式，这个微格式用来为网页内容添加结构和语义从而使得网页内容或者局部内容可以被广播（syndication），比如博客日志或者新闻文章等。

hAtom微格式是建立在Atom XML同步格式基础之上的。跟之前hCard和hCalendar不同，hCard和hCalendar都和传统数据格式有着1:1的对应关系，但是hAtom同Atom之间却没有这种直接的对应关系。Atom是一个很稳定的模型，能够为内容广播提供非常多的功能。而hAtom仅仅是提供必须的元素，因此更像是Atom的子集。由此说来，hAtom具有的属性和子属性也都是基于Atom原有的术语而来的。

尽管hAtom基于Atom，hAtom本身并不是一个广播格式。hAtom的作者和编辑──David Janes──解释说：

hAtom was never intended to be a syndication format nor to compete with Atom or RSS. It’s simply designed to describe the microcontent on webpages, such as blog posts. We used Atom because it provides a well-defined nomenclature for describing such elements.（译：hAtom从来都不是为了作为广播格式存在，更不是为了同Atom或者RSS之间竞争。他就是用来描述网页中的为内容，比如博客日志。我们使用Atom是因为他提供了很好的术语可以描述这样的元素。）

所以，hAtom不是专门为了那些需要广播的网页内容的。不过，为了这篇文章的目的，我会在博客日志的基础上讨论，而博客日志通常是需要支持广播的网页内容。

在讨论hAtom细节之前，让我们来看一下基础的规则（同hCard和hCalendar类似）：

还是，对所有微格式适用：包含他们的标记元素是什么不重要（虽然应该是有效并且具有语义的）。Class的值（属性或子属性）决定了hAtom微格式。

如果您选择使用hAtom，同样应该在网页的代码中加上他的Profile说明：

head profile=http://purl.org/uF/hAtom/0.1/

对hCard和hCalendar，我提过使用组合Profile，可以覆盖所有非提案微格式：

head profile="http://purl.org/uF/2008/03/

不过，hAtom是提案规范，他的Profile没有涵盖在组合Profile里面，所以，还是需要明确的指明他。如果您还引用组合Profile，可以简单的添加hAtom Profile（W3C 允许 多个profile值，使用空格隔开即可）：

head profile="http://purl.org/uF/2008/03/ http://purl.org/uF/hAtom/0.1/

背景信息差不多了，现在我们来看实际的hAtom，下面的hAtom信息是描述我的博客日志全文的：

hAtom的根属性是，他可以包含一个或者更多条目（在上面例子上，条目就是博客日志）。这个根属性是可选的。如果没有明确包含根属性，默认假设他已经存在于页面中了，上面的例子中就没有包含根属性。如果必要的话，页面中可以包含多个。

每个条目必须包含在属性中。如之前提过的，可以应用一个或多个属性。上面例子中，只有一个是因为这个实现是应用在显示博客某一日志全文的页面中。我会在文章后面讨论如何使用多个条目。

属性包括了条目的所有信息。

是必需的子属性之一，用来说明条目的题目。在上面例子中，我为应用了属性，因为作为题目，把他放在头条结构中是具有一定语义信息的。

是另一条必需的子属性，用来说明条目的作者。根据规范说米功能，包含在子属性中的内容必须使用标记上的元素。

但是，也还有很多实际操作的例子中，发布者并不在意列举出作者名字，包括我的博客。hAtom的规范默认了这种情况并允许可以不在属性中包含作者信息，不过是在当页面本身已经包括了hCard的信息，并含有指定子属性的address元素。这个方案也在hAtom 的FAQ中作了解释。

因为我在我所有页面的页脚中都包括了hCard实现，所以，我没有在hAtom信息中包含子属性，这样做是有效的。对于那些多作者协作的博客，如果他们不希望显示作者名字，目前还没有有效的方案。必须出现在属性中。我可以想象使用CSS方案来取消显示（）可能也是可以接受的。

上面的讨论涉及到另外一个问题：实现hCard时使用。

在第三部分讨论中曾经提到过，为hCard使用元素只有在hCard是文档拥有者时才有效。hCard的FAQ中也强烈建议不要在hCard不是文档拥有者时候使用。因此，如果hAtom的条目由不是文档拥有者创作的话，不是合适的语义元素。

这个问题目前还在讨论中。目前的建议是取消的限制。

子属性也是必需的，他表明条目最后被修改和更新的日期/时间。这里也有需要注意的事情：如果子属性没有被定义，子属性将会用来表明日志更新的日期/时间。在上面的例子中，您会注意到我并没有包含子属性，不过使用了。

是可选的子属性，基本上同的语义是一致的，都是表明条目的更新时间。尽有的区别在于，更倾向于描述条目第一次发布的时间，而可以是发布的时间或者是条目后来更新的时间。如果同时包含和来描述条目的日期时间信息也是有效的：

abbr class="published updated title=2008-08-28T13:14:37-07:00″Aug 28, 2008/abbr

在我的例子中，仅仅使用就符合我的目的了，所以我选择只使用他。

对于和，hAtom推荐使用的时间和日期格式跟我们之前讨论的日期时间设计模式相同：

abbr class=published title=2008-08-28T13:14:37-07:00″Aug 28, 2008/abbr

该模式定义容器元素为，在属性中指定机器可读的日期/时间信息，而在内容中指定人类可读的日期/时间信息。而且，在中包含的时间日期信息应该遵循ISO 8601格式要求。

是可选的子属性。他说明条目的摘要信息。这个子属性可以在中多次使用。在我的博客中，我没有为文章生成这样的摘要，所以我没有提供这个子属性的实现。

是另一个可选的子属性，用来说明条目的全文内容。在上面的例子中，所有的文章内容都被包含在元素中。同样，可以在中使用多次属性。

hAtom还定义了一个属性值来说明条目的永久链接：。在第一部分中，我们讨论了很多基于rel-的微格式，用来表明链接（）和文档之间的关系。rel-bookmark也是用来描述链接关系的，不过不能作为微格式单独使用。必须作为hAtom的属性存在，描述文档内容的永久链接。

使用hAtom，您可以简单的在条目的永久链接上添加：

a href="http://www.ablognotlimited.com/articles/web-accessibility-is-important/" rel=bookmarkWeb Accessibility Is Important/a

您可能会注意到，在我的例子中没有提供永久链接。这是因为我通常遵循一条规则：不在页面中提供本文链接（Nielsen’s #10 of the Ten Most Violated Homepage Design Guidelines）。而且因为rel-bookmark是可选的，所以我的实现是有效的。如果没有指明永久链接，那么就会缺省认为本页链接为条目永久链接。如果中定义了属性，该值会被拼接到URL后面来为条目定义唯一值。

之前我们在第一部分中讨论过rel-tag 微格式。他用来添加到链接（）) 说明网页──或者网页的局部内容──是关于什么内容的。基本来说，通过标签来组织/分类已经在博客中广泛使用。hAtom可以充分发挥rel-tag的作用，只需要在和中做出实现：

在前面的例子中，我在中使用了rel-tag链接：

p class="category"a href="http://www.ablognotlimited.com/articles/category/commentaries/ rel=tagCommentaries/a/p

dda href="http://www.ablognotlimited.com/articles/tag/web+design/ rel=tagweb design/a/dd

注意就是rel-tag规范中要求链接目的地址（）中必须包括标签的值作为URL的最后一段，这被设计为标签空间。

上面已经讨论了hAtom的大部分细节，应该给出一个例子说明如何应用在多日志的页面中。在我的博客上，在首页中添加了hAtom信息，用来描述我最近的三篇日志：

在这个例子中，我使用了多个实例，每一个用来描述一篇日志。并且，我为每一篇日志都指定了永久链接，因为他们并没有指向当前页面。除了上出两个不同之外，hAtom基本上跟我之前的例子是一样的。

除了我上面的两个例子，还有很多可以实现hAtom的页面：

我正在考虑在存档和搜索结果页面中实现hAtom（还包括评论页面，因为那里需要hCard实现）。

在这个系列中提及的微格式中，hAtom是最难的一个。我个人觉得这是因为这个微格式还是一个提案状态的规范。不过，我遇到的实现困难还都是很小的，不过也有点小挫败：

所以，从个人角度，我认为毕竟他还处于提案状态，还需要被修改和讨论。但我并不认为就不去实现hAtom，最起码也可以先熟悉熟悉他。只要注意他还在提案状态就可以了。

虽然前面提过现在支持hAtom的工具和资源还很少，我们还是可以列举一些：

尽管hAtom是提案规范，但是还是有很多服务提供支持：

还有更多实际的hAtom支持。

我想hAtom最酷的一个好处就是他为XHTML广播带来的潜力。在工具和资源列表中，我提到了几个转换器，他们利用XSLT把带有hAtom的XHTML转换为XML，从而提供Atom或者RSS的源。这意味着不需要再为了广播去生成或者维护单独的Atom或者RSS的XML文件。简单的利用hAtom和这些转换器就可以完成广播XML的自动生成。

自己试试吧。需要做的仅仅是在包含hAtom信息的URL前面拼接这些转换器（http://transformr.co.uk/hatom/）：

a href="http://transformr.co.uk/hatom/http://www.ablognotlimited.com/Atom feed for A Blog Not Limited/a

产生的链接会自动生成Atom格式的XML：

我还没有为我的站点实现这个转换，因为我使用自定义的RSS源。不过这些转换器绝对在我的实验列表中。

您不会认为我忘了这点吧？

借助于已有的标准（XHTML元素和属性），微格式为网络内容添加结构和语义。语义能够同时帮助人类和机器来处理、搜索和理解互联网。微格式鼓励您使用互联网标准标记内容的标准化方法，应用class信息，还包括开发的正确流程。

语义很棒。标准很棒。微格式很棒。

译注：Syndication翻译为广播不知道合适不合适，以前一直提RSS，但是还真从来没想过或者查过如何翻译合适。