RE: Requirements for External Members and Ordered Collections

Judith,

I finally got time to review these requirements I hope this doesn't cause too many problems with the March 13 deadline :-)

Some comments on the external members requirements

 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.

[Dylan Barrell]  If this is not required, then what is the point of having these references at all? If there is no relative URI, then as far as I can see there is no URI at all so there is no way for a non WebDAV compliant client to GET the content (which they can for internal members which means that there is an inconsistency between how internal and external members are treated). Legacy apps will have to implement a WebDAV gateway so they might as well implement a scheme for generating a URL for the external references (they must all have some way of uniquely identifying a reference).

[Dylan Barrell]  Some comments on the ordered collections requirements

 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.

[Dylan Barrell]  It would be nice if the order could be manipulated in the same way a property is manipulated though i.e. make the ordinal a WebDAV property of the members of a collection and the differentiation between an ordered and an unordered collection simply a property on the collection - this would make this portion of the spec very consistent with the base WebDAV spec.

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.
[Dylan Barrell]  This would be easy and consistent if the ordinal is a property.

4. It is possible to impose multiple orderings of the same collection

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.

[Dylan Barrell]  I think this shouldn't be a requirement but rather that the second collection option be chosen as the way of solving this problem.

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.

[Dylan Barrell]  This was the rationale for allowing an external reference to an internal member of a collection to reside in the same collection. That should be the way to solve this problem I don't think the ordering solution should be a requirement.

6. Orderings are server-maintained, and cannot be directly accessed by clients

[Dylan Barrell]  I disagree with this. I think clients should be able to derectly manipluate the ordering (oterwise how does the professor indicate in which order the students are to read the materials)

Cheers
Dylan

Received on Thursday, 12 March 1998 03:01:38 UTC