Re: Workspace header and optional labeling

I believe that these issues should be discussed on the mailing
list during the last call period, and not deferred to a discussion
at the Dec working group meeting.  Certainly, any issues that cannot
be resolved on the mailing list should be discussed at the Dec working
group meeting.

<jra>The mailing list is a great place to capture, discuss, and resolve
issues. But the working group meetings are often attended by a broader
community. To get a little broader coverage, some issues should be
discussed in this community, especially when there are conflicting views
presented on the mailing list.</jra>

We explicitly decided to not discuss leveling over a year ago,
since it didn't make sense to discuss what functionality belonged
in what level until we had actually settled on what functionality
we would supporting.  Over the last year, the design effort has been
primarily focused on firming up the details of advanced versioning
support, which are primarily of interest to configuration management
system providers.

<jra>We have never really given up on leveling. We just renamed to to core
versioning and advanced options because there appeared to be little
agreement on what the levels should be. This is fine. My only point is that
its interesting to note that optional labels never came up (that I can
remember).</jra>

Now that the dust has settled, and we have received a very thorough
review from a document management provider, I believe we need to
take that review very seriously.  The fact that configuration
management providers are happy to provide labeling support is
to be expected, and is therefore neither very surprising nor
especially interesting.  If we want document management system
providers to implement the versioning protocol (and I certainly do),
we need to set the "functionality bar" at a level appropriate for
document management.

<jra>There has been DMS representation in the DeltaV working group and on
the design team. Of course, not every DMS was represented. But we have
included many concepts and compromises to accommodate DMS systems. Perhaps
optional label support is another. But I think its a little like saying we
want optional user-specified URLs for resources. I'm willing to consider
making labels optional, but I would like to challenge the assumption that
including them in core is setting the bar too high. I have designed WebDAV
interfaces to two versioning management systems that didn't support
labeling as specified by the protocol. Both designs supported labels. I
just hid them in my own server-defined properties.</jra>


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

<jra>This does not sound like either an adequate, optimal, or interoperable
way of distinguishing revisions of the same versioned resource.
DAV:verion-name might not be meaningful to a user, might not be used on
more than one versioned resource, and can't be moved.
DAV:creator-displayname is not unique to a revision. Relying on DAV:comment
to distinguish revisions would introduce the possibility of parsing comment
strings to identify a revision. This doesn't sound convenient or
interoperable. DAV:getmodificationdate has no logical meaning although is
is sometimes useful to identify revisions by when they changed. Custom
client defined properties would not result in an interoperable solution.

Lisa, of the versioning repositories you surveyed, which ones are planning
on implementating a WebDAV interface? Of those, how many would like to have
label support if there was some convenient way to provide it? Could labels
be persisted in a server-defined property? Would it be OK for the WebDAV
server implementation to do the labeling semantics, and just use the
underlying DMS repository for persistence?</jra>

Received on Wednesday, 11 October 2000 17:14:36 UTC