- From: <Tim_Ellison@uk.ibm.com>
- Date: Thu, 8 Feb 2001 12:15:49 +0000
- To: ietf-dav-versioning@w3.org
> > Just to be pedantic for a minute, if the client > > was totally versioning unaware then they would be > > unaware that versions of the resource exist, or > > the need for "global" properties. A versioning > > unaware client would set a dead property on an > > autoversioned version-controlled resource, and > > that would be carried forward through subsequent > > versions of the resource. > > But they would be aware of the need for a property > like "Editor-in-Chief", they may need to get or set > the value of this property. I don't understand your point. Assuming a versioning unaware client, what characteristics of the property could they expect that are not provided for by RFC2518? > > Ok, so if a client was, say, versioning aware (i.e., > > knows versions exist) but versioning challenged<g> > > (i.e., cannot make versioning calls) then they > > could query the DAV:version-history property of > > the VCR (using PROPFIND) to get to the version > > history resource and set properties there (using > > PROPPATCH). It would not require any versioning > > specific methods to implement the "global" properties. > > But they would also potentially know about the property > "Editor-in-Chief". And the versioning-aware client > can look at past versions, where the "Editor-in-Chief" > property really should not have a different value. You missed my point, the property would be on the version history resource, but does not require any versioning specific methods to get or set. > So how are the two clients supposed to use the same > property interoperably? A versioning unaware client would have no such expectations for a property like this. Please explain further, I feel I'm missing it. Tim
Received on Thursday, 8 February 2001 07:19:53 UTC