- From: <Patrick.Stickler@nokia.com>
- Date: Fri, 16 Nov 2001 16:40:55 +0200
- To: sean@mysterylights.com
- Cc: www-talk@w3.org, uri@w3.org
> -----Original Message----- > From: ext Sean B. Palmer [mailto:sean@mysterylights.com] > Sent: 15 November, 2001 17:55 > To: Stickler Patrick (NRC/Tampere) > Cc: www-talk@w3.org; uri@w3.org > Subject: Re: What is at the end of the namespace? > > > > Assertion 1: Mammals may have either no legs, two legs > > or four legs. > > Assertion 2: Dogs may have either no legs, two legs or > > four legs, because mammals may have either no > > legs, two legs or four legs. > > > > and totally misses the fact that > > > > Assertion 3: Dogs have four legs. > > Close, but no cigar. For a start, your comparison this time assumes > that subsets of URIs (URIs with a certain scheme) must have a set > number of legs... er, i.e. they necessarily denote a non-equivalent > subset of the whole set of resources that URIs can denote. If that > were true, it would be pointless to continue with a "tag:" or > "urn:pts:" style scheme/NID, because those are meant to be able to > denote anything. No. You missed my point. You seem to be arguing that a specific URI scheme can not *itself* constrain its use to a subset of URI applications, and I'm arguing that it can, and that the HTTP URI specification *does*. > Nothwithstanding that, you're still really missing what I'm saying. > I'll lay the facts out sequentially, so that you can just stop me > where I'm wrong:- > > * The URI specification says that the definition of a resource is > "anything which has identity" > * When creating a new scheme, it is possible to come up with one which > can denote "anything which has identity" > * Unless a scheme's documentation says that those URIs necessarily > denote a subset of resources, they don't > > That's it. I don't disagree with any of the above. But I assert that the HTTP URI scheme *does* define such a subset in the language of the specification and inherited from the semantics and purpose of the HTTP protocol. > This is turning into a bizarre argument, because in the > words of a man whom I greatly admire:- > > [[[ > I feel like I've been in the Twilight Zone where every word I use no > longer holds its meaning and every time I write "green" folks read > "blue", and the frustration has been significant. > ]]] ;-) > All I want you to do is point me to a bit of verbiage in an RFC which > says "thou shalt use HTTP URIs to identify chunks of data only", and > I'll go "fair enough, I accept that now". See my recent response to Roy, repeated here: --- > > > The HTTP > > specification > > can only talk about those aspects of the protocol that are relevant to > > HTTP. > > You've just summed up, IMO, the whole issue in a nutshell. The > HTTP URI is relevant only to the semantics of the HTTP protocol. > And the HTTP protocol is for *access* of concrete web resources. > Thus HTTP URIs are only intended to be meaningful to processes > based on the HTTP protocol, which expect to *return* something. > Therefore HTTP URIs are not intended to denote abstract concepts. --- I think that sums it up. I can go and cut and paste stuff from the RFC's if you like, but not just now... gotta run and fetch the kids... > [...] > > They are using them, because that's *all* there is to use. > > > > Show me one, single, solitary URI scheme provided or > > promoted by either the IETF or W3C for denoting abstract > > concepts *only*. > > Register an informal NID. It takes two, maybe three weeks to do so, > and then you have a set of persistent identifers forever. The > registration process could not be all that simpler, and you get to > decide what they denote. That's only good if (a) you are registering a URN namespace, and (b) your namespace is not a hierarchical path based URI Nope. I'll be going the full URI route. > But we're pressing through "tag:" as such a URI scheme, and it's quite > far down the recommendation track. Great. I may ask you for a roadmap ;-) > We'll just have to be patient, and > I know that it's very difficult... but we don't have much of a choice. In that we are agreed. Cheers, Patrick
Received on Friday, 16 November 2001 09:41:50 UTC