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

David Orchard wrote:
>...
> 
> But won't the authors of the the http namespaces now want client software to
> do something with the REC-RDDL file? 

Presumably there is some new kind of application that is enabled by the 
RDDL deployment. For instance it becomes possible for XML editors to 
give "friendly names" of elements or auto-discover datatypes. If your 
client app needs this new feature then it tries to dereference URIs it 
sees. If it doesn't, it just does string comparisons as today.

>...

> This seems like a most succinct summary.  And it still causes me confusion.
> 
> Given the lack of constantness, how does a user of a thing know when it
> changes from one form to another?

Answer #1:

I would say that either GET returns 404 or it doesn't. If the provider 
of the URI knows whether GET should return useful information or not, 
then they could add that as metadata surrounding the link.

Answer #2:

If GET always returns something (either because we make that a Best 
Practice or because we define "404" as "something") then there is no 
confusion. It's just a question of whether GET returns something 
interesting to a particular client or not. This comes back to either 
testing or using surrounding metadata.

> ...  Presumably we want the software to do
> different behaviour depending upon whether it's concrete or abstract. 

I disagree. Either you work with the thing "by identity" (string 
comparison) or you need to know something about its state that can only 
be answered by dereferencing it. I don't think that a single application 
(or application feature) needs to shift from one mode to another. If it 
works with the former it should use the former. If it needs the latter 
it should use the latter. If it COULD USE the latter but fallback to the 
former, it probes and does the right thing.

> ... And
> the only tool we have is the name.  

And surrounding markup/metadata/assertions.

  Paul Prescod

Received on Thursday, 10 October 2002 17:13:12 UTC