Re: Complexity and Core Considerations

   From: Tim_Ellison@uk.ibm.com

   The only arguments for splitting the document are editorial (i.e.,
   readability) and process (i.e., submit separately).  Since the
   document has been restructured it is easy for a core developer to
   ignore the optional parts.  I just don't buy Jim W's comments about
   problems with having to skip forwards to read the Sections 15-22,
   grief, if a developer cannot sort that out then I don't want to
   entrust my data to any server they are writing!  I'd like to get
   the optional sections submitted so that people who have declared
   their intent on this list can make things happen.

   So, 'no', don't split the document.

Good points.

Another reason to keep them together is that we have been so stringent
in removing any "forward references" from the core section to any
optional section (the only reference is to the "version history
option").  If core and options are in one document, at least the table
of contents provides a minimal roadmap for someone reading the core
section and confused about the absence of some key concept (such as
labels or an explicit CHECKOUT/CHECKIN method).

With this in mind, I go from being "neutral" to being strongly
in favor of keeping the options with the core in one document.

Cheers,
Geoff

Received on Monday, 5 February 2001 10:11:43 UTC