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

Re: Complexity and Core Considerations

From: James J. Hunt <jjh@allerton.de>
Date: Tue, 06 Feb 2001 01:24:50 +0000
Message-ID: <3A7F525F.7CF0C075@allerton.de>
To: lisa <lisa@xythos.com>
CC: Tim_Ellison <Tim_Ellison@uk.ibm.com>, ietf-dav-versioning <ietf-dav-versioning@w3.org>
Lisa Dusseault wrote:

> > 1) Is the current form of the specification too complex?
> > Yes/No/Maybe. Why?
> >
> Yes.  The definitions are complex.  The language used is frequently too
> complex.
> > 2) Does there remain sufficient discussion going on surrounding
> > the OPTIONS that the draft should be split into two documents,
> > CORE and OPTIONS, so that we can move CORE forward?
> > Yes/No/Maybe.  Why?
> Yes, core should be split out.  This would force the definitions used by
> 'core' to be self-consistent even without the advanced options being
> present.  This will improve readability and expand the potential
> readership of the document.
> Tim said:
> > The only arguments for splitting the document are editorial (i.e.,
> > readbility) and process (i.e., submit separately).
> That's a straw man.  Another argument to split out is consistency.
> While it is possible for core to be self-consistent while it is part of
> a larger draft, it seems difficult.
> Another argument, related to readability is exposure/reach.  I believe
> deltaV-core will get more exposure and more readers, thus more
> comments/suggestions, and perhaps even more implementations, if it is
> broken out and clearly expressed.
> Right now, I'm afraid that despite the stated intent of the authors to
> make DeltaV suitable for document publishing purposes, the inclusion of
> so many specialiazed features and definitions will scare away document
> publishing implementors.  They'll start reading the document, see "Fork,
> Merge" in section 1.3, "Workspace Resource", "Version-controlled
> collection resource" , "Collection version resource", "configuration",
> "baseline", "activity" and "Variant" in section 1.3.1, and be put off by
> the perceived complexity.  That would be a shame.
> My experience backs this up:  we have customers, some doing client work,
> who are interested in doing document management with versioning, and
> they haven't reviewed DeltaV because the task is so daunting.
> Lisa

Dear Colleagues,

Lisa has a good point about the complexity being daunting, but I disagree
with the remedy.  This is a point were a good introduction could help.  I
tried to take a stab at this but was shot down.  My intent was to give the
reader a bit of motivation about the structure of the document.  The read
should be given some feeling up front, about what parts of the document
need to be studied to support document management, file based revision
control, and configuration management, as well as some indication as to the
choices about client vs server managed work areas.  Perhaps someone else
could take a shot at it.

Received on Monday, 5 February 2001 23:58:21 UTC

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