W3C home > Mailing lists > Public > uri@w3.org > June 1995

Re: URC spec

From: Ron Daniel Jr. <rdaniel@acl.lanl.gov>
Date: Tue, 13 Jun 1995 09:24:40 -0600
Message-Id: <9506130924.ZM1832538@macrdan.acl.lanl.gov>
To: mshapiro@ncsa.uiuc.edu (Michael Shapiro), uri@bunyip.com
Hi Michael,

Thanks for the comment on the draft URC spec.

>    There  is  an  implied  assumption  in  the   SGML-based   URC
> specifiction  that  URNs  resolve to URCs. I think that this is a
> fundamental mistake.  URNs should not be required to  resolve  to
> URCs. They should be allowed to resolve to any resource.

I am going to add some stuff to the trivial query language section
that steals from the OCLC URN proposal. I will add the N2L, N2C, N2N,
L2C, C2C queries so that a name, location, or characteristic can be
resolved into a name, location, or characteristic. Note that I am not
adding the ability for a name to resolve directly to the resource.
I am very hesitant to do such a thing. My take on the URC service is that
it provides the level of indirection between the name and the resource
that makes it possible to easily move resources, supply multiple copies,
etc. Note that this does not mean that the user has to see the URC.
For example, if N2L was requested, I will say that the response should
come back as an HTTP Location: header (or whatever the new approach
is) so that the client will immediately fetch the resource without
the user noticing what is going on.

>    In section 3 "Attribute Sets", the specification states
>      "A ... complication arises as a result of using  a  URN  for
>      the AID .... We resolve AID-1, which is a URN, and ge back a
>      URC (URC-2) ....  What is the AID in URC-2? How do we  avoid
>      infinite regress?"
>    The proposed solution is to convert the  AID  from  a  URN  to
> something which is not a URN, but has all the properties of a URN
> in that it is a persistent name for a resource that  happens  not
> to be a URC.
>    This  infinite  regression  could  also  be  solved   if   the
> requirement  that  all  URNs resolve to URCs be relaxed. Here, it
> seems to me, is a perfect example of the need  for  a  URN  which
> does NOT resolve to a URC.

In my draft spec, the AID can be a URN, or the reserved string "root".
This is, admittedly, somewhat of a hack. However, I am very hesitant
to allow the URN to return just anything. The whole point of the URN
was to get away from the problems we have with URLs by providing the
level of indirection. I can't forsee what all the consequences of
resolving directly to a resource are, but it has a warning bell going
off in my head.

Ron Daniel Jr.                     email: rdaniel@lanl.gov    
Advanced Computing Lab             voice: (505) 665 0597
MS B287                              fax: (505) 665 4939
Los Alamos National Laboratory      http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM  87545          tautology:"Conformity is very popular"
Received on Tuesday, 13 June 1995 11:19:45 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:30 UTC