W3C home > Mailing lists > Public > public-forms@w3.org > January 2009

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

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 13 Jan 2009 11:24:22 -0800
To: public-forms@w3.org
Message-ID: <OF2A2A2269.F2587F08-ON8825753D.00688AEC-8825753D.006A9B11@ca.ibm.com>
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
Received on Tuesday, 13 January 2009 19:25:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:50 UTC