Re: Should modules be divisible?

Clearly, QAWG should enter an issue about "atomicity of modules".  I'll do 
that.

Almost certainly, we will not be able to resolve it before publication of 
SpecGL in 2 weeks.  But that is okay -- the purpose of the next publication 
is precisely to flush out discussion and issues like this.

Other comments in-line...

At 04:15 PM 8/12/02 +0200, 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.

I agree that it shouldn't be worded like that.  It is something of a 
placeholder (and red flag!), documenting a loose QAWG consensus about 
atomicity of modules.  "Rules for Profiles" in several standards define 
such a requirement -- XHTML does it, SMIL does it, CSS does it, SVG1.1 has 
the rule but it is broken by some profiles in Mobile.

Exactly what it means is:  if you define a profile of one of these 
languages, you must observe atomicity in order to earn a label like "Host 
Language Conforming Profile".  It is implicit -- but never said explicitly 
-- that these profiles are "good" according to criteria defined by each of 
these respective WGs.  Of course, that doesn't mean that someone can't 
define a profile contrary to the rule.  It just means that the profile 
doesn't get the WG's classification.  I see it as a means for these WGs to 
provide guidance towards what they consider to be good design.

So for the pending SpecGL publication -- recognizing that we won't resolve 
the issue before then -- we have several options:

0.) leave it alone, let others comment, with the recognition that we'll 
address and resolve before following publication.
1.) Change the motherhood phrasing to a SHOULD phrasing, to reflect the 
existing loose QAWG position, and leave it at that until following publication;
2.) Have a priority 1 (p1) checkpoint somewhere. "Address atomicity of 
modules."  In other words, specifications must consider the question, 
described and justify their choices.
3.) Have a p2 or p3 checkpoint, "Ensure that modules are atomic [when 
assembled into profiles]."

In all options, we can and should flag the existence of the issue.

> >
> > 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? Provided that the PR entrance criteria is
>restrictive enough on the module implementation, I think the process
>ensures the possibility of such a claim. And if that's the case, the QA
>framework should probably provide some guidance on this.


-Lofton.

Received on Monday, 12 August 2002 12:20:09 UTC