Re: now://example.org/car (was lack of consensus on httpRange-14)

You do not need to feel like you need to respond to this as the topic 
has been overcooked. But I thought I had the answers to your questions 
so I gave it one more shot.

David Orchard wrote:
>
>...
> 
> But it's truly time to stick a fork into this debate.  I just don't get it.
> I do think we are awfully close in position, believe it or not.  However, to
> finish and simply for the record, my central misunderstanding is why an
> author shouldn't use a non-deferenceable scheme for URIs when their intent
> is the URI is non-dereferencable, and use dereferenceable schemes when the
> intent is dereferencing, particularly if the author may change the intent of
> the URI.   Because it seems to me the author wants the client/client software
> to now do something (like deref) different when they now provide
> representations, and changing the identifier is a great way to indicate that
> intention. 

You know how a big part of the XML philosophy is that the receiver of 
the information decides what to do with it, not the producer? The same 
goes for URIs.

The person working WITH the URI decides whether to use it as a locator 
or an identifier, not the person creating the URI. The same bit of 
software may use it as one thing in one case, and another in another 
case. If it sees it as an XML namespace and it is trying to build unique 
names, it uses it as an identifier. If it sees it as an XML namespace 
and it is trying to figure out content models then it *has no choice* 
but to try to use it as a locator, because the information it needs is 
not otherwise available. So it hands it to a dereferencing function. 
That function looks in its cache. If the information is there, then it 
has successfully used the URI as an identifier. If it doesn't, it makes 
an HTTP connection and uses the URI as a locator.

When I create the identifier I *do not know nor care* who will use it as 
an identifier and who will use it as a locator. And furthermore, any URI 
that can be only one or the other is simply disabled. Half-useful.

Once there is a REC-RDDL, thousands of EXISTING identifiers will have a 
standardized way to have the other half of their nature "turned on". 
Thank goodness they were designed to make this easy ("http://...") and 
not hard ("urn:...").

Given that the person creating the URI doesn't know what problem you are 
trying to solve in using the URI, it simply doesn't make sense for them 
to tell you whether you should dereference it or not. Really, the answer 
is very simple and costant across *all URIs*: "If you lack information 
about the resource that you think you might get by dereferencing it, 
then dereference it. If you have the information you need about the 
resource, then don't dereference it." Web browsers usually fall into the 
former category (caching being the exception). XML parsers usually fall 
into the latter category (RDDL-lookup being the exception).

> ... I don't think that the cost of deploying a non-dereferencable
> scheme would be high - there's no methods of deref to define or have
> software understand.  And I do believe that http: URIs can and should be
> used for identifiers.

There is no such thing as a completely non-dereferencable scheme. No 
matter what the scheme, you can hand the URI to an HTTP proxy and it 
will try to give you a representation. But as we have discussed before, 
it is very difficult for it to give you a representation if there is no 
location information in the identifier.

  Paul Prescod

Received on Friday, 11 October 2002 19:52:04 UTC