W3C home > Mailing lists > Public > www-tag@w3.org > April 2005

for names consisting of an adiminstrative hierarchy and a path, HTTP/DNS is as good as it gets

From: Dan Connolly <connolly@w3.org>
Date: Tue, 19 Apr 2005 18:34:40 -0500
To: www-tag@w3.org
Message-Id: <1113953681.3004.101.camel@localhost>

On 15-March-2005, the OASIS XRI TC released some documents for
public review...

... and the TAG started looking at them on 22 March...

Not having read the XRI docs (because of patent concerns), today I
suggested the following line of argument:

 1. XRIs follow the pattern of an administrative hierarchy
    followed by a path
 2. http/DNS handles the case of an administrative hierarchy
    followed by a path, and is ubiquitously deployed
 3. A specification SHOULD reuse an existing URI scheme
   (rather than create a new one) when it provides the
   desired properties of identifiers and their relation
   to resources.
   -- http://www.w3.org/TR/webarch/#pr-reuse-uri-schemes
 4. The XRI work should use http/DNS; the xri: scheme
    should not be introduced.

Point 2 seems to merit elaboration. So I'm taking a look
at the docs now...

In [XRI] section 3. How XRIs Help Solve These Problems, subsection
3.1 Persistent Identification, we see the familiar story
of a link breaking because a department gets renamed.


moves to


Then, it says, "A much better solution would be to assign the
resource ´govdoc.pdf¡ an identifier that never needs to change or
be reassigned." Quite! Absolutely! Cool URIs don't change[TBL].

[XRI] continues... "This can be accomplished using a fully
persistent XRI such as the following: xri://@!9990!A58F!1C3D/!2495 "

Well, now if the govdoc publisher had the foresight to
consider the possibility that the govdoc resource might
outlive the agency or its name, they could have used
a nice sturdy http/DNS URI in the first place, ala


That's assuming the government prefers to take responsibility
for long-term publishing of documents itself. Of course, this
could be outsourced to xri.com , who might issue the name...


and then resolution can happen by way of HTTP (or https) redirects,
analagous to the way XRI resolution is described.

The point is
  * yes, it's useful to assign a persistent name in the
    first place, in case a resource outlives its original
    publisher, but

  * there's no reason not to use http/DNS to do this

When I started to read the next section, 3.2 Federated Identification, 
I thought maybe XRIs had made the split-point between the administrative
hierarchy and the path invisible at the syntax level, ala the
long-discussed path: scheme[DLL]. But it says,
"Once we have reached the public XRI authority
@example.org*agency*department, it can switch to internal delegation"
which is nothing tricky at all; it's just like the
apache InternaRedirect mechanism (and analagous mechanisms in
other HTTP server architectures).

http://www.oasis-open.org/apps/group_public/download.php/11857/xri-intro-V2.0-wd-04.pdf ...
which bears the "Location" http://docs.oasis-open.org/xri/xri/V2.0
which, by supreme irony, is 404

[TBL] http://www.w3.org/Provider/Style/URI

The Path URN Specification
Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Fri, 17 Mar 1995 16:58:25 -0600

Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Tuesday, 19 April 2005 23:34:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:45 UTC