W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2002

RE: New AFTF draft.

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Wed, 11 Sep 2002 11:01:39 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D086182EB@red-msg-07.redmond.corp.microsoft.com>
To: <noah_mendelsohn@us.ibm.com>
Cc: <carine@w3.org>, <chrisfer@us.ibm.com>, <dorchard@bea.com>, <John_Barton@hpl.hp.com>, <moreau@crf.canon.fr>, <ruellan@crf.canon.fr>, <xml-dist-app@w3.org>, <ylafon@w3.org>

I think the main point is that a URI doesn't imply "location", it is
merely an abstraction of something that has identity (I think this is
consistent with [1]). The notion of "server" is not in any way integral
to this, as I said in my previous mail [2], a server (or servers) may
show up in particular resolution mechanism but that is orthogonal to the
identifier itself. There is no dependency on client/server or otherwise.

Hope this makes sense,


[1] http://www.w3.org/TR/uri-clarification/#uri-partitioning
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0101.html

>Hmm.  I don't think we can have it both ways.  If resources 
>don't travel, 
>then it's incoherent to say "this resource lives at server X". 
> In other 
>words, if something has a location, then it's necessarily 
>reasonable to 
>say that it has a location that moves, at least in a system like this. 
>Keep in mind that with my earlier example, there was on 
>picture of my on 
>any server.  The only state representing the picture at all was in the 
>message.  So, I think we can have it two ways:
>1) Resources don't travel because they are never localized.  
>They are just 
>abstractions with no notion of location or proximity.  In this case, 
>Henrik's proposal that resources don't travel makes sense.
>2) Resources do or often do have a location.  In this case, I 
>think it's 
>as coherent to say the location is in a message as on a 
>server.   I hope 
>we aren't tieing the notion of URI and resource to client/server?
Received on Wednesday, 11 September 2002 14:02:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:52 UTC