- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Wed, 17 Jan 2001 07:15:11 -0500 (EST)
- To: ietf-dav-versioning@w3.org
OK, I (finally :-) get it. The section on working resource properties should enumerate the properties that a working resource can have, rather than requiring a person to scan through the protocol to find them. I'll add this enumeration to the working resource property section, and make sure to include DAV:workspace in that list. Everyone OK with that? Cheers, Geoff From: "Mark A. Hale" <mark.hale@interwoven.com> Date: Tue, 16 Jan 2001 22:16:04 -0800 I think that we have now strayed off from the original intention based on the teleconference last Friday. At that time, it was agreed that the DAV:workspace property is a property of all resources that are in the workspace. A working resource is one such resource which can be in the workspace. When reading section 6.1, it says that a "working resource has all of the properties of a checked-out version-controlled resource". I requested on the teleconference for the simple addition to 6.1 specifically stating that one of the properties can be DAV:workspace for clarity and it was agreed. There are places throughout the draft in which clarifications are added and I feel that this aids in clarity and fully conforms to the specification as written. Thanks, Mark > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M. > Clemm > Sent: Tuesday, January 16, 2001 8:28 AM > To: ietf-dav-versioning@w3.org > Subject: Re: DeltaV Draft > > > > From: "Mark A. Hale" <mark.hale@interwoven.com> > > > I agree that a server that supports both workspaces and working > > resources might reasonably make such an association, and a server is > > certainly allowed to set a DAV:workspace property on a working > > resource (since any resource can have a DAV:workspace property) but > > what would a client do with this property value (i.e. what > > interoperability would we get by highlighting this fact)? > > We've already got a complex spec, so I try to leave out anything > > that doesn't directly contribute to interoperability. > > Per our telecon, it was non-obvious to an implementer that the > properties > are inherited. > > As Tim pointed out, its probably best to avoid the term "inherited" > here. The protocol states what kind of resources have what kinds of > properties. It states that any resource can have a DAV:workspace > property; therefore, since a working resource is a resource, a working > resource can have a DAV:workspace property. > > I feel that adding a sentence or two like the following: > > A server may set a DAV:workspace property when a new > working resource is created. The property is asserted > by servers that utilize server-managed workspaces for > resource management. > > is clear as to what the property is and when it is set in the > context of the working resources creation. > > I don't see that this statement by itself would lead to any > significant interoperability. Although it hints at what this property > could be used for, it doesn't provide anything that an interoperable > client can count on for it to mean. > > I feel that a client > usage discussion would actually make the Draft Specification harder > to read. > > I agree. My request for a client usage scenario was for us to > understand what you wanted it for, not for insertion in the protocol. > > A client can use this property-value to its advantage for a number of > reasons: it can initiate a single cleanup instruction to the server by > asking for a workspace deletion, the client can decide to > generate the next > working resource in the same workspace in order to due > synchronization in > off-line editing, and others. > > An interoperable client can't do any of these things unless the > protocol requires specific behavior that produces this result. For > example, we could add a postcondition to the DELETE method that says > "whenever a workspace is deleted, all working resource that identify > that workspace in their DAV:workspace property MUST be deleted". > > Perhaps that is the change you'd like to see in the protocol? > Assuming it is, do people agree that this is something that should be > in the protocol? I'm a bit concerned about adding storage cleanup > semantics into the protocol, since this tends to be a very > implementation dependent area. > > Cheers, > Geoff
Received on Wednesday, 17 January 2001 07:16:06 UTC