- From: <Tim_Ellison@uk.ibm.com>
- Date: Thu, 18 Jan 2001 11:52:01 +0000
- To: ietf-dav-versioning@w3.org
> 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 UTC