[SpecGL] D1 Subdividing the spec. (revision)

The following is a revision of the Intro and Good Practice previously 
sent.  Changes made based on comments received.  Following this email, will 
be the rest of this section.
Still needed are examples.

D1 Subdivide
Subdividing the technology should be done carefully.  Too many divisions 
complicates conformance and can hinder interoperability by increasing the 
chances of conflict with other aspects of the specification (e.g., other 
subdivisions).  Be smart when dividing the technology so that it is not 
excessive and provides a positive impact on implementation and 
interoperability.  The benefits of subdividing should outweigh the drawbacks.

[@@ Maybe a table of the following is better.  many things (e.g., 
interoperability) are both benefits and drawbacks – i.e., subdivisions can 
help interoperability as well as hurt it).

Benefits: Subdividing can
--make the technology easier to implement
--facilitate incremental implementation
--increase interoperability by focusing the technology on specific needs
-- help organize the structure of the technology

Drawbacks: Too many divisions can:
--complicate conformance – need to account for interrelationships with 
other subdivisions and variability (e.g., extensions)
--hurt interoperability – increases likelihood of incompatible implementations
-- increase misinterpretation or cause conflict of requirements due to 
multiple or duplicative requirements.

Good Practice: Subdivide the technology to foster implementation

What does this mean?
It may make sense to subdivide the technology into related groups of 
functionality to target specific constituencies, address specific 
capabilities or hardware considerations, provide for incremental 
implementation, facilitate usability, etc.

Why care?
For some specifications (e.g., huge, multi-disciplined), bundling 
functionality into named or anonymous packages can
    * provide an additional level of scoping control,
    * improve readability and the ability to find areas of interest, and
    * facilitate implementation and interoperability, since implementing 
the entire, monolithic specification may be impractical and undesirable

Related
[Tech Note] contains additional information on three methods to subdivide 
technologies, Profiles, Levels and Modules.

Technique: Use profiles.  Profiles are subsets of a technology tailored to 
meet specific functional requirements of application communities.  The 
specification may define individual profiles, or may define rules for 
profiles, or both.  An individual profile defines the requirements for 
classes of products that conform to that profile.  Rules for profiles 
define validity criteria for profiles themselves.  Profiles are a good way 
to target the needs of specific constituencies.

Technique: Use Functional levels (aka levels)   Functional levels are a 
hierarchy of nested subsets, ranging from minimal or core functionality to 
full or complete functionality.  Levels are a good way to facilitate 
incremental development and implementation.

Technique; Modules.  Modules are discrete collections of 
semantically-related units of functionality that do not necessarily fit in 
a simple hierarchical structure.  Use modules when functionality can be 
implemented independently of one another – e.g., audio vs video module.  It 
is common to have implementers pick and choose multiple modules to implement.

Examples:
Profile:  SVG Tiny is a profile aimed at mobile phones.
Profile: XHTML Modularization (XHTML-MOD, section 3) and SMIL (SMIL 2.0) 
specifications define rules for profiles.

Levels: There are no examples in W3C where levels are defined explicitly in 
a single edition of a specification.  CSS and DOM are examples where levels 
are the result of progressive historical development and technology 
enrichment and are realized in a series of specifications.

Profile/Level combo: SVG Mobile define 3 nested profiles -  Tiny, Basic, 
Full  - which are really 3 levels, each targeted a specific hardware 
communities.

Modules: XHTML Modularization and SMIL gives good examples


STOP: Only proceed if you do the above Good Practice.  Else, skip the rest 
of this section.