Re: profiles/modules/levels -- 2 of 2

Preface:  it is worthwhile to look at our prevous (non-LC) issues about 
modules/profiles/levels:  #73, 74, 75, 76...

[0] http://www.w3.org/QA/WG/qawg-issues-html#x73


At 05:15 PM 4/22/03 -0400, you wrote:

>Lofton's extended analysis makes me think that levels are the weak DoV
>in this scheme. One could say that modules may or may not have a subset
>(hierarchical) relationship, and that profiles may or may not have a
>subset relationship, then do away with levels. BUT I don't think that's
>a good idea. Levels are a separate DoV because we think that modules
>and maybe profiles could have them.

Two points:

1.) the vice-versa relationships could pertain as well.  Earlier drafts of 
SpecGL discussed possible relationships.  We took a position a while ago 
that we will NOT try to legislate good/bad relationships (issues 73-76, 
[0]).  But rather, discuss possible relationships and document them with 
examples, if we could find any.  The "old" links in my "2 of 2" message 
show some of this verbiage/examples.

2.) Actually, I'd say levels are a separate DoV because the concept, as we 
have defined it, corresponds to a certain body of practice, albeit (as you 
say) a weaker body than others.  That is certainly the history of "levels" 
in the original combined GL of the initial SpecGL draft, of May 2002.

>For profiles it would be, say,
>multiple levels of the PDA profile for ever-better PDAs. Alternatively,
>a profile could require a mix of various features, including some which
>come in leveled form. For modules, it could happen like this:
>(use monospace below)
>
>+---------------------+
>| Foo Module Level 2  |
>+---------------------+------------+---------------+
>| Foo Module Level 1  | Bar Module | Jar Module    |
>+---------------------+------------+---------------+
>|        Core (required of all products)           |
>+--------------------------------------------------+
>
>This is an immediate concern because the XQuery WG is proposing to have
>modules, but have a leveled relationship among the modules. You can't
>have the Static Typing Module unless you have the Schema Import Module
>for it to build on. Furthermore, "Basic" XQuery (what you have when you
>don't have either module) is required to raise errors when the query
>contains artifacts of Schema Import. If you were to draw a box diagram,
>it would be:
>(back to monospace)
>
>+---------------------+
>|    Static Typing    |
>+---------------------+
>|    Schema Import    |
>+---------------------+
>|        Basic        |
>+---------------------+
>which is a picture of levels, for sure.

I must be misunderstanding.  I thought you said in your prose (above the 
diagram) that having the Static Typing Module requires that you have the 
Schema Import Module, and having the latter requires that you also have the 
Basic Module.

I did not think that you meant, Static Typic contains Schema Import, and 
Schema Import contains Basic.  *This* would be a layered relationship.  In 
a layered architecture, as we have defined it, each layer *contains* the 
previous layer.  See GL7, "Level 2 includes all of level 1 plus additional 
functionality. [etc]"

What I thought you described, "A requires B, and B requires C" is a 
mandated relationship amongst modules.  We address this in CP5.1 ([1]).

[1] 
http://www.w3.org/TR/2003/WD-qaframe-spec-20030210/#Ck-indicate-module-mandatory


>Saying in the definition that "Modules are non-hierarchical..." seems
>like an unnecessary constraint. Modules are typically not hierarchical,
>but a "core" module is required.

Typically, but not necessarily.  A Core module *may* be required, but it is 
not an essential (defining) criterion of modularization as we have defined 
it.  See CP5.1 [1] again.  Examples (actually, in all these examples a 
single core, or a core set, has some presence)...

In a couple of the (proposed) archetypical modularization systems -- XHTML 
and SMIL -- a required core is only defined in the context of 
profiles.  XHTML-MOD, for example, defines a notion of "XHTML Host Language 
Conforming".  This is really a set of Rules for Profiles -- what a profile 
must contain in order to earn the "HLC" (goodness) designation.  It 
includes this requirement:  "...must include, at a minimum, the Structure, 
Hypertext, Text, and List modules".  FOUR required modules, not a single 
Core module.

The picture is similar for CSS3 modularization [2].  Looking at section 2 
of [2], "Any module whose table row is backed with green is considered part 
of the "CSS Core."  There are THREE of them.  (I haven't yet found a 
description of what "CSS Core" means, but we can guess.)

[2] http://www.w3.org/TR/2001/WD-css3-roadmap-20010406/#whymods

Looking at DOM2:  "DOM Level 2 consists of 14 modules.[...]An 
implementation is DOM Level 2 conformant if it supports the Core module".
Looking at DOM3:  "DOM Level 3 consists of ? modules. It is possible to 
conform to DOM Level 3, or to a DOM Level 3 module.  An implementation is 
DOM Level 3 conformant if it supports the Core module [...]. An 
implementation conforms to a DOM Level 3 module if..."

[3] http://www.w3.org/DOM/DOMTR#dom2 (good starting point).

So DOM (DOM2, at least) contains the notion of a single required Core module.

>Does it matter whether the other
>non-core modules are depicted on top of the core or not? The key idea
>IMHO is that if your so-called modules really stack up like the second
>picture above, you should call them levels.

Disagree.  Only if there is containment.  If the stacking is a way to show 
dependency or required inclusion, then it is not levels.

-Lofton.

Received on Wednesday, 23 April 2003 13:03:02 UTC