W3C home > Mailing lists > Public > www-qa@w3.org > July 2002

Modules and levels in a specification

From: David Marston/Cambridge/IBM <david_marston@us.ibm.com>
Date: Mon, 29 Jul 2002 23:52:44 -0400
To: www-qa@w3.org
Message-ID: <OFDD21E3B2.8B7F25D6-ON85256C06.0012E4F9@lotus.com>





The QAWG wants to strike a balance between specification guidelines
that allow sufficient expressive power to the substantive WGs and yet
promote good interoperability (and testing thereof). Two ways in which
specifications can allow variance of conforming products are modules
and levels. There is some debate about how the two can interact.

Using the highly interoperable technique of Crude ASCII Art, I'll
show the issues. This document should be viewed in a monospace font.

Modules are a general-purpose way of dividing the specification or
its targets. A classic example is a user agent that can have both an
audio module and a video module, or just one of the two. In the
classic picture, modules are fully independent, like this:
+-----+-----+-----+
| Mod | Mod | Mod |
|  A  |  B  |  C  |
+-----+-----+-----+
Of course, the Specification Guidelines will state that specs should
be clear about the separation of modules.

Levels are specifically designed to represent hierarchical steps, as
in the DOM specs.
+------------+
|            |
|  Level 3   |
+------------+
|            |
|  Level 2   |
+------------+
|            |
|  Level 1   |
+------------+
Conformance to a particular level requires conformance to all lower
levels. Level 1 is the core.

XSLT may go to a hybrid: a core with optional modules:
+-----+-----+-----+
| Mod | Mod | Mod |
|  B  |  D  |  S  |
+-----+-----+-----+
|                 |
|   Core Module   |
+-----------------+
In my opinion, the above should be discussed strictly using the
concept of modules, because the hierarchical nature is very weak. One
can just say "the Core Module is required for all implementations,
and the others are independent and optional in any combination" and
effectively express the requirement without calling anything a level.

Can modules have levels within them?
+-----+-----+-----+
| Mod | Mod | Mod |
|  A  |  B  |  C  |
| Lev | Lev | lev |
|  2  |  2  |  2  |
+-----+-----+-----+
| Mod | Mod | Mod |
|  A  |  B  |  C  |
| Lev | Lev | lev |
|  1  |  1  |  1  |
+-----+-----+-----+
I think they can. Returning to our audio/video example, the levels
would be different resolutions (pixels for video, frequency response
for audio) and an implementation is free to choose a level for audio
independent of the level for the video module.

Can a level be assembled from modules? Lofton says yes, but I'm
skeptical. An example would be:
Level 1 requires the Core Module;
Level 2 requires the Core plus modules A and B
Level 3 requires the Core plus A, B, C, and (D or E)
Level 4 requires the Core plus A, B, C, D, E, and F
Notice that the levels are indeed supersets all the way up.
I think this approach uses levels as a labeling scheme for aggregates,
which is a separate design idea from levels or modules as units of
implementation. We need a labeling scheme for aggregates, so we
should discuss that. I think "profiles" may be a good choice as the
exclusive means of labeling aggregates.

Other opinions?
.................David Marston
Received on Tuesday, 30 July 2002 02:00:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 12:13:59 GMT