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.
attached mail follows:
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 14580Received on Friday, 23 January 1998 11:02:21 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:44 GMT