[SpecGL Draft] D1 Subdivide the technology

This seemed to get too long, but its always easier to cut out words.... 
This is the first Good Practice, which if you don't do, then you skip over 
the rest of the Principles and Good Practices. These subsequent Principles 
and GP will be sent later (I still have to write them).

Comments?

D1 Subdivide
Subdividing the technology should be done carefully  it is not always a 
good idea.  Be smart when dividing the technology so that it is not 
excessive and provides a positive impact on implementation and 
interoperability.  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).  Requirements may 
be in multiple places and/or duplicative, making them more difficult to 
find and increasing the probability of conflict and 
misinterpretation.  Subdividing the technology increases the likelihood 
that implementations will implement different subdivisions and thus not 
interoperate

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.

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: Use 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: example?


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