RE: Complexity and Core Considerations

> 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

Received on Monday, 5 February 2001 18:00:03 UTC