RE: proposal for ordered collections

My current understanding is that an agreement has been reached between the
IESG and the W3C allowing for XML to be directly referenced in IETF
standards track documents. My further understanding is that the official
reference for XML will be released by the W3C this month.

As for the use of DAGs. Let us separate the purpose of collections from
capabilities the syntax we are using may have. The purpose of collections
was to provide a mechanism for managing the hierarchical relationship
implicit in HTTP URLs. Until now that relationship was not formalized
however this working group felt that a formalization was needed and banded
together for the purpose of providing that formalization.

An arbitrary DAG goes beyond the simple hierarchical relationship that
collections were meant to encompass. However this issue will be directly
addressed in our versioning work as the current consensus is that the
relationships amongst different versions of documents will be described as a
DAG.

			Yaron


> -----Original Message-----
> From:	Roy T. Fielding [SMTP:fielding@kiwi.ics.uci.edu]
> Sent:	Thursday, December 04, 1997 6:04 PM
> To:	w3c-dist-auth@w3.org
> Subject:	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 Saturday, 6 December 1997 18:48:34 UTC