Re: Workspace option comments

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

The term "checked-out resource" is used consistently through the document.
It refers to a checked-out version-controlled resource, and, if the
working-resource OPTION is supported) a working resource.

Note that a "version resource" is by definition a checked-in resource.
A version history resource is not a versionable resource (and therefore
cannot be checked in/out).

Maybe the term "checked-out resource" should be added to Section 1.4 Terms?

> 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?  Is this defined on "version controlled
> resources" or "version resources" (or both)?  Also,
> it sounds like non-version-controlled resources should
> also support this property.  Should "version history
> resources" support this property -- I can't see much
> need for that, but maybe there is a use case.

Any resource that is a member of the workspace will have this property, so
"yes" for version-controlled resources and unversioned resources etc., that
are associated with the workspace, and "no" for version resources and
version history resources since they are created by the server in
'server-generated URL' namespace which typically would not be in a
workspace.

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

Section 2.5 is describing the case when there is no <DAV:version> body
specified, and that holds equally true in Section 7.7.

The Section 7.7 precondition (DAV:cannot-add-to-existing-history) handles
the case of trying to bring another versionable resource under version
control with a <DAV:version> body.  I think that the 7.7 preamble
"...create a new version-controlled resource for an existing version
history." and this precondition are sufficient.  Am I missing something?

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

Since it is not explicitly disallowed, then yes you can.

You'll see in Section '7.2.1 DAV:workspace' that the DAV:workspace of a
workspace MUST identify itself, and all other resources MUST have the same
DAV:workspace value as their parent collection.  This means that the
workspace containment is constrained to follow the collection containment
(otherwise things get really freaky).

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

A workspace is a collection, so if the server supports versioned
collections, then yes, a workspace can be versioned.

> Minor nits:
>
> Section 7.1:
>
> > The workspace option introduces the following REQUIRED
> > properties for a workspace.
>
> But there is only one property (singular) introduced.
>
> The same comment applies to Section 7.2

I went back to my marked-up copy of the spec., and yes, I did miss it :-(

> Section 7.2.1:
>
> > If the resource is associated with a workspace, this
> > property MUST identifies this workspace.
>
> identifies --> identify

This was introduced since I last read that section.  Geez you'd think he
could type properly<g>

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

I'm only owning up to the plural/singual nits, the other stuff passes
muster with me.

...but there have been a few revisions since my last detailed read through
front-to-back, maybe it's time to do it again.

Tim

Received on Friday, 9 February 2001 05:49:08 UTC