W3C home > Mailing lists > Public > www-qa@w3.org > August 2002

Re: Should modules be divisible?

From: Al Gilman <asgilman@iamdigex.net>
Date: Mon, 12 Aug 2002 11:22:19 -0400
Message-Id: <5.1.0.14.2.20020812102135.01de7ec0@pop.iamdigex.net>
To: (wrong string) Žl-Massieux <dom@w3.org>
Cc: www-qa@w3.org

At 10:15 AM 2002-08-12, Dominique HazaŽl-Massieux wrote:
>Le lun 12/08/2002 ŗ 16:06, Al Gilman a ťcrit :
> > At 08:58 AM 2002-08-12, Dominique HazaŽl-Massieux wrote:
> > >The current editor draft of the spec GL says:
> > >
> > >"Atomicity of modules within profiles represents a clean design, and a
> > >reflects that the modularization has been well tailored to the goal of
> > >building profiles from modules"
> > >http://www.w3.org/QA/WG/2002/08/qaframe-spec-0804.html#Gd-group-require 
> ments-modules
> > >
> > >This is said in the general verbiage of the GL about modules. I wonder
> > >if this should not be a checkpoint instead since it does bring a
> > >judgment on the design of modules.
> >
> > This kind of motherhood should be expunged from the document.
> >
> > The W3C lacks the organizational "capability maturity" after the
> > language of the CMU/SEI 'Capability Maturity Model' to ensure that
> > modules it ordains are uniformly fit to claim atomicity.
> > One can only
> > experiment with both atomic and subsettable premises in appropriate
> > contexts and make the groundrules as to what the terms of offer of
> > a module are.
>
>What about the CR phase? Isn't the right time to ensure that atomicity
>of modules make sense?

No.

>Provided that the PR entrance criteria is
>restrictive enough on the module implementation,

In CR you have all you can do to show that there are implementations
that support the simple profiles that treat the components
atomically.

And it is not feasible to make CR protracted enough to test in
the market whether the atomicity claims will stand the test of
volume use.

>I think the process
>ensures the possibility of such a claim.

Absolutely.

>And if that's the case, the QA
>framework should probably provide some guidance on this.

Not at all.

This should be at the discretion of the domain experts working
on the web aspect in question.  This is product strategy for which
there is no well-demonstrated quality rule yet and the QA documents
should be reluctant to take risky positions, sticking to a few simple
demands that are clearly worth policing.

The quality rule should indeed be that constraints (such as atomic import of
modules) that module systems wish to impose on profiles should be clearly
stated.

Viable systems of atomic modules are governed by wave equations driven by
market forces.  W3C doesn't have the knack of out-guessing these market
driven results yet.  So a policy saying "make modules atomic" is piety in
the sky.  We can't deliver on that promise, so we shouldn't make it a policy.

Promise little and deliver 110%.

Al

>Dom
>--
>Dominique HazaŽl-Massieux - http://www.w3.org/People/Dom/
>W3C/INRIA
>mailto:dom@w3.org
Received on Monday, 12 August 2002 11:22:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 12:13:59 GMT