Re: v6: external members

Jim,

> At 06:49 PM 1/24/98 PST, Roy T. Fielding wrote:
> >It seems to me that the use of PROPFIND to provide a namespace listing
> >is merely providing a window to the namespace allocation functionality
> >of the server.  It has become so stripped down as to no longer correspond
> >to what is normally referred to as a collection (at least within other
> >Hypertext systems).
>
> I am not sure I understand Roy, but if I do, I agree with him, conditionally.
>
> Let me elaborate and expand on what I think this means.
>
> The proposed semantics for collection are so weak as to not be "worthy" of
> the name "collection".
>
> If these semantica are retained  (I would prefer expanded semantics, e.g.
> external members as first class citizens, and optional support for
> ordering) then perhaps a better name, more faithful to the actual
> semantics, would be "directory"  or "folder".  I find "namespace" to be too
> generic, since one may speak of a namespace of domain names, but perhaps
> the term "namespace" is used in a coherent way throughout the spec.  If
> that's the generally accepted term in the HTTP community (forgive my
> ignorance) then it's fine.
>
> If so, shouldn't the method MKCOL be renamed to MAKENAMESPACE (or MKDIR) as
> appropriate?

Whether it's called a "collection" or not aside, in my view is the WebDAV notion
of a collection *should* be treated as a pure namespace.  There is a need to be
able to structure the URI namespace, and the current WebDAV collection does
that.  When the notion of a collection (really a namespace) is expanded to
included unnamed external members, it suggests that a collection is more than a
namespace, but does not specify what it actually does represent.  It seems to me
that this opens the possibility that different DAV implementations may use
external members for different purposes, which might hurt interoperability.

Certainly there are any number of other possible notions of "collection",
including compound documents and versioned documents.  Each one of these needs to
specialize the namespace concept of a collection in some way.  I believe that
each of these specialized forms of a collection ought to be modelled as a
different resource type.  That is, if you want a compound document container,
define it as such, with ordered and repeated members as desired.  It would also
be wise to consider the possibilities of compound documents with versioned
members, and versioned, compound documents.

That being said, I don't object to inclusion of external members in the spec, if
that's what it takes to get it through the process.

Howard

Received on Monday, 26 January 1998 15:01:44 UTC