- From: Bruce Cragun <BCragun.ORM2-1.OREM2@GW.Novell.com>
- Date: Tue, 16 Feb 1999 09:47:27 -0700
- To: <w3c-dist-auth@w3.org>
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