Re: Summary: Ordered Collections

Jim,

Thank you for the summary on ordered collections.  Reading the summary brought to mind a few questions.

My reading of the summary and the list entries cited lead me to believe that the proposal is for totally ordered collections.  The order is to be generated by the client (via a header which stipulates predecessor or successor) and maintained by the server.  The semantics of the order are not known to the server.  A given collection can have only one ordering.

  1.  No argument that linear orderings can be useful, but why exclude partial orders?
  2.  What if I need two or more orders defined in a collection?
  3.  What are the semantics of the proposed order?

One of the compelling arguments made for ordered collections is that it might be useful for versioning, in which case Q.1 has some merit.

More troubling to me are the issues raised by Q.2 and Q.3.  As I see it, within the context of  the current proposal (for ordered collections) it would be difficult at best to provide future support for multiple orders in a collection, let alone define the semantics of such orders.  As for the semantics of the proposed ordering, I suppose one can only hope that client B "means" the same thing as client A (w.r.t. order) when adding something to a collection.

Will the WebDav property model allow one to define a relation in a collection, and associate the relation with the collection?  Might there be schema(s) associated with the relation that make its semantics identifiable and unambiguous?  If so, and if the relation were reflexive, antisymmetric and transitive, then one would have an order in the collection.  Presumably, one would want such a property to be "live".

    Del

Received on Thursday, 4 December 1997 19:34:55 UTC