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

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

Right. Gabe and I discussed 
this this afternoon. You can also see the related discussion at http://lists.w3.org/Archives/Public/www-tag/2005Apr/0075.html.

 

I have to assume this is just the beginning 
of their comments, otherwise they kind of missed the point.

 

Dave

From: Peter C Davis 
[mailto:]
Sent: Tue 4/19/2005 6:28 
PM
To: 
Subject: [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 <>
To: 


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