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

On 15-March-2005, the OASIS XRI TC released some documents for
public review...
  http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri

... and the TAG started looking at them on 22 March...
http://www.w3.org/2005/03/22-tagmem-minutes.html

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
therefore
 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.

  http://department.agency.example.org/docs/govdoc.pdf

moves to

  http://newdept.agency.example.org/docs/govdoc.pdf

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

  http://govlib.example/2005/govdoc

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...

  http://9990.xri.com/2005/A58F!1C3D/!2495


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).


[XRI]
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

[DLL]
The Path URN Specification
Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Fri, 17 Mar 1995 16:58:25 -0600
http://lists.w3.org/Archives/Public/uri/1995Mar/0027.html


-- 
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