- From: <Tim_Ellison@uk.ibm.com>
- Date: Tue, 16 Jan 2001 09:37:34 +0000
- To: ietf-dav-versioning@w3.org
Pls see <tim> below. > - Highlight in Chapter 6 that the 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. > > 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. 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. <tim> The properties are not inherited (so it is good that this is not 'obvious' :-) The additional property is described in 7.2 as part of the Server-Workspace Option. My objection to your sentence is that it further implies that the DAV:workspace property is particular to certain resource types, and it is intended to apply to *any* defined type. </tim> is clear as to what the property is and when it is set in the context of the working resources creation. I feel that a client usage discussion would actually make the Draft Specification harder to read. 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. <tim> I agree with your observation, and agree that such a 'client usage discussion' would not be appropriate in the spec. </tim> Tim
Received on Tuesday, 16 January 2001 04:38:32 UTC