- From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
- Date: Sun, 2 May 1999 00:08:53 -0400
- To: ejw@ics.uci.edu
- Cc: w3c-dist-auth@w3.org
From: Jim Whitehead <ejw@ics.uci.edu> ... I did want to note that there is a really good definition of resource in RFC 2396: Resource A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources. I'm happy with all this ... suitably "inclusive". The resource is the conceptual mapping to an entity or set of entities, not necessarily the entity which corresponds to that mapping at any particular instance in time. This makes it even more inclusive, since "not necessarily" doesn't rule out anything, it just extends it. Of course "conceptual mapping" does open up the barn door pretty wide (:-). Thus, a resource can remain constant even when its content---the entities to which it currently corresponds---changes over time, provided that the conceptual mapping is not changed in the process. This is an intriguing statement. I'm not sure what "remain constant" is supposed to mean or imply. And again, what is a "conceptual mapping"? So, it's not really appropriate to normatively define a resource as something that only lives in an object store. I agree. Plus, the definition is very careful to note that a resource is a "conceptual mapping to an entity" but is not necessarily the actual entity itself. In the file system case, this means a resource is a conceptual mapping to a file, not the file itself. Well, not really. It says that it is "not necessarily" the actual entity itself, but this doesn't rule out that the resource being the file itself. The definition is also explicit in noting that the resource can remain the same, even though the entity it is mapped to can change over time. So, a resource can remain the same, even though it may be mapped to several different files over its lifetime. I'm not sure what is the semantic significance of this "remaining the same"? > ... this makes it clear that > deleting all bindings to a resource has no defined effect on all > mappings to that resource. Huh? At least in the example in the definition, deleting all bindings does remove all mappings. A parsing problem. I think you interpreted the sentence as "has no defined effect on *any* mappings". The intended point is that deleting all bindings to a resource does not necessarily delete all mappings to a resource, since there can be mappings through techniques such as cgi-bin scripts, that are not derived from advanced collection bindings. > You can create a new resource in an > advanced collection with a PUT, MKCOL, or COPY. This might create all > sorts of mappings from URL's to resources, but none of them are > bindings except for the original one requested. The *only* way to > create a second "binding" to the same resource is with an explicit > "BIND" command. Then a "DESTROY" or "DELETE -all-bindings" > deletes the initial binding, and all *explicit* bindings created by > the BIND command. At first I wasn't too keen on differentiating between mappings and bindings, but now I see that this distinction is really helpful, and I like it. Excellent! Cheers, Geoff
Received on Sunday, 2 May 1999 00:08:56 UTC