- From: Tim Berners-Lee <timbl@w3.org>
- Date: Wed, 24 May 2000 01:41:52 -0400
- To: "Liam Quin" <liam@holoweb.net>, <xml-uri@w3.org>
-----Original Message----- From: Liam Quin <liam@holoweb.net> To: xml-uri@w3.org <xml-uri@w3.org> Date: Tuesday, May 23, 2000 5:31 PM Subject: Re: Are *relative* URIs as namespace nemes considered harmful? >James wrote, incorrectly: >> That's not the problematic case. The problematic case is when you have >> two URI references that are identical when compared as strings but refer >> to different resources (because they have different base URIs). > >URLs (specifically) do not guarantee that they will return teh >same octet stream when accessed each time. Many do not, in fact. Liam, I diasagree with you here. It is true that the URL *technology* does not (unlike md5:) guarantee you the same thing each time, BUT the HTTP spec determnes that if you get 200 OK back from a GET for a URI then the server returns you a representation of the (abstract) resource identifid by the URI. Obvously, this is under the control of the owner of the domain name, who owns the URI. So as in most places trust is involved. We trust that ISBNs won't be reused. There is a historical running down of URLs as though the HTTP technology were responsible for fact that sometimes URLs "change". They don't change, people change them. (And they are learning not to!) >Therefore, there is *never* a guarantee that two URLs refer >to the same resource. Consider a URL that, when dereferenced, >returns a random web page. Or a document that is updated. In each case, there is a generic concpet f what is identified by the URI. The random page is exactly that. It is (a strange special example) an abstarct resource whose value is a random generation or random selection. Like a random number function it has uses. A living document is a very important case. It is important to b eable to refer to "the latest version of the XHTML spec". We give two URIs, one for the frozen version and one for the latest version. >The only way to say that two URLs refer to the same thing is >to download them and look at what you got. There is nothing else. You have a relationship with the domain owner, formed by a promise such as "for more information see http://example.com/chocolate" >As a result, the only rational way forward is to define what lies >at the other end of a namespace URL, and to remind implementors >that they can use a cache to avoid fetching it every week, along >with the "Expires" http header where available. > >If you do this, there is no long a problem with a relative URL, >because all that matters is the resource to which that URL refers, >not the byte sequence in the URL itself. I disagree. The absolute URI itself is th identifier of the abstract thing, the namespace. That is what we want to hang syntax and semantics on. The particular resource which the namespace's owning authroity retirns to tell you about it may differe from day to day. Today, for example, it may be an xml-schema and tomorrow it may be an xml-schemav2 document which tells you totally consistent things but adds more information which before coulod only be expressed in English in the comments. >Lee Tim BL
Received on Wednesday, 24 May 2000 13:18:40 UTC