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

Re: Re (2): Workspace header and optional labeling

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Wed, 11 Oct 2000 21:46:52 -0400 (EDT)
Message-Id: <200010120146.VAA19386@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Edgar@EdgarSchwarz.de

Hi Edgar, good to see you back on the list!

   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 :-)

I'm pretty sure that your question was part of the motivation for
my suggesting we change, so you get to pat yourself on the back
for that one (:-).

   I think some sort of 'labeling' should be available in core versioning.
   Sort of a poor mans baseline :-)

As a side note, I encourage servers to actually implement baselines if
they want to provide baseline functionality, and encourage clients
to use it on servers that provide it (:-).

   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.

The argument for using DAV:comment was not that it is a good/reasonable
way to provide baselining, but rather that it is a good way to add
client defined information to a version if you are *not* interested
in baselining, but rather just distinguishing versions from a *single*
version history.  If there are two versions that are tested, it is
quite reasonable to annotate them both as "tested", and use other information
to distinguish one "tested" version from another.  This of course doesn't
work with baselining, but a server that cares about baselining will
implement labels (or preferably, baselines).

   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.

If a client encounters a server that does not provide labeling
support, no need to "fake it", you just grey out the "label"
operation.  If you want labeling, just get a server that supports it,
and then it's easy for a client to expose it, since we've standardized
on what labeling looks like when it is supported.  

(I'm tempted to make an analogy about the superiority of "market driven"
economy over a "command" economy :-).

   It works now because every document management
   system that do so without the use of labels has it's matching client.

I think labeling is such a well understood concept that any DMS system
that wanted the functionality would have invested in implementing it.
They certainly would do so in their server, and not in their client.

   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).

Yeah, I was a strong advocate of Workspace headers too, until
I ran into those pesky technical problems ... (:-).

Received on Wednesday, 11 October 2000 21:47:32 UTC

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