- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Sat, 27 Sep 1997 02:51:35 -0700
- To: "'John Turner'" <johnt@cgocable.net>, "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
John, Thank you for your comments on the "sneak preview" collections and namespace operations draft. My comments are below: On Friday, September 26, 1997 3:10 AM, John Turner [SMTP:johnt@cgocable.net] wrote: > I have a few questions and comments. > > Section 1.1.1, last paragraph. > I agree, but there are cases where it does not make sense > (i.e. the cgi example in the protocol document.) Would something > like "SHOULD > for the part of the namespace that it makes sense" be reasonable? In WebDAV we have been using the RFC 2119, (also Best Current Practices 14), definitions of the terms MUST (NOT), SHOULD (NOT), and MAY. In particular, this specification states, SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Based on this definition of SHOULD, I think adding "for the part of the namespace that it makes sense" would be redundant, since if the SHOULD requirement is ignored, it would only be after carefully weighing that option, which would presumaby only happen in the case where the requirements didn't make sense. > Section 1.3.2 > This seems to be a copy/paste error. The description belongs to > another property. Good catch. I'll recommend this be corrected. > > Section 1.4.8 Example > What are the parameters on the IsCollection start tag in the Members > element? The parameter is a PropLoc, which was originally defined in the properties section of the specification. This parameter gives the URI of the IsCollection property on the resource. Performing a GET on this URI returns the value of the property. A PropLoc parameter could appear on any of the properties in the Prop block, but in this example, only one is shown. > Section 1.5.3 > My understanding is that a PUT of a non-collection resource adds it > to the namespace > and also adds it as an internal member of the parent collection, > assuming that the parent > is a collection. Is this correct? If so, could this be said > explicitly? > Yes, this is correct, and yes it should be stated explicitly. I'll recommend language be added to section 1.5.3.1, "PUT for Non-Collection Resources" to state this explicitly. > Section 1.6.3.3 > The paragraph references a conflict between between source and > destination > properties, but the next section (1.6.3.4) says that if the > overwrite is set > then it must DELETE the destination collection. I thought that if > the overwrite > was not set, that the copy would fail. This suggests that there can > be no conflict > between the properties. > > There also seems to be something wrong with the last couple of lines > of text. Hmmm. This paragraph is wrong, and needs to be fixed -- either an edit got lost, or didn't make it in. You are correct that, as-is, this paragraph does not make much sense. I'll create new language for this section. > Section 1.6.5.1 > The overwrite header is missing on the first example. Or does it > default to true? Yes, Section 1.11.3 states that the default value of the Overwrite header is true, and the header may be omitted when its value is true. Note that the last sentence of 1.11.3 is incorrect, and a change has been submitted to correct it. > General Copy/Move question about non DAV space > Should there be some comment to the effect that a MOVE or COPY on a > non DAV part > of the server has undefined results? I think this falls under the general guidelines of: if you don't support a method, then return a method not supported status code. This is a pre-existing mechanism, so I'm not sure it needs to be re-stated. - Jim
Received on Friday, 26 September 1997 18:14:31 UTC