Re: proposal for ordered collections

I think that we need to consider what (if anything) differentiates
a collection from a non-collection resource.  As far as I can tell,
that would be

  o  A collection can be unordered

All the other features could be accomplished as a normal resource.
That is, in fact, how Hyper-G implemented collections [1], and why they
do not support unordered collections.  After all, an unordered collection
is simply an ordered collection with the ordering defined by the server.

There are advantages to treating a collection differently than
a normal resource.

  o  The new method names allow the default presentation of a collection
     resource to be separate from its collection structure.  [This could
     also be accomplished by a property on the collection resource,
     which is how "index.html" works on most servers.]

  o  It is unnecessary to require a single exchange media type
     for manipulating the collection membership via PUT/POST/PATCH.

On the other hand, the current draft already requires text/xml
(which itself is a problem, see below) and a recent proposal said
that INDEX would be eliminated.

There are also disadvantages to treating a collection differently than
a normal resource.

  o  Ordering relationships have to be made by indirection to an
     ordering type or a separate DAG resource.

  o  Clutter.

I don't buy Jim Davis' argument that multiple ordering relationships
are unnecessary.  If ordering is needed at all, then it should be
represented in its most abstract form; otherwise, we'll have to come
up with a new exchange syntax to satisfy other ordering needs.
If you want to maintain simplicity, use a general syntax (such as
the ordering type being expressed as a property containing a URI
that defines either one of the standard orderings or a DAG resource),
and only require support for "none" and a single "dav:as-added"
ordering URI.

However, this all leads to a perplexing question: we (or perhaps I should
say, whoever decided text/xml was a universal exchange format) have already
eliminated all the advantages of distinguishing between collection
and non-collection resources, so why haven't we eliminated the
disadvantages as well?  Have I missed something?  In other words,
if we are already requiring text/xml, then require a form of XML
that represents a DAG and manipulate the DAG client-side in the same
way that the server-side DAG would be manipulated by the individual
methods, and then PUT/PATCH/POST the result.  That allows a much
friendlier UI as well.

BTW, the problem with text/xml is that there is no fixed definition
which the IESG would consider acceptable for a normative reference.
That is something the XML folks will have to get a move on, and fast,
if WebDAV is ever to be a proposed standard.  Harald knows what a
"fixed definition" entails [I don't know what the current understanding
is between IETF and W3C].

....Roy

[1] H. Maurer. "Hyper-G, now Hyperwave: The Next Generation Web Solution",
    Addison Wesley, 1996, section 9.2.

Received on Thursday, 4 December 1997 21:25:46 UTC