W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Splitting off core: where we stand

From: Sankar Virdhagriswaran <sv@hunchuen.crystaliz.com>
Date: Thu, 8 Feb 2001 14:46:57 -0500
Message-ID: <010a01c09207$e5a24fe0$4975ef8c@crystaliz.com>
To: <ietf-dav-versioning@w3.org>

> (1) Core useful, options useless.
> (2) Core useful alone, options useful.
> (3) Core useless, core + options useful.
> (4) All of DeltaV useless.

This is one way to phrase the argument. Your argument discretizes the
choices where there is a continuum. Therefore, I would like to interject a
different conceptual view point. As I understand things, the spec. goes from
serial joint authoring support to more and more parallel joint authoring to
merge support. For those interested in supporting features that involve
parallel joint authoring, semantic consistency of the specification as it
moves from serial authoring to parallel authoring is important so that
whatever marketing decides, the engineers can digest one model of
consistency management and implement features as time permits. The most
recent note from John Vasta on this thread sort of points this out. For that
crowd (I am one of them), the fact that the specification is the way it is
helps us identify and deal with semantic consistency issues particularly
when it comes to implementation. Wading through 4 different documents is not
fun. For some one like you who has been involved in the discussions
intimately, parceling the pieces does not raise an issue due to familiarity
with the issues and how they were resolved. For some one like me who is not
tracking all the issues, who is hoping to read the spec. in detail once it
is done, I don't have any context.

In my mind, the tradeoff is between losing context and therefore
consistency/ease of implementation vs.the one-large-document digesting

Since I will be spending more time in implementation than in reading and
digesting a spec. document, I vote for optimizing the larger value.

Received on Thursday, 8 February 2001 14:46:05 UTC

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