W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Editorial suggestions for DeltaV 11.2

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 18 Jan 2001 11:52:01 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569D8.0041313C.00@d06mta07.portsmouth.uk.ibm.com>


> Some minor editorial suggestions for DeltaV 11.2:

I'm not an editor, but that didn't stop me making some comments, below.
p.s.  where there is no comment that means I agree.

> Section 1, "Introduction", paragraph 1, 5th sentence:
> "interesting" -> "interested"
>
> Section 1.3, "Terms", "Predecessor, Successor, Ancestor, Descendant":
> "When a version is related to another version by one or more predecessor
> relations, it is called an 'ancestor' of that version."
> Consider clarifying which version in the sentence is the predecessor:
> "When a version precedes another version by one or more predecessor
> relations, it is called an 'ancestor' of that version."
>
> Section 1.3, "Terms", "Version History Resource" and "Fork, Merge":
> Why aren't these defined in section 1.3.1, Optional Versioning Terms?
> Version History and Merge are both optional.  By my reading, there is no
> requirement to support fork/merge semantics or version history resources
in
> Core Versioning.  If "Fork, Merge" definitions are moved to section
1.3.1,
> the diagram following the definition should move with them.  While you're
> at
> it, why not label the first set of terms "Core Versioning Terms" and make
> them a peer section to "Optional Versioning Terms"?

The terms are used in core versioning, even though the resources are not
required to exist.  For example, see the definition for VERSION-CONTROL in
section 2.4.  It refers to a new history resource being created although
ther Version-History Option is not presented until section 5.

> Section 2.1.1, "Creating a Version-Controlled Resource", paragraph 1,
> sentence 1:
> Add "versionable" as follows to make clear that VERSION-CONTROL can be
> applied only to versionable resources, not just any old resource:  "In
> order
> to track the history of the content and dead properties of a versionable
> resource, an author can put the resource under version control with a
> VERSION-CONTROL request."
>
> Section 2.2.1, "DAV:checked-in  (protected)", sentence 2:
> "This URL can be used to retrieve this particular state of the
> version-controlled resource after the version-controlled resource itself
> has
> been modified."
> This sentence should be moved to Section 2.2.2, "DAV:checked-out ...",
> because it's true there but incorrect here.
>
> Section 2.4, "VERSION-CONTROL", subsection "Postconditions", paragraph 1,
> sentence 5:
> "chose" -> "choose".
>
> Section 2.8, "Additional PROPPATCH Semantics", subsection "Additional
> Preconditions", last precondition:
> "(DAV:cannot-modify-unsupported-property): An attempt to modify a
property
> defined by this document (either core or optional) whose semantics are
not
> enforced by the server MUST fail.  This helps ensure that a client will
be
> notified when it is trying to use a property whose semantics are not
> supported by the server."
> It seems from RFC 2518 that all dead properties fall under the
description
> of "[a property] whose semantics are not enforced by the server", but
> surely
> we don't want to disallow modifying dead properties.

They key point seems to be "defined by this document" -- the document does
not define any dead properties.

> This should be
> reworded to say:  "DAV:cannot-modify-unsupported-property): An attempt to
> modify an optional property defined by this document but not supported by
> the server MUST fail.  This helps ensure that a client will be notified
> when
> it is trying to use a property that is not supported by the server."

This is more succinct.

Tim
Received on Thursday, 18 January 2001 06:52:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT