RE: Sneak preview: New collections and namespace operations draft

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