Are modules really a DoV? and levels/profiles?

[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? 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]; 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 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.

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

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. 

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.
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).

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.
- 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 Friday, 18 October 2002 09:51:02 UTC