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