Re: Editorial thoughts on qaframe-spec

I'll combine my comments on two of Dom's messages.  From yesterday...

At 06:51 PM 10/14/02 +0200, Dominique Hazaël-Massieux wrote:
>[...]
>As now I have to work on the DOV GL (currently GL 3,4 and 7), I have
>thought of a new way to understanding these GL and would like to get
>feedback on this, especially from Lynne and Lofton. The current pb is:
>- we have had difficulties separating what concerns the technology and
>what concerns the specification in GL 3, 4, and 7
>- some CP speak about entries in TOC, but it's not clear to which TOC
>these CP apply; in the case of profiles, this could be the "main" spec,
>a specific profile, the rules for profiles

Right, as I mentioned yesterday, we have been ignoring a basic reality of 
W3C specifications:  the divisions of technology which are in effect may 
not align neatly with packaging and possible partitioning of the 
specification(s).

I had been thinking that we could get rid of the 8 separate but identical 
TOC checkpoints by combining them into one.  But then the problem comes up, 
as you mentioned:  which TOC, if all of the relevant bits (technology 
and/or conformance divisions) do not reside in the target ("current") 
specification?

Generically, and ignoring the badness of the subjective untestable 
language, what we want to say is:  starting at the TOC, it should be easy 
to find ... [...info on any of the 8 DoV...].  I think David expressed it 
this way a while back.

One way of thinking of it is that there is a "virtual document" -- this 
target document and the others that it is tightly normatively bound 
to.  E.g., the base standard, its (possibly separate) modularization, its 
(possibly separate) profiles definitions, etc.

That abstraction is probably too complicating.  We ought to be able to 
express it clearly by considering the target document and normative 
dependencies on any tightly-bound "foundation" documents.


>My view on this is that we are actually treating the same way 2 very
>different issues:
>- specifications defining one or more [modules,levels,profiles]
>- specifications "using" (that is, inheriting features defined by) one
>or more [modules, levels, profiles]
>
>The confusion between the 2 issues is easy to make since often, a
>specification matches this 2 categories (e.g. CSS TV Profile defines a
>profiles, using CSS Modules).

There are all sorts of different and reasonable combinations.  SMIL20, for 
example, defines modularization and two initial profiles (built on modules) 
in the same document.


>A related issue that we don't clearly address but that we probably
>should is the question of subsetting a specification (does the spec
>allow it? if yes, under what rules? ...)

By subsetting, do you mean partitioning the specification into pieces 
(e.g., base standard, modularization, profiles, subsequent levels, etc)?


>I'll try to see if I can find a good way to match this in a new
>structure for GL 3, 4 and 7, but any comment in the meanwhile is
>welcomed :)

So, onward to your message of today...

At 09:43 AM 10/15/02 +0200, Dominique Hazaël-Massieux wrote:
>[...]
>Here is how I see we could get out of our GL mixes:
>* for each subsetting DOV (module, profile, level) *defined in the
>spec*, have a set of CP requiring
>-> documentation of the architectural design behind it
>-> inclusion or normative reference to conformance rules per product
>class
>-> additional constraints per product class
>-> cross DOV relationships

I think the combination of "defined in the spec" and "inclusion or 
normative reference" is the key to solving the problem.  We should be able 
to craft "easy to find" language

>[This is more or less what's already in the GL 3,4 and 7 but do not rely
>on equivalence spec<->techno.]
>
>* a generic GL on guidance for subsetting a spec:
>-> indicate if there are constraints on re-using parts of a spec; if
>there is so, provide a conformance section of derived spec (or more
>generally, make sure you consider specs as one of the product class
>addressed by your spec) and try to use a DOV approach for that

I'm not sure I understand this bit.  Can you give an example?

Are you thinking that:
1.) SpecGL should have some specific additional rules as focused as CK3.6 
(the "Rules for Profiles" rule), wherein SpecGL requires a target spec to 
define rules for its descendent (or derived, or...) specs?  Or,

2.) SpecGL should have a general catch-all rule that requires target specs 
to address rules and constraints applicable on their descendent (or 
derived, or...) specs, about how those latter specs must/should/may 
partition or subset?  Or,

3.) (one less level of indirection) SpecGL itself should have a set of 
rules that relate the partitioning of target specifications and their 
descendents (separately released documents) to their divisions of 
technology (modules, profiles, maybe other DoV)?

(It is hard to talk about clearly, when you get a level of indirection like 
CK3.6 or #1 or #2 -- SpecGL rules that require specs to make rules about 
follow-on specs.)

On partitioning/subsetting (other than CK3.6), I'm thinking maybe that 
SpecGL need only contain "direct" rules (#3).  The main rule that comes to 
mind is: each separate spec (if a piece of a larger spec family, or part of 
a compound spec) must either contain or have normative reference to all 
conformance requirements that are needed to fully implement it, and to make 
it testable.  SpecGL need not require this rule to also be present in a 
target spec, as implied by "specs as one of the product classes addressed 
by your spec".  There could be informative discussion in the target spec, 
about future specs that normatively re-use the target spec -- a reminder of 
the SpecGL rule(s) -- but does the target spec need to serve as a "SpecGL 
proxy" by relaying SpecGL's rules to its follow-on specs?

Possibly I am misunderstanding the intent behind this bit.

(Also, Kirill's review of SOAP Attachments -- circulated this morning -- 
may indicate that something like #1 or #2 is in fact appropriate.)

>-> more? if not, I need to find where to insert the CP into an existing
>GL probably

This latter and the preceding bit sound like parts of a single issue, 
unless I am misunderstanding the preceding bit.

>* a generic GL on importing a spec (by normative ref):
>-> respect existing rules
>-> document implied conformance per class of product
>-> specify any additional constraints
>
>I haven't yet decided if GL 3,4 and 7 should be merged in this new
>design, or if we should keep them separate for sake of clarity. If the
>latter, I would like to have them adjacent in the document.

My opinion:  keep separate, and make adjacent.   It was much too messy when 
they were combined (in 15-may version).


>It's probably a good idea to discuss this new model and its related
>questions at our teleconf Wednesday.

Absolutely.

I think we should also get WG feedback on your in-progress editing.  From 
the edit-styled version, we should hear opinions and get consensus on the 
general level of cutting, transfer to Extech, etc.

-Lofton.