- From: Lofton Henderson <lofton@rockynet.com>
- Date: Mon, 12 Aug 2002 10:20:13 -0600
- To: www-qa@w3.org
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