Re: Requirements for Collections

At 01:02 PM 2/20/98 PST, Judith Slein wrote:

A terrific set of requirements, which I am in substantial agreement with.
Will we be able to discuss these at a BOF at IETF?  I know Judy does not
plan to attend but I hope we can discuss them anyway.  I am eager to see
this move forward.

Following are comments and questions on specific bits and pieces.

>1. A resource is a direct member of only one collection.  

Suggested alternative wording:
 "Every resource, except the root resource, is a direct member of exactly
one collection.  The name of that collection is the name of the resource,
with the final component deleted."

Building on point 5 (no referential integrity), I would add

"A member-by-reference may be added to a collection regardless of whether
the resource it refers to actually exists at that time."

>9. It is possible for a member-by-reference to carry its own properties,
>distinct from those of the resource it refers to.

Let me elaborate on the conflict between 9 and 13.  The conflict arises as
follows:  Suppose one does a PROPFIND on collection C, looking for, let's
say, the 'date added' property.   Suppose C contains two members, direct
member (C/X) and member-by-reference R, where R's name (URL) is not
relative to C.  The resulting responses include hrefs for both C/X and R.
But if one does a PROPFIND on R directly, there's no way to find the 'data
added' property.  Indeed, R might be stored on some server other than that
holding C, and may have no idea that R is included (by reference) in C.

So one answer is to drop requirement 13, and require that all members by
reference have a name relative to the collection.

A second answer is to extend PROPFIND to take a Collection header argument.
 This argument would contain the name of the collection that contains the
member by reference.   So,

 PROPFIND R
 
might return different values than

 PROPFIND R
 Collection: C

The former sees the properties stored on R in its (unique) native location,
the latter sees those on R *as a member of C*.

I think the first solution is cleaner and simpler.  Are there other
solutions? Are there other conflicts, by the way?

In any case, the conflict between 9 and 13 is okay with me for now, since,
in general, protocols don't always satisfy all their requirements anyway,
so any specific proposal can satisfy one or the other, even if not both.  

As for Jim W's suggestion of a data model where a reference is a 'special
type of resource where its state is the reference'.  One nice thing about
this idea is that we would not need ADDREF or DELREF.  One could create
such a resource with PUT, providing the reference as a mandatory header
argument (the target URL), and delete it with DELETE.   Another is that one
can say precisely that GET will always do a Redirect reply (if one opposes
'automatic redirection', as in req 15 below.)

Alternatively, one could just add the member as an empty (or null) resource
and store the referent as a property value.  All that DAV would have to do
is define the name of this property.  Here, one would create a reference by
doing a PROPPATCH, and delete it with DELETE.
 
>11. For any collection member, it is possible to find out whether it is a
>direct member or a member-by-reference.

This does kind of suggest adding a new resourcetype, namely
memberbyreference, unless a resource can be *both* a collection and
member-by-reference, in which case it suggests adding a new property
memberbyreference which is T or F.

>12. It is possible for the same resource to be a member of a single
>collection multiple times.

This also conflicts with 13.

>13. Members by reference are not required to have names (URLs) relative to
>the collection.
>
>Rationale: Legacy applications that implement membership-by-reference
>without assigning names to the references in the collection.

Ummm, could you name one or two such legacy applications?

>
>15. By default, operations on members-by-reference affect the reference,
>not the resource it refers to.  But wherever it makes sense, an option is
>provided to let the client request that the operation apply to the target
>resource.


Well, as you know, I oppose this.  I think there should be no automatic
redirection, on the grounds of simplicity (uniformity) and security
(authentication).

I think we should use the 302 Moved Temporarily reply for GET and PUT on a
member by reference

>-------------------
>ORDERED COLLECTIONS

>JIM WHITEHEAD:  You forgot to state your assumption that the server will
>use the ordering of a collection when returning the members of a collection
>with PROPFIND.

I don't think this is necessary or desirable.  It would limit the
collection to exactly one ordering (or else require the client to select
the desired ordering   when doing the PROPFIND, which is just too complex.
it would means that ordering properties would have to be LIVE and it would
increase the complexity of the server.  And since it would have to be
optional anyway, I doubt clients would even bother to use it.)

Let the server return members in any order it likes, and let the client
fetch an ordering property if it cares.  Clients that don't care will work,
and those that do will also work.  

>6. Orderings are server-maintained, and cannot be directly accessed by
clients
>
>...>JUDY: I'm definitely assuming that the server will use a collection
>ordering when responding to a PROPFIND on the collection.  But it can do
>this even if the orderings are client-maintained properties, provided that
>we standardize the name of the ordering property, and its syntax.  

As I said above, I don't support this requirement.

While the requirements document is no place to debate implementations, I
would be unhappy with a set of requirements that explicitly ruled out use
of properties for ordering, esp since it seems both inexpensive and
(backward) compatible means of meeting all the (other) requirements.

Best regards

Jim

Received on Saturday, 21 February 1998 19:39:16 UTC