- 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