Re: Specifications containing modules (e.g. XForms Binding Specification, XForms Functions Specification,...)

+1

I suggested something similar before the Amsterdam f2f and still think it's
a good idea.  Another candidate for consolidation is in the data
model/instance modules.

We can still write them to be usable alone (island) but simplify the
editing ...

Charlie
 -----John Boyer <boyerj@ca.ibm.com> wrote: -----

 =======================
 To: public-forms@w3.org
 From: John Boyer <boyerj@ca.ibm.com>
 Date: 01/13/2009 02:24 PM
  Subject: Specifications containing modules (e.g. XForms Binding
 Specification, XForms  Functions Specification,...)
 =======================
 Dear Forms Team,

Developing new things using small, incremental specs each containing one
idea or module seems like a good idea.

However, when you already have a monolithic system that you are
refactoring into modules, it can be too much work and take too long to
refactor in a way that makes it look like you did it in the above way to
begin with.

This seems to be one reason why we are not getting much velocity in the
XForms 1.2 modularization.  Another is that I think we may be going
overboard with a Procrustean approach of one spec per module, which
creates in some cases somewhat artificial decouplings that are just plain
harder to write around and in other cases just more admin work for no real
benefit.

I'd like to propose we take a different approach.

Just thinking back to last week's telecon discussion about the XForms bind
module, you may recall Nick indicating that it was hard to write the bind
module and talk about MIPs without talking about any actual MIPs.  I
agree.  I really think what we need here is to consolidate a few of the
modules into a specification that makes sense and is worth reading as a
unit.  Conformance can still easily be specified on a per module basis,
but a number of these modules work particularly well together so it would
be no surprise to find that most implementations contain more than one
module from the specification.

To some extent, this was the approach on the XForms functions.  All the
functions from XForms that might be applicable across all modules are
placed in the one specification, but it is divided into sections based on
the kind of function.  A little more effort could be used to indicate that
these sections are representative of function modules, but splitting these
into four specs just seems to be going overboard on admin work for no real
benefit.

In the case of the bind module, I think the case for consolidation is even
more compelling.  I think we actually need an "XForms Binding"
specification comprising the binding attributes module, the bind module,
and one module for each of the current MIPs.

This may be the kind of move we need to make it easier to modularize what
we have by increasing the amount of content we can import as opposed to
substantially rewording.  It'll still be a lot of work, but I think we
need to do something differently if we're going to get some real progress
here.

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw