RE: [xri] Fwd: for names consisting of an adiminstrative hierarchy and a

Subject: RE: [xri] Fwd: for names consisting of an adiminstrative hierarchy and a path, HTTP/DNS is as good as it gets

---------- Forwarded Message ----------

Subject: for names consisting of an adiminstrative hierarchy and a path,
HTTP/DNS is as good as it gets
Date: Tuesday 19 April 2005 07:34 pm
From: Dan Connolly <connolly@w3.org>
To: www-tag@w3.org

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

-------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xri message