RE: Requirements for External Members and Ordered Collections

Thanks for your comments, Dylan.  The first requirements draft has already
been submitted.  It is really meant just to stimulate discussion like yours
in any case, so timing isn't really critical.

>
> 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).

[Judy] There are certainly implementations that would allow a client to get
the absolute URI without assigning it a relative URI.  One such
implementation was described in earlier versions of the WebDAV spec: a
collection's external members were represented as a list-valued property on
the collection.

>
>[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.

[Judy] I think you'll find a lot of support for implementing orderings
using properties.  But most suggestions I've seen so far favor making a
list-valued property on the collection rather than a property on the
members of the collection.  It seems to me that it would be much easier to
maintain an ordering (imagine adding a new member to the collection, which
you wanted at the beginning of the ordering) if it were a single property
on the collection.

>
>
>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.

[Judy] As you point out, there are several problems that can be solved
either using membership-by-reference or using orderings.  Because I was
thinking about two separate groups of requirements, one set for
membership-by-reference and one set for ordered collections, what I ended
up with was some "requirements" that are really pointing to a solution
rather than capturing the problem to be solved. In the next draft, I should
probably try to abstract up a level.  

So in this case the requirement is really that it be possible to view the
same set of resources as being ordered in different ways.

Then when we get to discussing implementations, we can decide whether to
satisfy this requirement by relying on multiple collections of
members-by-reference, each with a single ordering, or to support multiple
orderings on a single collection.

>
>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.

[Judy] This may be another case where there's really a single more abstract
requirement that could be satisfied either through our implementation of
external members or through our implementation of orderings.  I'm at a loss
for the moment as to how to abstract it.

I can see that in general you favor a very simple ordering mechanism, and
where possible solving problems through the external members.
>
>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)

[Judy] You have lots of company in favoring client maintained orderings.
The alternative would be to provide methods for creating and modifying
orderings.

Received on Thursday, 12 March 1998 10:51:59 UTC