RE: Splitting off core: where we stand

I think the reason that the working group is so divided on this is
that we all have our own reasons for supporting DeltaV.  Frankly,
the fact that we have a standard document in the first place is
completely amazing, given the major differences in versioning models
in use right now.  The way the spec deals with change set vs. branching,
client vs. server workspaces, document management and source code
configuration management issues, and resolves the tradeoffs, is a
major accomplishment.

To me, splitting the document upsets the delicate balance that has
been developed by Geoff Clemm & Jim Amsden over the past few years,
and the reason for the proposed split is procedural, not technical.

Splitting the document would require enough rework to probably delay
submission by a month, as we remove all of the forward references from
Core into the option stuff, and then go through a round of nitpicking
on errors in that process.

While it is clear that Larry & others are right, that Core would go
through the standards process faster alone, it is also clear that
the options would go through much slower.  So, the time benefit of
splitting depends on the relative value assigned to the MOST important
option for each implementor, vs. the value assigned to Core.  Naturally
the people who only plan to implement Core are in favor of splitting,
since they assign a very small (if not zero) value to the options.
Plus, the cost of splitting the document must be added to the time
cost/benefit of the split standard.

Successful standards are all about the implementations (and how
interoperable they are), not the IESG.  If we have a bunch of people
out there doing implementations, with a spec that is stable, that
achieve interoperability, that is the important part.  If the content
of the spec is basically done, isn't it better to have the people on
this working group focusing more on implementation of the spec than
on rehashing its format for another month?  

Finally, to Lisa's point, I don't see how splitting
the document helps people who just want to implement Core.  I actually
think it hurts them, because they will want to interoperate with
people implementing many of the options, and if they have no clue as
to where those folks are coming from, they will have a harder time
debugging interoperability problems.  It's like trying to implement
a mail server and only understanding RFC822, without having any clue
as to what MIME is.  Yeah you can do it, but you aren't going to get
much interoperability.




-----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 Thursday, 8 February 2001 00:38:26 UTC