[SpecGL] D1 Subdividing the spec. (revision and new)

Comments Please - examples and techniques needed.

Thanks
Lynne

+++++++++++++++++++++++++++++++++++++++++++
Principle: Indicate which subdivisions are mandatory for conformance

What does this mean?
Regardless of the subdivision technique (i.e., profile, level or module), 
state whether one or more of the subdivisions is required for conformance.

Why care?
Subdividing the technology affects and can complicate conformance with all 
the various combination of choices it provides – (a Chinese menu syndrome – 
1 from column A, 2 from column B and desert is included).  Thinking about 
the various possibilities helps to structure the conformance model, taking 
into account how the subdivision will affect various classes of 
products.  Implementers as well as users need to know what is mandatory, 
optional, prohibited or conditional with respect to choosing what to 
implement and be conformant.

Related
Conformance Principles/Practices of SpecGL

Techniques
In the conformance clause, list the subdivisions that are mandatory for 
conformance.  To help build this list, consider the following questions.
    * Can an implementation conform without implementing one of the 
subdivisions?
    * Does the subdivision apply to specific classes of products and not 
others?
    * Are there combinations of the subdivided technology that always go 
together and can not be implemented alone?
  Examples:
Content can be required to conform to one of the subdivisions (e.g., 
profiles)  or it may be conformant to the specification independently of a 
subdivision.  The question arises for a producer (of content): is it 
conforming if it generates content that is otherwise valid but does not 
conform to the subdivision.


Principle: Address subdivision conditions or constraints

What does this mean?
This is a corollary to the Principle above. Beyond being mandatory or not, 
subdivisions usually have conformance consequences due to minimal or new 
requirements, restrictions, interrelationships, and variability, etc.  As 
part of the conformance clause, describe the conditions or constraints 
associated with each subdivision

Why care?
Creating subdivisions can get complicated, not just for the specification 
editor but for implementers who must pick and choose from the set of 
subdivisions.   Well designed subdivisions that convey the conditions, 
constraints, interrelationships, etc. will improve the clarity and 
understanding of the specification, conformance to the specification and 
facilitate implementation and interoperability.

Techniques
In the conformance clause, describe the conditions or constraints on 
subdivision usage.  To help accomplish this, model or graph the 
subdivisions indicating the following that applies:
    * Atomicity of the subdivisions
Represent each subdivision showing its atomicity.
    * Mandatory subdivisions
Label the subdivisions that are mandatory
    * Minimal requirements
List minimal requirements for each subdivision.
    * Dependencies among subdivisions
Show dependencies and interrelationships of the subdivisions. For example, 
modules that requires and builds on functionally related modules, i.e., 
modules that require modules from other functional areas.
    * Conditions and constraints on subdivisions groups
Indicate conditions and constraints for combined occurrences of subdivision 
pairs or groups
    * Conditions or constraints associated with specific classes of products
Indicate which conditions and constraints are applicable to specific 
classes or products.
    * Other conditions or constraints beyond these
Indicate any other conditions or constraints.

Examples:

SMIL 2.0 has a SMILO 2.0 Language Profile for user agents but also provides 
a SMIL 2.0 Basic Profile for wireless and embedded devices. The SMIL 2.0 
language Profile requires that a user agent implement the BasicAnimation 
module but not the SplineAnimation Module.  The SMIL 2.0 Basic Profile on 
the other hand does not require implementation of any of the animation 
modules.

Dependency or interrelationship between profiles and modules is common – 
XHTML, SMIL, SVG 1.1

[@@ would be great to graph/model a technology]