- From: Lofton Henderson <lofton@rockynet.com>
- Date: Tue, 30 Jul 2002 18:35:38 -0600
- To: David Marston/Cambridge/IBM <david_marston@us.ibm.com>
- Cc: www-qa@w3.org
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