级别： 中级 Uche Ogbuji (uche@ogbuji.net), 首席顾问, Fourthought Inc.
2007 年 6 月 11 日 您可能听说过微格式，它是一种在标准格式中嵌入小容量的、专业的信息的方法。事实上，微格式分为两种类型：基本微格式（经常相当有用）和复合微格式（经常会造成一些问题）。本文向大家介绍了一种依靠 Web 结构避免一些复合微格式中存在的程序问题的基本方法。XML 和一些其他的自然数据表示技术，如 JSON，在微格式中也同样可以使用。
微格式 的概念最初出现于二十年前，那时它是一种把丰富语义嵌入主格式（如 HTML/XHTML 和 Atom）的方法。HTML 无法直接表示联系人信息，但是一种叫做 hCard 的微格式允许我们把 HTML 中平常的 divs 和 spans 转换成结构体，用以指定联系人姓名、街道地址、邮政编码等信息。微格式内部的一些基本思想是相当合理的，不过它的作用被大肆夸大了，以致于人们有些时侯不会去考虑微格式的适用范围和适用缘由。微格式应该成为一个可用于在 Web 上表示丰富内容的工具，并且应该补充（而不是替代）一些其他的此类技术，例如 Web 上的 XML 甚至 Ajax。这篇文章旨在介绍微格式的适用范围，以及一些值得重点注意的地方。
细微差别和害处
微格式最擅于在某个主体语言（如 HTML、XHTML 或 Atom）中对一些通常的结构加入少量细微的差别。rel-license 就是一个例子，它允许我们表示出一个链接，并且通过这个链接能识别出源页面内容的用法许可。链接 <a href="http://creativecommons.org/licenses/by/2.0/" rel="license">cc by 2.0</a> 不论位于页面何处都意味着页面的内容在 Creative Commons 2.0 Attribution Required 许可下可用。
我曾经看到有人滥用过这种微格式，他们为某个页面所描述的软件（而不是为页面本身）声明了一个许可，但是我们并不能为此就去真的责备微格式的开发人员。
还有一点更突出的问题，就是此类约定有可能会产生冲突，不过对于大部分情况，微格式都会忽略此类问题，它期望轻量级协议能在问题刚出现的时候就及时地解决它们。
像 rel-license 这样的微格式对一个 HTML 属性的用法提供了约定，该属性用于支持这种约定。其约定不过是在主体语言词汇的此类结构中提供了一些细微的差别，我把这种微格式称为具有细微差别的微格式（nuance microformats）。其中大部分是微格式开发人员所称的基本微格式（elemental microformats），基本微格式就是完全在某个元素内部构造而成的微格式。
一些微格式试图把专有的结构嵌入到主体语言的结构中去。我把这些微格式称作有害的微格式（nuance microformats）是因为它们在一些方面是相当有害的，不过在这篇文章中我将会使用微格式开发人员所采用的一种比较中立的术语：复合微格式（compound microformats）。
XOXO 就是一个很好的例子，它是一种用于表示概要的微格式。您可能会设计一些 XML 来替代 XOXO，因为 XOXO 要远比这些 XML 难于理解和处理。当然，XML 是设计用于表示复杂的和专有的内容结构的，而且它似乎倒退了一步，使用表现力更弱的结构却只是为了在 HTML 中嵌入这些结构。微格式开发者这样做的原因是他们感到 XML 太复杂了，而且还不够普及，更重要的是 XML 并不允许适度的降级，这意味着微格式对不懂 XML 之类比较高级的技术的用户代理来说就像是常规的 HTML。这是相当站不住脚的说法，其部分原因是现在大部分的用户代理都可以支持 XML，还有一部分原因是有的时候一个可伸缩的 Web 设计是值得这样的代价和麻烦的。尽管那时一些其他的 RSS 语言已经普及，但是后来还是开发了 Atom，一种更佳的 Web 提要格式。尽管对于懒惰的 Web 发行人员来说，使用 font 和 center 标记会更加地轻松和方便，甚至尝试应用 CSS 的 Web 开发人员在开发过程中遭遇了浏览器所带来的困难和阻碍，但是他们还是开发出了层叠样式表（Cascading Stylesheets，CSS）用于将 Web 页面中的内容和表示分离开来，尽管留下了很重的负担，但是这两种技术都表现良好，而遗留问题不过是糟糕的微格式设计的可怜借口。
不要忘记了超文本
Web 日志是微格式的一个热点用例。其想法是作者使用 hAtom 标出条目，使用 XOXO 实现 blogroll，使用 rel-license 指定许可，并使用 hCard 内联联系人信息，等等。微格式提供了一种更简单的方式，即通过更新 Weblog 引擎模板在经过改变少量结构的表单中发布所有这些数据。同时，适度的降级功能也使得 Weblog 受益不少，因此即便读者没有支持微格式的软件，他们也仍然能够直接阅读这些信息。
这些听上去都很合理，但是它也可能忽略 Web 的基本价值。HTML 支持把普通的文字组织到页面中。我们使用链接把页面连接在一起。使用到一些对象（如图像、样式表之类的）的链接表示特殊的数据。如今这种方式运行地很好。我们没有什么理由不表示地址簿，Web 提要及类似的数据，这些可以通过链接到 XML 文档来完成。XML 支持半结构化的数据。有时，XML 并不是最合适的数据格式。对于高度结构化的数据，JavaScript 对象表示法也许（JavaScript Object Notation，JSON）是更好的选择。无论如何，上述每一项技术对于其擅长的领域都易于使用，并且仍然能够对 Web 浏览器、甚至移动浏览器技术保持最大的兼容性。
我准备先从 hAtom 开始介绍，因为很明显它在 Atom 中可以使用 XML 替代方案。其中已经有了一个 XML 形式的 Atom。它得到了健康的发展和支持。甚至约定了从常规 Web 页面到 Atom 提要的链接：
<link rel="alternate" type="application/atom+xml" title="BobSutor's blog feed"
href="/developerworks/blogs/rss/BobSutor?flavor=atomdw" />
|
添加这种提要链接比起在 hAtom 中的各种循环中来回跳转要简单得多。任何有可能对 hAtom 提供支持的 Weblog 软件甚至更有可能支持纯 Atom。大多数搜索引擎都为有链接的 Atom 文件编制了索引，就和页面本身编制索引一样乐此不疲。搜索引擎软件能通过 Web 提要链接约定（自身内部的一种微格式）知道如何解释链接的 Atom 文件。并且对于那些文字 Web 工具和服务，Atom 比 hAtom 更易于解析和处理。我们能获得更多严格的 XML 语法并且无需使用一个含两个语义层的堆栈就可以使用 hAtom。尽管事实上比起有细微差别的微格式来说更像是有害的微格式，但是正确的 XML Atom 还是有优势的。
样板文件还是内联内容？
我们继续学习 XOXO 例子中 Weblog（aka "blogroll"）相关的列表，本例中的 XML 标准并不像 Atom 中那么显而易见。把 XOXO 插入 Weblog 是相当容易的事情，因为 blogroll 通常并不是条目内联内容的构成部分，而是整体 Weblog 模板样板文件的一部分。清单 1 是 XOXO Blogroll 的一个例子：
清单 1. XOXO blogroll 的例子
<ol class="xoxo">
<li>
<p>My favorite Weblogs</p>
<ol>
<li>
<a href="http://example.com/bud/" type="text/html">Buddy blog</a>
<a href="http://example.com/bud/atom" type="application/atom+xml">Buddy feed</a>
<dl>
<dt>description</dt>
<dd>My buddy's Weblog</dd>
</dl>
</li>
</ol>
</li>
</ol>
|
真的，我无法用其他方法来演示 — 这太可怕了。十个元素所完成的任务对于任何合理的 XML 格式来说只需四个或五个元素就够了（无格式的 HTML 中也只需六个元素）。清单 1 是 XOXO 的一个简化的例子。我曾经见过很多更复杂的例子。此处的问题是在滥用 HTML 表示 blogroll 的语义的过程中，XOXO 引入了复杂性并增加了出错的风险。并且难以测量收获。某个作者可能会使用清单 2 中的示例样板文件来表示 blogroll：
清单 2. 无格式的 HTML blogroll 例子
<div class="blogroll">
<h3>My favorite Weblogs</h3>
<ol>
<li>
<a href="http://example.com/bud/" type="text/html">Buddy blog</a>
(<a href="http://example.com/bud/atom"
type="application/atom+xml">Buddy feed</a>): My buddy's Weblog
</li>
</div>
|
这非常易于效仿，并且不会造成混淆或者错误。
即使用 JSON 也能完成任务
相对于 XOXO（清单 1）来说，无格式 HTML 例子（清单 2）的一个不足之处就是 blogroll 的结构不适合机器阅读。要解决这个问题，需要提供一个到结构化的 blogroll 数据的链接，它毕竟只是一个链接的集合。该数据是高度结构化的，并且服从除 XML 之外的一切数据格式，包括 JSON。清单 3 是 JSON Blogroll 的一个例子：
清单 3. JSON blogroll 数据的例子
[
{"blog": "http://example.com/bud/",
"feed": "http://example.com/bud/atom",
"description": "My buddy's Weblog",
"tags": ["buddy"]
}
]
|
我们可以把它保存为一个简单的文件并使之可用，并使用 Ajax 脚本技术通过前面的链接列表动态地构建 清单 2 中的无格式的 HTML blogroll。要处理适度降级的问题，应选择理解良好的技术用于可行的 Ajax 设计，IBM developerWork 网站上对其中的很多技术进行了讨论。
结束语
微格式宣称拥有的社区应该在微格式日行渐远的时候向大家发出警告。Weblog 软件是基于 Web 改进的一个令人惊异的引擎，它不断地引入一些思想和技术，这些努力应该能消除复合微格式的一些比较恶劣的有害特性。并且当它们生成这些改进时，我们通常都不必选择查看源代码来效仿它们。Weblog 开发人员经常会发表采用其技术的详细说明。毫无疑问，有细微差别的微格式是很实用的，构建它时考虑了有关开发的大致共识和现有的运行代码。它们与 MIME 类型、文件名扩展等文件的正式注册相似，不过在中心控制方面有所不如。当微格式的作者开始误用主格式而不是基于它进行构建时，一些问题就是随之而来了。在这类情况中使用使合适的格式会好很多，而且 Web 中到处都是有用的方法足以为我们提供健康的选择。
参考资料 学习
获得产品和技术
讨论
关于作者  | 
| | Uche Ogbuji 是 Fourthought Inc. 的顾问和合伙创始人，该公司是专门为企业知识管理应用提供 XML 解决方案的软件提供商和顾问。Fourthought 开发了 4Suite，一个 XML、RDF 以及知识管理应用程序的开放源码平台。Ogbuji 先生还担任 Versa RDF 查询语言的首席开发人员。他是一名出生于尼日利亚的计算机工程师和作家，生活和工作在美国科罗拉多州的博耳德。想要了解更多，可访问 Ogbuji 先生的博客 Copia 或者通过电子邮件 uche@ogbuji.net 与他联系。 |
对本文的评价
| 
