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:12:59 UTC