Re: Are modules really a DoV? and levels/profiles?

At 03:50 PM 10/18/02 +0200, you wrote:
>[sorry, this is yet another very long (and boring) email. It does ask
>important questions, though]
>
>Greetings,
>
>As I'm in the process of editing QA Framework Specifications Guidelines
>(SpecGL) [1] in preparation for an upcoming publication in TR space,
>I've come across the dimensions of variability (DoV) [2] issues one more
>time.
>
>1. http://www.w3.org/TR/2002/WD-qaframe-spec-20020826/
>2. http://www.w3.org/TR/qaframe-spec/#dimensions-of-variability
>
>As defined in the current TR version of the SpecGL [3], dimensions of
>variability are "the ways in which different products that are
>conformant to a specification may vary among themselves".
>
>3. http://www.w3.org/TR/qaframe-spec/#definitions
>
>But in that definitions, do modules really fit as a dimensions of
>variability?

Two general responses:

1.) although the current discussion in SpecGL perhaps blurs some 
distinctions that ought to be made, yes, I think that modules are a 
dimension in which conformance definitions may vary (note *may* in the DoV 
definition);

2.) this issue definitely needs discussion and clarification, but I'm not 
sure that we can finish it in the two weeks before SpecGL publication.

A couple of other comments...

>Let's consider 2 cases:
>1. a module is designed only to be part of a larger conformance scheme:
>e.g. XHTML 1.1 Text [4] module is only defined to be part of an XHTML
>1.1 Host language [5];

...which is really a profile.  But to be strictly accurate, a module can 
enter into other profile definitions by whoever wants to define a 
profile.  "Host language" is XHTML's view of a *good* profile, i.e., an 
XHTML profile is a Host Language if it meets XHTML's enumerated rules for 
profiles.

>CSS3-color [6] is only defined to be part of a
>CSS profile (as CSS TV [7])
>2. a module is designed with its own conformance scheme; e.g., an
>implementation can conform to DOM-Level-3-XPath [8]
>
>In the 1st case, since you don't expect anyone to conform to your module
>per se (an implementation will conform to a set of modules), having a
>module doesn't affect directly an implementation, and hence cannot be
>counted as a cause of variations between conformant products.

In this sense, modularization exactly meets the definition of DoV.  It is 
actually the principal principle behind this (modules/modularization) 
dimension, IMO.


>In the 2nd case, it is questionable that a module in that meaning is
>different in any way of any other specification: it has a conformance
>clause, and the fact that there are other modules (as DOM-Level-3-Events
>in our example) doesn't affect the conformance to this specification: 2
>products conforming to DOM-Level-3-XPath do not vary in their
>conformance to this module because of the fact that one may conform to
>DOM-Level-3-Event and the other not so.

#2 is a variation that we do not clearly address -- intra-module 
conformance variability.  It would be worth clarifying.  You seem to imply 
that intra-module variability is not really a consideration.  But I know 
that David, for examples, thinks that levels might divide modules.  If he 
is right, then there is one form of intra-module variability.  I could see 
that modules might interact with other DoV as well.  (Hmmm, in fact what I 
seem to be saying is that intra-module conformance variability is probably 
a consequence of the effect of another dimension from amongst the DoV, 
acting within the module.  However... see below for more opinions on 
interactions.)


>So, my question is: do modules really define a relevant dimension of
>variability?

Yes.  By assembling modules in different combinations, different 
conformance objects result.


>I don't think they do, but would like to get others' feedback on this.
>
>I think however they raise another important issue, which is
>interdependencies between specifications (module A needs module B;
>profile X include modules Y and Z; Level N is composed of module O and
>P) that we ought to address, but I don't think they fit well in the DoV
>framework.

I thought that we had decided at Tokyo that we would discuss possible 
interactions and relationships (in Extech) -- attributes, pros and cons, 
commonly used relationship, pitfalls, etc -- but would not try to legislate 
any particular relationships.  Am I missing your point here?


>Another argument that Alex raised earlier also makes me think that we
>should not enclose ourselves in a too formal divisions of
>interdependencies (modules/levels/profiles), since these
>interdependences may or may not be indicated using one of these formal
>names.

See issues 74, 75, 76:

http://www.w3.org/QA/WG/qawg-issues-html#x74
http://www.w3.org/QA/WG/qawg-issues-html#x75
http://www.w3.org/QA/WG/qawg-issues-html#x76


>For instance, one could argue that Namespace in XML 1.0 is a module of a
>generic XML Processing framework, as would be XML Include, XLink, XML
>Base, etc. For various historical and maybe political reasons, none of
>these bear any mention of being a module, but they would probably
>benefit from the rules designed for modules in SpecGL.
>Another limitation of our division appears in the fact that more or less
>levels are getting superseded by profiles in recent W3C specs (even
>though in a yet difficult to understand way, CSS3 seems to use modules,
>profiles AND levels).

Such discussion (about XML family) might be useful in Extech -- point out 
that there is W3C practice which matches the concept, but not in name 
(i.e., XML could have been designed as a family of modules).  What you are 
pointing out here is a big lack of uniformity within current W3C 
practice.  I don't think that we should try to encapsulate or standardize 
that -- we're trying to standardize "the best of current practice", and 
(issue #77) we're aiming at new work.

(Maybe someone should make a comment to "Blueberry", about a modularization 
perspective?)


>In summary, I'm looking for feedback on:
>- the relevance of modules, profiles and levels as DoV
>- splitting the current DoV framework into a real DoV discussion
>addressing the use of product classes, discretionary items, extensions,
>conformance policy, deprecation and an interdependencies discussion
>addressing among other things the relations that implies the usage of
>modules, levels and profiles.

So far, I'm having trouble seeing a distinction strong enough that it would 
warrant treating mod/prof/level differently.  They still seem like a 
conformance variability dimension to me, although they correspond to 
division or partitioning of the technology (which distinguishes them 
somewhat from the others).  However, it might be an interesting idea to 
pursue -- with a detailed outline or TOC (down to the ckpt level) for the 
next document cycle.

-Lofton.

>- ideas of checkpoints relevant to these discussions
>
>Thanks,
>
>Dom
>
>4.
>http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_textmodule
>5.
>http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_document_type
>6. http://www.w3.org/TR/css3-color/#status
>7 .http://www.w3.org/TR/css-tv#section-conformance
>8. http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#Interfaces-h2
>--
>Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
>W3C/INRIA
>mailto:dom@w3.org

Received on Monday, 21 October 2002 10:40:12 UTC