Re: [SpecGL] D1 Subdividing the spec. (revision)

Thanks for the PROS/CONS

Le 13 août 2004, à 00:17, david_marston@us.ibm.com a écrit :
> >Good Practice: Subdivide the technology to foster implementation
> I prefer: If you must subdivide, use the formal techniques described 
> here.

It doesn't have the same meaning at all. That will need more 
discussions.

> >Why care?
> + If the spec will be built upon by other specs, as with XPath, the 
> formal identification and naming of subdivisions sets expectations for 
> the other specs to identify which subdivisions they require, permit, 
> or prohibit.
>
> Example of modules: XQuery is defining several modules, which they 
> call "features"

I will add this example

> Example of levels: I like the WCAG example. DOM isn't necessarily a 
> bad example, because DOM levels 1 and 2 are still in force, rather 
> than being superseded like versions.
>
So I think we will have to discuss again deeply the topic. because I'm 
not so sure for example that... Dom Levels are really levels... I see 
them more as versions :)

WCAG can be seen as levels I agree.

> Drawings: I think the drawing Karl pointed to is good for profiles, 
> but not so good for modules and levels. A long time ago, I sent these 
> ideas:

hmmm ok let's try to explain further what I have done.

> Levels:
> +---------+
> |         |
> | Level 3 |
> |         |
> +---------+
> |         |
> | Level 2 |
> |         |
> +---------+
> |         |
> | Level 1 |
> |         |
> +---------+

Do you mean that:
	1st = Level 1
	2nd = Level 1 + 2
	3rd = Level 1 + 2 + 3
	===> the case of WCAG for example.

If yes, it's what my drawing is exactly saying. If not I would like to 
explain what do you mean by levels.

Though my drawin should be improved by reversing the figure for levels 
orders.

> Modules:
>
> +----------+----------+----------+
> | Module A | Module B | Module C |
> +----------+----------+----------+------------+
> |      Core Module - required for all         |
> +---------------------------------------------+
> This drawing deliberately shows a notch at the top to indicate that 
> implementing just the core is conformant.

Which is the same that I have done in my drawing in the sense. you can 
for example in the conformance section that what I have called Module A 
is the core module and it's fine. Your drawing just above expresses 
conformance rules, not technology division.

What makes the Core Module technologically different from other modules 
in your technology?

> Interaction:
>
>            +-------------------+
>            | Module B, Level 2 |
> +----------+-------------------+----------+
> | Module A | Module B, Level 1 | Module C |
> +----------+-------------------+----------+------------+
> |           Core Module - required for all             |
> +------------------------------------------------------+
> Of course, the above is one of zillions of possible interactions.

What you are saying here is that a module can be "spread on different 
levels". I agree with this one. But I would not have drawn it like that 
but more


           +-------------------+
           | Module B          |                         Level 2
+----------+-------------------+----------+
| Module A | Module B          | Module C |              Level 1
+----------+-------------------+----------+------------+
|           Core Module - required for all             | Level 1
+------------------------------------------------------+

I still don't agree with the Core Module being different, the thing 
that is always necessary to implement it, is not about technology 
division but more conformance. or if you really want a different 
module. Core Module = Level 0

If you implement Module, you have to implement Core Module.