Re: Modules and levels in a specification

David,

Very nice contribution, thanks.  Comments in-line...

At 11:52 PM 7/29/02 -0400, you wrote:

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

Yes.  I think that some of the debate arises from the tension between ideal 
design, and "design by historical accident".  I.e., when the XYZ WG wrote 
XYZ 1.0, they didn't really anticipate 2.0 and 3.0 (until maybe late in 1.0 
dev't cycle, when they realized all of the good stuff remaining to be done.)

IMO many of the existing levelled specifications are historical, not 
planned.  And those have led to some creative configurations.  That 
notwithstanding, we have to accommodate them in our model.


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

By "about the separation of modules", I assume that you mean "clarify 
whether they are separate or not".  As opposed to, specs should "clearly 
require that modules be separate".  Separation is the classical picture, as 
you say, but common practice support non-classical configuration, e.g., 
from Ch.2 of SMIL 2.0:

"The modules may be independent or complementary. For example, the 
SyncMaster module requires and builds upon the SyncBehavior module, but the 
PrefetchControl and SkipContentControl modules are independent from each 
other. In addition, some modules require modules from other functional areas."


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

I agree, weak hierarchy -- stick to modules.  I would at this place 
interject and replace "core module" or "mandatory module" with "core module 
set" or "mandatory module set".  Examples.  SMIL 2.0 (host language core 
set of modules), XHTML Modularization (ditto), SVG 1.1 (ditto).

By the way, my perspective on modularization is heavily influenced by these 
three, and I'd like to hear of some different approaches or 
structurings.  Anyone?


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

This seems reasonable.  It would almost certainly be "by design" -- 
unlikely that you could historically retrofit something this clean unless 
you planned it in advance.

Btw, this is only vaguely related, but XHTML talks about the evolution of 
modules, and requires that they have to be given unique identifiers.  That 
is tantamount to:  they become different modules, even if the change is 
pure accretion of new capability.  It (XHTML) is explicit that the old and 
the new co-exist and both remain available.

>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

Here is where I think historical accident could enter.  XYZ 1.0 (or 2.0) is 
modularized, 3.0 enriches 2.0 by adding a couple of modules, 4.0 enriches 
again by adding more modules.

Does anyone know an example of this?

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

I would agree and choose profiles, if planning cleanly from the start (with 
good foresight).  So do we say (in SpecGL), "best to plan it this way", 
while being aware that it might "evolve that way" (or might have already 
evolved 'that way')?

-Lofton.

Received on Tuesday, 30 July 2002 20:32:37 UTC