RE: resources and URIs

Yes.  The hash mark is a trip wire to invoke a 
different system, the content type handler. 
We did too many rounds on this design issue 
in Hytime for me to see it any other way. 
Esentially, at the point at which the network 
system has retrieved a content object of some 
type, the handler for that type must then 
recognize the address/location type handed 
to it and resolve it.  It can be a named location, 
a path location, a byte offset, pick your 
own poison, but at the # mark, the local handler 
takes over and uses its local and possibly 
opaque implementation to process an identifier 
which is itself, standard and/or a public type. 

Even if the # (octothorpe) indicates an abstraction, 
the handler for documents of type(abstraction) takes 
over.  In this sense, what is at the hash mark is a
different kind of information than what precedes it
and is type dependant.  It can only identify what a 
handler for it's type in the context of the thing to 
be identified can return or emit.

len


From: Norman Walsh [mailto:Norman.Walsh@Sun.COM]

/ "Bullard, Claude L (Len)" <clbullar@ingr.com> was heard to say:
| Nicely vague but operationally meaningless and that is 
| what a lot of people are having problems with.  Saying 
| a resource is the side of the bus that the URI is printed 
| on plus anything else printed there, or that a Ford Galaxy 
| or a Ford Falcon are resources 'on the web' makes the 
| web equal to the knowable universe.
|
| That buys us exactly nothing at the cost of Boltzman entropy.

Fair enough, but I don't see how to avoid it. I just don't see how
adding a hash makes the slightest real difference. It makes some
specification difference, perhaps, but we're still left with a
multiverse of URIs that can identify anything.

Len, do you think that grounding http://www.example.org/foo in some
way while leaving http://www.example.or/bar#foo ungrounded really
makes things more meaningful operationally?

Received on Monday, 28 July 2003 15:31:40 UTC