XRI versus URI?
The purpose of this TC is to define a URI-compatible identifier scheme and resolution protocol for abstract structured identifiers, i.e., identifiers that are location-, application-, and transport-independent, and thus can be shared across any number of domains and directories. The TC is also defining an extension of the generic resolution protocol for trusted resolution, and a special set of identifiers for XRI metadata (identifiers that describe other identifiers).The complete lack of W3C participation is also troubling. The view of some W3C people on XRI is a matter of public record. For instance, Tim Berners-Lee said:
[I am] convinced XRIs are a bad ideaAlthough there have been a number of releases of the specifications involved in XRI definition, it has not been until recently that the W3C have really taken significant interest and voiced their concerns more widely. This started in 2005, where the W3C TAG responded to the XRI committee on the need for a new URI scheme:
The TAG has reviewed the XRI 2.0 documents and requirements surrounding the use of XRI. At this time, it is the opinion of the TAG that the case has not been made for a new URI scheme, rather that the requirements can be addressed very well using the http URI scheme and existing implementations of HTTP and DNS.However, this did not dissuade the XRI committee, who have now progressed to a 2.0 version of the standard. For this attempt, the W3C asked a number of questions of the XRI Technical Committee:
We would very much appreciate it if you could clarify whether we have read the XRI Resolution specification correctly in inferring that:These were answered by the technical committee, but it is clear from the W3Cs latest email to the committee that the TAG is still not convinced of the need.
1) All access to resources identified by XRIs
require (at least) two round trips, the
first to retrieve metadata (XRDS, XRD or
uri list) and the second to retrieve
(a representation of) the resource itself?
2) HTTP content negotiation can be used in
requests for XRIs to force either metadata
return or redirection to actual resource
3) Relative XRIs are of course allowed in the
normal way when a full-form XRI has been
established as the base URI. Are they also
allowed _without_ any full-form XRI as a
base URI? That is, for example, is "=henry"
intended to be recognize as an XRI in the
absence of any base URI? If so, what is
being done to ensure that both now and in
the future, the syntax of such abbreviated
XRIs is coordinated with (I.e. remains
disjoint from) the syntax of both absolute
and relative URIs that might be used in the
Also, could you let us know what steps, if any, you have taken towards registration of 'xri' as a URI scheme with the IETF?
In The Architecture of the World Wide Web the TAG sets out the reasons why http: URIs are the foundation of the value proposition for the Web, and should be used for naming on the Web. The TAG has reviewed XRIs twice, once in a previous draft and more recently the XRI Resolution draft and on both occasions we raised a number of questions with the OASIS XRI TC.Although there is some wider interest in XRI, it has to be asked what future there can be for a Web-based scheme that does not have the full endorsement of the W3C (or any major Web vendors). Back in 2003, one author suggested that XRI was needed for XML and Web Services. At the time Justin Taylor, chief strategist for directory services at Novell, said:
The TAG's work in this area is ongoing. For further information see
We are not satisfied that XRIs provide functionality not readily available from http: URIs. Accordingly the TAG recommends against taking the XRI specifications forward, or supporting the use of XRIs as identifiers in other specifications.
Tim Berners-Lee and Stuart Williams, co-chairs, W3C Technical Architecture Group
XRI is about creating a common URI for how we will refer to distributed information, whether it's objects in a directory service [such as user objects], or dealing with files in different servers or with different types of documents that might be in different systems.We seem to be doing well without XRI. Is this a solution looking for a problem? If the standard is adopted will it cause yet more contention? Or will it disappear into oblivion if none of the major vendors implement it?
Doc List Oct 25, 2014