RE: Splitting off core: where we stand

I wanted to state that I concur with what Lisa has said.  Well stated.

	Mark




> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Wednesday, February 07, 2001 6:12 PM
> To: Jim Whitehead; ietf-dav-versioning@w3.org
> Subject: RE: Splitting off core: where we stand
> 
> 
> > (b) One of the more compelling arguments for splitting core
> > from non-core is
> > that a smaller, core specification is likely to progress to
> > RFC faster than
> >
> > (c) Another argument is the core parts will likely progress to Draft
> > standard status faster than the options will, since there will be more
> > interoperable implementations.  In this argument, what
> > happens now is not
> > nearly as important as a year from now, when it's time to
> > revise for going
> > from Proposed to Draft.
> 
> My two reasons, which I tried to express but seems to have been
> forgotten:)  are not related to speed of progression to RFC or Draft
> Standard.  They are:
> 
> 1) The core versioning specification will be much clearer if it is split
> out.  The definitions required by core will be much shorter and simpler.
> Forward references will _have_ to be removed.  Core will more likely be
> succesful stand-alone this way.
> 
> 2) More people will read and review the specification if it is (a) short
> and (b) relevant.  Right now, people may be unable or unwilling to
> review the draft, both because it is long, and because it has sections
> and terminology which will seem irrelevant and off-putting to people
> interested in a simple versioning model.  The first sentence in the
> rationale is:
> 
> "Versioning, parallel development, and configuration management are
> important features for remote authoring of Web content.".
> 
> Ouch!  Right off, some people are going to be turned off by "parallel
> development" and "configuration management" and think "I guess this
> isn't what I wanted after all, that's too bad."
> 
> Then the "terms" section is full of terms which are unneeded by somebody
> doing core; even in the supposed core section of terms there is "fork,
> merge".
> 
> Although adoption of DeltaV by implementors of document versioning (and
> other simple versioning systems) doesn't rely on the draft being split
> in two, I am sure that a large spec of daunting complexity is not a
> help.  In other words, splitting core out will encourage and speed
> review and adoption of DeltaV "core" by a wider range of implementors
> and vendors.
> 
> This last point, to me, is the real key and the most important reason to
> split the documents.
> 
> Lisa

Received on Wednesday, 7 February 2001 21:25:34 UTC