Versioning Goals feedback

Here is my feedback on the latest goals document for WebDAV Versioning.

Definition #2 - Versioned Resource - We don't specify that this is an
actual object, but later in the goals we refer to it having a URL. 
Also, is it or is it not intended that this resource would have specific
properties that represent the entire set of revisions?  For instance, in
our DMS we allow a document owner to specify an "Official" revision,
which may or may not be the latest.  A label could be used, but I would
like to get such a property from a central place (the Versioned
Resource) rather than have to search for the label across all
revisions.

Definition #4 - Working Resource - It says a "working resource can
become a new..."  The meaning of 'can' isn't clear to me.  Is this a
may-or-may-not?

Definition #8 - Label - The definition isn't clear on the uniqueness. 
I believe the uniqueness applies only within a single versioned
resource, not across any larger namespace.  One of the goals makes this
clearer by stating that a given label may be used on revisions of
multiple versioned resources, so the definition ought to clarify
"uniqueness."

----------

Goal #1 - Right near the end it states "a non-versioning aware client
should be able to PUT to a versioned resource and have a new revision be
automatically created."  I agree with this, but want to make sure that
somewhere we clarify what this really implies, or simply state that the
server can deal with this however it desires.  If a server supports
this, how does that interact with what others may be doing with that
resource?  The non-versioning aware client is blind to the intricacies
of activities and configurations, and it seems this will present some
problems we may need to consider.

Goal #1 (again) - The last sentence says a subsequent GET on the same
versioned resource by this client should return the new version.  How
can this be guaranteed?  What if the PUT forced a branch?  How does a
GET know what branch if the client is non-versioning aware?

Goal #11 - This should not specify HTML, but rather indicate any
document that contains URL links should be able to use relative URLs.

Goal #13 - This sounds too much like we are setting a DASL
goal/requirement.  Can we word this such that it is clear that
Versioning needs to make these properties conform to DASL such that a
DASL query automatically has access to this info.  Or does our
requirement truly require something to be added or changed in DASL?

Goal #14 - Let's get rid of the "DM / CM" distinction and just go with
"Level 1" and "Level 2" versioning.  Then I would reword this goal to
something like, "It must be possible to implement Level 1 versioning
without having to implement any part of Level 2 versioning."

Goal #15 - Immutable Properties are never defined.

Goal #15 (again) - The last sentence of the goal portion, "It must be
possible to determine...", sounds like a separate goal.

Goal #15 (again) - Is there an important reason why mutability is being
defined at the revision level?  Why not greatly simplify and declare
this at the collection level?  I think it is very confusing to mix
within a collection, and having to check this on every resource I access
seems cumbersome.

Goal #17 - I don't agree with this.  Why can I not delete a given
revision while leaving the rest intact?  For CM there are probably valid
reasons, but 1) in the DMS world this is done frequently, and 2) what if
I just want to clean up some old, non-important part of the set?  I
frequently delete older revisions but rarely delete newer ones.

Goal #23.1 - Some systems, if they support versioning, have no concept
of an unversioned resource and a versioned resource.  When a new
document is created it is, from its inception, a versioned resource with
a single revision.  The goals & protocol need to support this type of
environment.

Received on Wednesday, 17 February 1999 13:56:28 UTC