Re: Workspace option comments

   From: "Jim Whitehead" <ejw@cse.ucsc.edu>

   1) Ambiguity of the term "resource".

   Section 7.1.1, DAV:workspace-checkout-set property:

   > This property identifies each checked-out resource whose
   > DAV:workspace property identifies this workspace.

   Does this property identify a "version controlled resource", or
   a "version resource" (or both)? (Or "version history resource?") Just
   saying "resource" is ambiguous.

As Greg and Tim point out, the term is "checked-out resource",
not "resource".  I will follow Tim's suggestion and add the
term "checked-out resource" to the terminology section.  Saying
that a checked-out resource is the result of checking out
a resource sounds a bit like a statement issued by the
Department of Redundancy Department, but given the thread
on "does a PUT do a PUT", I suppose we'd better put it in there (:-).

   The same problem affects Section 7.2.1 (DAV:Workspace). If a
   server OPTIONally supports this property, which types of
   resources should have this property defined on it?

That's up to the implementation.  There is a requirement on
all version-controlled resources in a given workspace
(i.e. just one per version history), but the only effect
of having another kind of resource in a workspace is that
the workspace is deleted if the workspace is deleted.

   Is this
   defined on "version controlled resources" or "version
   resources" (or both)?

Again, up to the implementation.

   Also, it sounds like non-version-controlled
   resources should also support this property.

That's why we say it's a property on any WebDAV resource,
just like the DAV:comment and DAV:author-displayname
properties.

   Should
   "version history resources" support this property -- I can't
   see much need for that, but maybe there is a use case.

Up to the implementation.

   2) Section 7.7

   This section is being defined as a delta to the definition of
   VERSION-CONTROL given in Section 2.5, which states:

   > (DAV:put-under-version-control): If the request-URL identified
   > a versionable resource at the time of the request, a new version
   > history is created and a new version resource is created in the
   > new version history.

   Since this isn't the intent in 7.7, there needs to be explicit
   language stating that, when a version resource is specified in the
   request body, a new version history resource is NOT created. A new
   definition of the (DAV:put-under-version-control) postcondition is
   also needed in this case.

The DAV:put-under-version-control applies only when
when the request-URL identifies an existing resource.
I'll add "non-null versionable resource" to ensure there
is no confusion here.

   3) Child workspaces of workspaces?

   Is it possible for a workspace to be contained by another workspace?
   The specification is silent on this issue, though the definition
   of workspaces as collections suggests that yes, a workspace can
   contain a child workspace.

A workspace can appear in the URL space under another workspace
(anything not forbidden is allowed).  But a resource can only
identify a single workspace in its DAV:workspace property, so
the answer depends on what you mean by "contain".  If you mean,
"appears under in the URL namespace", yes.  If you mean "has
multiple DAV:workspace values", then no.

   4) Are workspaces versionable?

   Is it possible to place a workspace under version control using the
   VERSION-CONTROL method?  The specification is silent on this topic.

Anything that is not forbidden is allowed.  In particular, an
implementation can allow both the VERSION-CONTROL method and
the BASELINE-CONTROL method to be applied to a workspace
(but it is not required to do so).  Our implementation will
in fact not allow you to apply VERSION-CONTROL or BASELINE-CONTROL
to the workspace, but I know of others that will.

   Minor nits:

   Section 7.1:

   > The workspace option introduces the following REQUIRED
   > properties for a workspace.

   But there is only one property (singular) introduced.

After a while, I got tired of changing back and forth between
"y" and "ies", every time the number of properties changed between
one and many.  Please remember that I have prepared somewhere
between 50 and 100 working drafts.  I was planning on cleaning this up in
the final draft before submission to the IESG, but I appreciate you
raising the issue, because I may otherwise have forgotten to do
so.

   The same comment applies to Section 7.2

See above.

   Section 7.2.1:

   > If the resource is associated with a workspace, this
   > property MUST identifies this workspace.

   identifies --> identify

Thanks for catching that.  I recently did a pass through the document adding
MUST in a few places where I thought it was appropriate, and in
this case neglected to modify "identify" to "identifies".

   Hmm, it stretches credulity that 7+ people could have carefully reviewed
   this option and not caught at least these nits, if not the other issues.

Please allow me to be a bit testy here.

Also please bear in mind that JimW is a good friend of
mine, that I respect and admire his impressive contributions
to WebDAV, and that if anyone has the right to criticize,
it would be Jim, and that Jim has taken far more abuse as
co-author of 2518 than I ever have (or hope to :-), and
that he has a really cute new baby that I hope to visit
someday soon.

So with all that in mind:

(flame-on :-)

You appear to be implying that those who have stated that they have
reviewed this option are either lying or incompetent.  The reviewers
have been *incredibly* diligent and thorough, down to the point of
identifying places where there were only one space following a period,
rather than two, and where there was a leading space in the beginning
of a new section.  This indicates to me a level of effort far beyond
that required to ensure an interoperable and understandable document,
and speaks loudly to both the interest and quality of the reviews.

It stretches my credulity to believe that your credulity was stretched
by the fact that the reviewers understood a simplifying editorial
policy I have had since the very beginning, the fact that they
missed a typo that I introduced in a non-substantive change to the
document, and the fact that you felt there were parts of the protocol
that deserved some clarification, but which previous reviewers felt
were clear in their current form.

(flame off ... I'm sure I'll regret this, but really, didn't
Jim deserve it? :-).

Cheers,
Geoff

Received on Friday, 9 February 2001 10:32:49 UTC