Comments on 06 spec

Collections

1. State explicitly that a WebDAV server must treat its HTTP URL hierarchy
as collections, whether or not they were created with WebDAV's MKCOL. So
they must have resourcetype = collection, etc.

2. I'm going to raise the issue of ordered collections again, because this
version of the specification explicitly states that collections are not
ordered.  I have been arguing for some time that standardizing ordering for
collections would be very useful, and I believe that others on the list
share my view.  Of course, Jim has the last word on whether we have reached
consensus, and I bow to his judgment.

Ellis also pointed out that if we do have ordering for collections, it is
sometimes useful to allow a resource to be a member of the same collection
more than once. 

3. Semantics of external members

There are several points in the specification where I think the semantics
of external collection members is mistaken.  I think that the reason for
all of the anomalies is that you have decided to implement external members
as a property of the collection resource.  This implementation choice does
not force us to have the mistaken semantics, but it makes it more difficult
to get the semantics right.  I would argue that the semantics should drive
the implementation (and in fact we don't have to tell servers how to
implement external members at all).  So here are the problems:

Getting a listing of the members of a collection should result in a list
that includes both internal and external members, but according to 7.1 the
list will include internal members only.

A Depth = 0 COPY operation should not copy any members, internal or
external.  The new collection should not have any members. But according to
section 7.10.3, the new collection will have external members copied from
the old collection. 

The Depth header should define the behavior of a method for both internal
and external children, but according to 8.3 it affects only the behavior
for internal children.

4. (A minor point) DELETE for Non-Collection Resources (7.8.1):  Actually,
everything you say here applies to all resources, whether they are
collections or not.  Then 7.8.2 goes on to discuss DELETE behavior that
applies only to collections.

---------------
Links

I think it would be worth introducing the notion of links somewhere in
section 2.  Section 3.4 refers to them without having introduced them at
all, and support for links between resources of arbitrary media types is
really a significant contribution of WebDAV.  Here's some text, if you like:

"Although HTML resources support links to other resources, the Web needs
more general support for links between resources of any media types.
WebDAV provides such links. A WebDAV link is a special type of property,
formally defined in section 11.4, that allows typed connections to be
established between resources of any media types.  The property value
consists of a source URL and a destination URL, and the property name
identifies the link type."

I also wonder if the formal definition of link is right.  It says:
<!ELEMENT link (src+, dst+)>
But the accompanying text says you are trying to allow for multiple links
of the same type on the same resource, so do you really mean:
<!ELEMENT link (src, dst)+>
Or are you trying to allow a single link to have multiple sources or
multiple destinations? Or both, perhaps:
<!ELEMENT link (src+, dst+)+>

---------------

Typos

7.9.1 "...are not otherwise effected." Should be "affected".

11 "(i.e., to further restrict . . .)" should be "(e.g., to further
restrict . . .)"


Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	(716) 422-5169
Fax:		(716) 422-2938

Xerox Corporation
Mail Stop 105-50C
800 Phillips Road
Webster, NY 14580

Received on Thursday, 22 January 1998 16:55:45 UTC