W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re (2): Workspace header and optional labeling

From: <Edgar@EdgarSchwarz.de>
Date: Wed, 11 Oct 2000 17:38:20 -0400
Message-Id: <200010112138.RAA10083@tux.w3.org>
To: ietf-dav-versioning@w3.org
Cc: Edgar@EdgarSchwarz.de
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:45 UTC