Re: Variability in Specifications Graphics

At 06:36 PM 8/16/2005 -0400, david_marston@us.ibm.com wrote:

>DM>>2. Does XHTML have a "core" or mandatory piece? The drawing implies
>DM>>that no single module is needed by all implementations.
>
>KD>The drawing implies that *every* modules is needed by all
>KD>implementations. :) But that could be specified in the text around
>KD>the graphics to make it really clear.
>
>KD>It's not defined like that. XHTML 1.1 is a full set of technology
>KD>with no optional modules. Using XHTML Modularization it is possible
>KD>to define new modules
>
>So far, this is not looking like a good example. The best possible
>example of modules would display the following properties:
>1. Exactly one module would be mandatory for all,

Offhand, I can't recall any past or present guideline, requirement, or good 
practice of ours which mandates this, or even suggests it.  I can see some 
logic to it.  But I disagree that the driving criterion for modularization 
must be the borders of manditoriness, i.e., I disagree that the lines must 
be drawn so that there is a single mandatory core module.

Both XHTML and SVG have drawn the lines so that the modules are 
functionally coherent and distinct.  That seems to be the common practice 
in W3C.  My guess is that it's done for reasons of user-friendly, 
human-friendly comprehension of the overall structure and content of 
XHTML.  Plus, the definition of modules as functionally distinct units 
leaves the door open in the future for other assemblies (other than the 
mandatory-core-4), for the definition of other conformance designations.

>2. The WG would have specified 2 or more modules that are optional,

I guess I don't understand this assertion.  As I read XHTML Modularization, 
in section 3.1, the "XHTML Host Language Document Type ..." conformance 
designation, any of the XHTML modules other than the core 4 are optional, 
in satisfying that conformance designation.

-Lofton.

>3. A generalized modularity mechanism would allow more modules to be
>    defined in the future (or maybe added by others).
>Since XHTML fails 1 and 2, we are left trying to salvage a good
>example from property 3. XPath is a better example, though they don't
>use the term "modules" for what are, indeed, modules.
>
>I hope these new drawings are meant to supplement, rather than replace,
>the existing drawings.
>.................David Marston