Re: Clarification of URI vs. Resource

Here's the way I wish things worked:

Collections are resources, and their members are resources, and membership
in a collection has nothing to do with what identifiers are used for the
collection or its members.

Methods are defined for creating and deleting collections, adding and
removing collection members, copying and moving collections, listing
collection members, and listing the collections a resource belongs to.
(Only the last of these is missing today.)  So we never have to rely on the
syntax of identifiers for any of these operations.

MOVE resource R from collection C1 to collection C2 just means if you do a
PROPFIND on C1, you will no longer see R in the result set, and if you do a
PROPFIND on C2, you will see R in the result set.  It implies nothing about
identifiers for R.

DELETE collection C1 means that C1 and all of its member resources are gone,
not just that certain identifiers for those resources don't work any more.

Eventually we need to ask, can there be collections that weren't created
with MKCOL?  In particular, may the file system directory hierarchies that
many Web servers expose be collections?  We want to say, yes.  All that's
necessary is that the Web server support PROPFIND, etc., for those
resources.  May a server decide that some of the resources in the file
system directories are collection members and others are not? Yes, that
might be confusing to users, but it could be done.  We expect that mostly
servers would decide to have their URL namespaces exactly mirror collection
hierarchies, so that mostly it would be possible to deduce collection
membership from the URL syntax, but no one should ever rely on this.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Friday, 13 November 1998 11:20:29 UTC