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

Hi John,

I think you are on to something. :)

Just sticking with the 'bind' module (as currently named), I'd suggest
that perhaps the key part is the dependency-graph; everything else
concerns the graph's reflection via events to the UI, and associated
CSS properties. So we might consider naming this module something more
to do with that, rather than simply 'bind', and then throwing in
everything that makes it work.

Which reminds me...a few years ago I did a paper at the W3C web apps
workshop on how a set of standardised modules might relate to each
other [1], and I called what amounts to the bind module a 'dynamic
infoset' module.

Augmenting an infoset with dynamic properties is the _purpose_ of the
dependency-graph, so this might be a better moniker. I think such a
name also reflects some of the original design goals of XForms 'bind',
that I believe existed in the early work by yourself, Roland, Raman,
and others.



[1] <>

On Tue, Jan 13, 2009 at 7:24 PM, John Boyer <> wrote:
> 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:
> Blog:
> Blog RSS feed:

Mark Birbeck, webBackplane

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Tuesday, 13 January 2009 20:45:48 UTC