Re: URC spec

Thus spoke Michael Mealling:   (at least on Jun 13 at  9:36am)

> Michael Shapiro said this:
> >    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.
> 
> But you will also notice that Ron has several different types of 
> URC syntax. In this case we could just as easily state a reverseal
> of the above: Anything that is returned during the resolution of
> a URN can be considered a URC. 
> 
> A URL all by itself is just a very small URC. A null string is
> just a null URC.
> 
> Its just semantics....

Michael Mealling's response was pretty much along the lines of my thinking.
If a list of URLs were returned, that would be just one form of URC. Lots
of things could be returned and considered a URC. 

Michael Shapiro's comment seems to be that we should allow the URN to
resolve directly to the named resource, without an intermediate step
of the URC. This is where we have a fundamental disagreement. I think
that resolving a string to a resource is the role of the URL. URNs
are supposed to isolate us a bit from the resource so that we can
easily move it around, etc. I certainly think we should insulate the
user from this extra step, but I think that the user's agent has to
see it in order for us to achieve the goals of URNs.

Anyone else on the list care to voice their opinon on this point?


-- 
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:57:11 UTC