Re: QA Spec Guidelines and Modular Technologies

It's a good topic that you have uncovered here, Karl.

For a while, I have been thinking that Specification Guidelines (SpecGL) 
concept of "specification" ought perhaps to apply to document groups larger 
than a single Technical Report.

This might be a good topic to consider during SpecGL's next review cycle -- 
an extended "CR", for trial application to W3C's TR's -- is SpecGL's 
concept of "specification" currently flexible enough that it could be 
applied to a modularized multi-part standard such as CSS3?  If not, should 
it be made more flexible, and how?

ISO has a formal notion of a multi-part standard.  I don't find that in 
W3C, although there is this interesting line in W3C Manual of Style:

"Title [(ACRONYM)] ["Specification"] ["Part" Part_Number] [: Subtitle] 
["Module"] [(nth "Edition")] ["Version" Version_Number]"

The "["Part" Part_Number]" is not explained (nor are any of the other 
bits).  Perhaps this would be a useful concept to develop further in W3C, 
given that standards like CSS3 are already going that way.

Then, SpecGL could be applied to an individual part, but in the context of 
all of the *currently published* parts.  For example, each part need not 
replicate an almost identical Conformance Clause, but an appropriate 
general-purpose one must exist in one of the published parts, and must be 
easy to find from each given part.

More comments in-line...

At 07:14 PM 8/12/03 -0400, Karl Dubost wrote:

>[...]
>I have made the review of CSS3-UI, which is a modular spec. The technology 
>becomes more and more modular with time. It has an influence on the way 
>WGs organize their Spec editing. We have moved from a monolithic spec to a 
>multiple document spec. The last big monolithic spec have been SMIL and 
>SVG, even if organized in modules.
>
>Often in this reorganization, you have a master document which defines 
>conformance, usage scenarios, etc. and the modules attached to it.
>
>For example CSS has moved from a 1-spec (css1 and css2) to a multi-spec 
>(css3).
>
>This way of writing specifications raises a very important questions on 
>the notion of 1 Recommendation = 1 Technology. It's not anymore the case.

Right.  Currently 1 Recommendation = 1 *part* of the Technology.


>1. Should a technology be considered complete when all the bricks are 
>ready. So is there a missing concept inside W3C which defines this set of 
>bricks?

Multi-part standard?

>2. Should a WD (which is a module of this set) be authorized to reach the 
>status of Rec (and even Last Call without the other bricks)?

I think yes, as long as the collection of finished parts is internally 
consistent, satisfies (collectively) the things that SpecGL requires of a 
"specification", and has no unsatisfied dependencies on unfinished parts.


>         2.1 If a module can become a Rec without other elements of the set
>                 - How do we define depencies?
>                 - How do we create usage scenarios?
>                 etc
>
>                 AND more important ***How do we apply QA Spec Guidelines?***
>                 There's a big issue here. We can't for example find the
>                 conformance section because sometimes it's in a
>                 document which is not written yet.

I suggest:  apply SpecGL to each part, in the context of all finished 
parts.  In the case that the Conformance Clause is missing, because it is 
in an unfinished part ... this is a critical failure.  "Dependencies" and 
"usage scenarios" are important details, but IMO we could sort them out if 
we agreed on a conceptual approach (e.g., consider the part in the context 
of the multi-part).


>         2.2 If we think that a module can NOT become a Rec without others 
> elements of the set.
>                 - How do we create the mechanism in the process document 
> that specify this.
>                 - We have to check that QA Spec Guidelines is working 
> well with modular docs
>                 Notion of table of contents, references, etc.
>
>Should this be discussed to the chairs mailing-list?

Perhaps.

But maybe we should explore it some more in QA first?  Possibly, a 
potential solution is not very difficult.

Regards,
Lofton.

Received on Friday, 15 August 2003 14:21:36 UTC