- From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
- Date: Sat, 1 May 1999 23:45:14 -0400
- To: ejw@ics.uci.edu
- Cc: ccjason@us.ibm.com, w3c-dist-auth@w3.org
Just one minor terminological note. I'd like to make sure that we don't confuse the concepts of mapping a URL to a resource with any games the server may play in associating underlying files in the file systems to a resource. In particular: From: Jim Whitehead <ejw@ics.uci.edu> /url1.html /url2.html | / | / resource "1" | \ | \ | \ /html/url1.html /html/url2.html That is, have a one to many mapping of a resource to files in the filesystem. This is permitted behavior, and is in fact the only way to implement multiple variants of a single resource using a file system repository. One url is mapped to one resource, which is mapped to several files, one file per representation of the resource. We could perhaps use a term "implements" instead of "mapping", i.e.: "That is, a resource can be implemented by several files in the filesystem. This is permitted behavior, and is in fact the only way to implement multiple variants of a single resource using a file system repository. One url is mapped to one resource, which is implemented by several files, one file per representation of the resource." The benefit from a filesystem perspective is that /html/url2.html is only a hard link, not a copy. Now, when an UNBIND occurs, the picture changes to: /url2.html / / resource "1" \ \ \ /html/url2.html Now, admittedly, this behavior causes problems for those proposed definitions of UNBIND which prevented state changes on the server, suggesting those definitions may need some tweaking... I don't think that the proposed definitions (or at least, my proposed definition :-) of UNBIND prevented state changes on the server. To the contrary, it explicitly *avoids* saying anything about state changes on the server beyond the change to the advanced collection from which the binding was removed. Cheers, Geoff
Received on Saturday, 1 May 1999 23:45:19 UTC