Re: Requirements for Collections

I have a few comments on the requirements for collections.

At 01:02 PM 2/20/98 PST, you wrote:
> .
> .
> .
>The requirements are intended to cover both external membership in
>collections and ordered collections.  I'm using different terminology here
>from what we are accustomed to.  Instead of "internal members," I talk
>about "direct members."  Instead of "external members," I talk about
>"members-by-reference."  This is because the requirements stated here allow
>a collection to contain a resource as a direct member, and also to contain
>a reference to that same resource. 
>
>MEMBERS-BY-REFERENCE
>
>The point of supporting members-by-reference is to enable multiple
>collections to share the same members
>
>	Without each having to keep a physical copy of the member
>	Changes in one place are guaranteed to be seen everywhere
>
>Principles and Requirements
>
>1. A resource is a direct member of only one collection.  

It seems to me that this requirement is mixing ideas.  Direct membership can
be used to indicate that something is a part of the collection and should be
treated as such.  A compound document for example.  Saying that it can only
be a direct part of one document limits the usefulness.  There is no reason
(except for complexity) that a document cannot have aliases in the
namespace.  A server that implements the namespace directly from a file
system would certainly have a harder time with aliases, but a server that
has a document manager as backend could deal with it easily.  In addition,
it would limit the means the DM server has to represent its documents in a
web namespace.

> .
> .
> .
>
>6. Preventing cycles is not required.

In fact I do not believe that the server should concern itself with cycles.
There may be applications of the reference that make use of cycles.


> .
> .
> .
>
>9. It is possible for a member-by-reference to carry its own properties,
>distinct from those of the resource it refers to.
>
>Rationale: There are properties like "who added this resource to this
>collection" and "when was this resource added to this collection" that
>don't belong to the target resource, since it may be a member (by
>reference) of many collections.  Instead, they belong to the
>member-by-reference.
>
>JIM WHITEHEAD: This requirement suggests a data model where a reference is
>a special type of resource, where its state is the reference (the URL), but
>which can have its own properties.
>
>JUDY:  Yes.  This suggests that requirements 9 and 13 conflict.

Not neccesarily.  One solution would be that if a reference does not have a
name it cannot be addressed directly, only through PROPFIND, etc.

>10. A listing of the members of a collection should show both the direct
>members and the members-by-reference of the collection.
>
>11. For any collection member, it is possible to find out whether it is a
>direct member or a member-by-reference.
>
>12. It is possible for the same resource to be a member of a single
>collection multiple times.
>
>Rationale: The cases I can think of where this might be useful are all
>cases of ordered collections.  So perhaps another way to supply the needed
>functionality is to allow a resource to be a member of a single collection
>only once, but allow it to appear multiple times in a single ordering of
>the collection.  Anyhow, here's a case: A collection contains the readings
>for a course.  The professor wants the students to read a particular
>article once at the beginning of the semester, and then to re-read it at
>the end.  Here's another: A collection contains the pages of a document,
>one of which is a graph that needs to appear multiple times in the document.
>
>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.
>
>JIM WHITEHEAD:  Add the corollary requirement that members-by-reference may
>have different names than the URL they reference (i.e., an in-collection
>name, separate from the referred-to name).
>
> .
> .
> .
>JUDY: Intuitively, I would expect DELETE, MOVE, and COPY not to touch the
>referred-to resource.  I don't know why. Intuitively, I would expect GET,
>PUT, PROPPATCH, and PROPFIND to affect the referred-to resource rather than
>the reference.  I think this is because the whole reason for the reference
>being in the collection is to give end users access to the referred-to
>object through that collection.  End users will not want even to know
>whether any particular resource is there by reference or directly.  Only
>administrators care about that stuff. I don't know what I would expect for
>LOCK.

I think I favour the simpler, all act on the reference by default, with some
operations having an option of acting on the referred-to resource.

> .
> .
> .
>
>
>ORDERED COLLECTIONS
>
>JIM DAVIS:  We don't need ordered collections.  We already have properties,
>which can have lists as values.  So clients can maintain any ordering they
>need using DAV properties.
>
>JUDY: DAV properties are certainly an obvious implementation of ordering.
>But if we choose that approach, we need to define a well-known property
>with standard syntax to represent orderings.  This is what will allow
>different applications on different clients to understand and use each
>others' orderings, and the server to use the ordering when responding to a
>PROPFIND.
>
>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.
>
>The collections specification will deal primarily with arbitrary orderings
>that are not sorts based on property values.  The DASL specification will
>presumably address sorting based on property values.  We should coordinate
>with them to make sure that it is possible to save the result of "SELECT *
>FROM /collection1/ ORDER BY author" as an ordering of the collection
>/collection1/.
>
>1. It is possible to order the members of a collection in an arbitrary way,
>not based on property values.
>
>Rationale:  Consider a collection of course readings for Computer Science
>101.  Two different professors teach this course, and each prefers to have
>the students do the readings in a different order.  This collection needs
>two different orderings, neither based on any properties of the readings,
>but just on what the professors think makes sense.
>
>2. Internal and external members may be intermixed in a single ordering
>
>3. It is not required that all collection members be included in an ordering
>
>Rationale: In 1 above, one of the professors only assigns a subset of the
>readings.  An alternative to this requirement would be to create two
>separate collections (one of them has only members-by-reference), one of
>which is a subset of the other.
>
>4. It is possible to impose multiple orderings of the same collection


If a property based ordering was used, how would that fit in with this?  A
single standard ordering property and as many others as systems set up? Or
multiple orderings in the one property?


>Rationale: See 1 above.  An alternative to this requirement would be to
>create two separate collections (one of them has only
>members-by-reference), each with a single ordering.
>
>5. A collection member may be included in an ordering more than once
>
>Rationale:  The professor may want the students to read an article early in
>the course, and re-read it near the end.
>
> .
> .
> .
>12. By default, members added to a collection without specifying a position
>are added to the end of the order.

This could be in conflict with 3 and 5 above.  A new member may not belong
in an ordering at all.  If a request to add a new member asks to have it
added to an orderering but gives no location, it should be added to the end.

>
>13. Deleting a resource removes it from the order.  So, a DELETE, followed
>by a PUT will not result in the same ordering as before the DELETE.
>
>JUDY:  Note that 12 and 13 assume some amount of server maintenance of
>orderings.
>
>ISSUES FROM JIM WHITEHEAD:
>
>Is ordering a quality of the collection, or of the resource? So, if I lock
>a resource, but not its containing collection, can I modify the order of
>that resource?
>
>
>
>
>
>
>Name:		Judith A. Slein
>E-Mail:		slein@wrc.xerox.com
>Phone:  	(716) 422-5169
>Fax:		(716) 422-2938
>
>Xerox Corporation
>Mail Stop 105-50C
>800 Phillips Road
>Webster, NY 14580


John Turner
johnt@cgocable.net

Received on Friday, 20 February 1998 17:51:32 UTC