XSI对决URI?

作者 Mark Little译者 黄璜 发布于 2008年5月26日 下午10时12分

社区

SOA

主题

Web服务标准

标签

W3C

OASIS的扩展资源标识符（Extensible Resource Identifier）小组成立了好几年了。它的成员有Boeing和Booz Allen Hamilton，但你平常所期待的那些对Web的重量级的设想都不会像这个这么重要：

本TC的任务是为抽象结构的标识符定义一个与URI兼容的标识符模式以及解析协议，例如，这种标识符是独立于位置，应用，或者传输的，因此可以在跨任意的域和目录进行共享。本TC还在通用的解析协议之上为信任的解析定义了扩展，并为XRI元数据（用于描述标识符的标识符）定义了特殊的标识符集合。

完全缺少W3C的参与同样也是一个麻烦。W3C的一些人对XRI的看法是把它当成一种公共记录。比如说，Tim Berners-Lee说道:

[我]完全相信XRIs不是个好主意

尽管针对XRI的定义已经发布了一定数量的规范，但直到最近W3C才开始真正关注并广泛地表达他们的意见。这开始于2005年，W3C TAG就XRI委员会所提出的对新的URI模式的需求作出了回应：

TAG已经审阅了XRI 2.0的文档以及应用XRI的相关需求。在目前这个时候，TAG一致认为这些例子还不足以论证一种新的URI模式，相反，这些需求用现有的http URI模式以及现有的HTTP和DNS的实现就处理得相当好了。

然而，这并没有打消XRI委员会的念头，他们现在正朝着这个标准的第二版在努力。对于他们的这种尝试，W3C向XRI委员会提出了一系列的问题：

我们作出以下的这些推断是否是正确地理解了XRI解析规范，望你们能予以说明。我们将不甚感激：

1)所有要获取被XRI所标识的资源的方法都需要（最少）进行两轮，第一轮是取回元数据（XRDS，XRD 或uri list），第二轮才是取回资源（的一个表述）本身？

2)在请求XRI的时候，HTTP内容协商被用于强制元数据的返回或是重定向到一个资源的表述？

3)在建立了完整形式的XRI并将其作为基本URI的时候，当然允许作为普通形式相对的XRIs。在没有作为基本URI的完整XRI的时候，它们也同样是被允许的吗？比如说"=henry"在没有任何基本URI的情况下能够被理解成一个XRI吗？如果是这样的话，如何来保证在现在和将来，这样缩略语法的XRI能够与上下文中可能同时出现的绝对的和相对的URIs进行协调呢？（比如，保持它们是不相交的）

同时，能告诉我们，你们将打算采取什么样的步骤（如果有的话），来向IETF将‘xri’注册为一个URI模式呢？

该技术委员会回答了这些问题，但W3C最新的邮件表明，他们仍然觉得这一需求并不能让他们信服。

在The Architecture of the World Wide Web里TAG说明了为什么http:URIs是Web价值主张的基础并应该被用来在Web上命名的原由。TAG已经审阅了XRI两次，一次是之前的草稿以及最近的XRI Resolution draft，在这两个场合我们都对OASIS XRI技术委员会提出了一系列的问题。

TAG在这个领域的工作仍在进行中，更多的信息请参考ISSUE-50: URNsAndRegistries。

XRI所提供的功能并未超出现有的http:URIs的范围，对此我们并不满意。因而TAG建议停止此项规范的发展，或者在其它的规范里包括对使用XRI的支持。

Tim Berners-Lee和Stuart Williams, 联合主席, W3C 技术架构小组

尽管有一些对XRI更广泛的兴趣，我们仍不禁要问，对于一个基于Web的模式，缺少了W3C的认可（或者任何主流Web供应商的支持），它的未来会是什么样子呢？2003年的时候一位作者建议XML和Web服务需要XRI。当时Novell目录服务的首席战略师Justin Taylor这样说道：

XRI打算为我们如何引用分布式信息创建一个统一的URI，不管它是目录服务里面的对象[比如用户对象]，或者不同的服务器之间处理的文件，还是各种系统之间的各种不同类型的文件。

现在看起来没有XRI我们一样做得很好。是先有了解决方案再反过来寻找要解决的问题吗？如果这个标准被采纳会招致更多的争论吗？还是它会由于缺少主流厂商的实现而渐渐走向遗忘？

查看英文原文：XSI versus URI?

---

译者简介：黄璜，2007毕业于重庆邮电大学计算机学院。现从事Java Web开发，供职于成都ISSC,熟悉Struts,Spring,ibatis，关注语义网，SOA，云计算等领域。个人主页：http://www.chinacomputing.org， 联系方式huangh@cn.ibm.com。参与InfoQ中文站内容建设，请邮件至china-editorial@infoq.com。

• 更早的 >