- From: <Edgar@EdgarSchwarz.de>
- Date: Wed, 11 Oct 2000 17:38:20 -0400
- To: ietf-dav-versioning@w3.org
- Cc: Edgar@EdgarSchwarz.de
Hi, I didn't have time to follow the discussion for some months, so perhaps I'm not uptodate on all arguments. What I noticed with the recent draft it the 'revision' was replaced by 'version'. I remember that I asked sometime why 'revision' was used. So well done :-) geoffrey.clemm@rational.com wrote: >I have not seen any rebuttal to the recent arguments (only your >initial messages in favor of requiring label support by all servers). > To summarize the recent arguments: > > The combination of standard client defined properties like DAV:comment > and DAV:creator-displayname, custom client defined properties, and > standard server defined properties like DAV:version-name and > DAV:getmodificationdate, are sufficient to name and locate versions of > interest, and this is demonstrated by the document management systems > that do so (without the use of labels). I think some sort of 'labeling' should be available in core versioning. Sort of a poor mans baseline :-) Perhaps it is possible to get a similar result with DAV:comment, but I imagine that more than one label could be stuck to one version. So won't that be a little bit confusing and complex if I label with DAV:comment. Also I understand DAV:comment (perhaps wrongly) as comparable to the RCS log string you can give to a new version. Labels aren't too complicated to implement in comparison to other things I guess. If labels aren't in core versioning then I fear that different clients would perhaps find different ways to implement pseudo labeling which could hurt interoperability. It works now because every document management system that do so without the use of labels has it's matching client. Just some brainstorming without too much thinking. It's late already. So I will stop and give just a short comment on workspace headers. I really wouldn't like to give them up because IMHO workspaces are a central concept in advanced versioning. And it would be a shame to hide them in the protocol. But I have to think about the technical problems Geoff mentioned (The stuff about server extension responsible for namespace subtrees). Cheers, Edgar -- edgar@edgarschwarz.de http://www.edgarschwarz.de * DOSenfreie Zone. Running Native Oberon. * Make it as simple as possible, but not simpler. Albert Einstein
Received on Wednesday, 11 October 2000 17:38:20 UTC