Editorial suggestions for DeltaV 11.2

Some minor editorial suggestions for DeltaV 11.2:

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"?

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.  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."

--Chuck Fay 
FileNET Corporation, 3565 Harbor Blvd., Costa Mesa, CA 92626 
phone:  (714) 327-3513, fax:  (714) 327-5076, email:  cfay@filenet.com

Received on Wednesday, 17 January 2001 18:01:40 UTC