Re: Comments on 06 spec

  See my comments below:

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.

[SKREDDY] Yes. Also, what about the backward compatibility. What happens if
		WEBDAV clients are trying to retrive properies of URL hierarchy
		created outside this protocol? What is acceptable in this scenario?

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. 

[ SKREDDY]  I agree with Judith and Ellis on this. May be we can do some more
	           discussion on this issue and come to some consensus on this.	
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.


[SKREDDY]  Why should external members different from internal memebers. 
	We should treat internal and external members same this would lead to
	much better and cleaner implementation.
   


   Regards,
   -Surendra

  ------------------------------------------------------ 	
Surendra K Reddy         Tel.   +1(650) 506-5441 
                         Fax.   +1(650) 506-7421
                         Email.	skreddy@us.oracle.com
"It is unwise to be too sure of one's own wisdom. It is healthy to be
reminded
 that the strongest might weaken and the wisest might err."  

  
Warning: Statements and opinions stated herein may not be those of Oracle
Corp.

Forwarded message 1

  • From: Judith Slein <slein@wrc.xerox.com>
  • Date: 22 Jan 98 13:59:53
  • Subject: omments on 06 spec
  • To: 3c-dist-auth@w3.org
  • Message-Id: 3.0.3.32.19980122165953.0093ab90@pop-server.wrc.xerox.com> 
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 Friday, 23 January 1998 11:02:21 UTC