From: "Ronald E. Daniel" <rdaniel@acl.lanl.gov>
Message-Id: <9404010949.ZM13579@idaknow.acl.lanl.gov>
Date: Fri, 1 Apr 1994 09:49:02 -0700
In-Reply-To: ccoprmm@oit.gatech.edu (Michael Mealling)
To: ccoprmm@oit.gatech.edu, uri@bunyip.com
Subject: Re: A modest suggestion for the URN->URL service
On Apr 1, 11:16am, Michael Mealling wrote:
> Subject: Re: A modest suggestion for the URN->URL service
> Ronald E. Daniel said this:
[...]
> > Here is my modest suggestion. We
> > extend the structure of a URN from
> > <URN:opaque_string>
> > to
> > <URN:method[(arg_list)]:opaque_string>
> >
> > and define a set of methods.
> >
>
> Doesn't that breaks everything a URN is meant to be? How can
> I compare one URN string to another and find out whether I have
> equality?
The comparison would be done on the opaque string, not on the wrapper and
method specifier.
> A URN is meant to be an identifier, not a complete object in
> the OOP sense. Those functions operate ON URNs therefore you can't include
> the function in what it's operating on (can you?).
I am not an OOP maven, but when you say things in C++ like foo.method(args)
you are specifying the function and arguments, as well as the particular
object the operation is being applied to.
Another way to view it might be to look at the URN service as a global
distributed object, the opaque string selects which URN inside the object
to apply a particular operation to. Whatever.
> I think most of us who are thinking of URCs envision some
> type of view limitation function so that a client can specify limitations
> on it's requests. For example, I see very limited clients like gopher
> using gateways that only request URCs with URL and URN fields. Here's
> an example:
>
> client has URN1
> it connects to whois++.int and says:
> "Give me the record for URN1 but only give me fields that start with
> URL: and URN: and limit the results to 50 hits and restrict the search
> to URLs in the continental U.S." (forgive me for not being able to
> construct the full whois++ query here!)
> Then the client gets back about 5 URLs mapped to one URN that is written
> up in a 6 line URC.
Sounds OK to me. You are going to have to have some means of constructing this
query, specifying the URN of interest, etc. I proposed a particular method.
Also, the method I suggested is sessionless, which is an aspect of HTTP that
I like and would like to see brought into the URN service.
I will take a more detailed look at the whois++ stuff to see about how
it works and how we specify view limitations, etc. I have no problem
with the portions of URCs being returned to clients coming in as
templates.
> I do agree that we have not focused very much on the functions that we
> plan on using all these things for but I think that is due to the fact
> that there are so many functions that one can do. It's kind of like
> designing numbers with the intention of one day getting around to
> trying to write down all the functions that you plan on using them for.
> I do think we need to sit down and write down that we plan on using
> these things to do basic functions akin to add,subtract,multiply and
> divide. Comments? Flames?
That is the main purpose of my message, to get some discussion on the
various uses of URNs. I think that there are certain fundamental operations
that have to be provided - publish a new URN, register or unregister
a URL for a particular URN, create a new publishing authority, handle the
expiry of a publishing authority, etc. Mapping a URN to a URL is, of course,
one of those fundamental operations.
I will take another, more extensive, look through the whois++ stuff
to see how my stuff can be mapped into it.
-- Ron Daniel Jr. email: rdaniel@acl.lanl.gov Advanced Computing Lab voice: (505) 665-7453 MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939 Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/Home.html Los Alamos, NM, 87545 tautology: "Conformity is very popular"