Several of the
guidelines, GL2 through GL6, address a way in which the
conformance policy of a specification might allow variation among
conforming implementations. For example, a specification might allow
implementations to choose between one of two well defined behaviors for a
given functionality, thus two conforming implementations might vary on that
aspect.

The Working Group has identified
seven ways in which a specification can allow variability, that
are refered to as dimensions of variability (DoV).
The seven dimensions of variability recognized by this document
are:

The above are not necessarily all orthogonal to one another. There are
many possible associations, dependencies, and interrelationships. As a
general policy, these specification guidelines do not attempt to legislate
correct or proper relationships among the DoV. Rather, they try to clarify
the nature of each dimension and require a specification to make deliberate
and well documented choices. Some discussion of possible interrelationships,
including examples, will be found in the Specification Examples &
Techniques.

The dimensions of variability are one of the principal concepts in this
guidelines document to help organize, classify and assess the conformance
characteristics of W3C specifications. The seven DoV get special attention because
they are at the core of the definition of a specification's conformance
policy, and thus there is significant potential for negative interoperability
impacts if they are handled carelessly or without careful deliberation.

As a general principle, variability complicates
interoperability. In theory, interoperability is best when there are
numerous identical, complete, correct implementations. However, in
practice, the net effect of conformance variability is not necessarily
negative in all cases, when compared to the alternatives. For example
profiles — subdivisions of the technology targeted at specific
applications communities — introduce variability among
implementations. Some will implement Profile ABC, some will implement Profile
XYZ, and the two might not intercommunicate well if ABC and XYZ are fairly
different. However, if ABC and XYZ are subsets of a large monolithic
specification — too large for many implementors to tackle in total --
and if they are well targeted at actual application sectors, then subdivision
by profiles may actually enhance interoperability.

Different sorts of variability have different negative and positive
impacts. The principal danger is "excessive" variability -
variability which goes beyond that needed for a positive interoperability
trade-off, and which unnecessarily complicates the conformance landscape.
Specification writers need to carefully consider and justify any conformance
variability allowed, do so by reference to the project requirements and use
cases, and explicitly document the choices made.

Note that the variability addressed by the so called
dimensions of variability is only considered with regard to conformance to a
well-defined specification. As such, the changes introduced in the
conformance requirements between two versions or two editions of the
specification are not considered as dimensions of variability.

To answer the question "what needs to conform?" it helps to first
look at the nature of the specification and categorize it and then look at
the types of products that would implement the
specification.Categorizing the specification provides a basis for
classifying the software that may be affected by the specification.
The specification category is the generic
name for the type of specification and the technology it describes.

The categories indicate what the specification describes. One
specification could potentially fall into more than one category. This
list does not exhaust all possibilities. Specifications may have to define
their own specification category if none of these fits.

From this categorization of specifications, the WG can identify the class of
products that are affected by the specification. Classes of products
can be generalized as either producers or consumers, or as
content itself.

For example, identifying which are producers and consumers is clear for a
protocol-type specification: the two parties to the dialog are the targets.
For a processor-type specification, the processor is the consumer of an
XML vocabulary defined
in the specification. For content-type specifications, there may be one or
more consumers that take the content and 'play' it in some way.

Profiles, modules and levels are three ways to
subdivide a specification into related groups of conformance requirements.
Because these three dimensions of variability define subsets of a technology,
they share some characteristics in the way they affect conformance and
interoperability.

A profile is a subset of the technology that
supports a particular functional objective or a subset of a set of
technologies defining how they are required to operate together (e.g., XHTML
plus MathML plus
SVG).

Profiles can be based on hardware considerations associated with target
product classes — for example, SVG Tiny is aimed at mobile phones
— or they may be driven by other functional requirements of their
target constituencies — for example, a graphical profile tailored for
technical illustrations in aircraft maintenance manuals.

Diagram illustrating profiles used to adapt the SVG Technology to different
platforms.

The use of profiles to divide the technology is described in the
specification, and may or may not be reflected and paralleled by the
structure and organization of the specification.

Specifications 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 —
i.e., if others (users, applications, or other standards) define their own
profiles of the standard (called derived profiles of the
specification), then rules for profiles define the constraints that
those derived profiles must
satisfy in order to be considered valid profiles of the specification.

For example, XHTML Modularization ([XHTML-MOD], section 3) and Synchronized
Multimedia Integration Language (SMIL 2.0), [SMIL20] specifications both define rules for profiles --
what constraints must a profile meet in order to be classified as a "Host
Language Profile" or an "Integration Set Profile." SMIL further defines some
specific profiles, using the modularization. Separate recommendations --
XHTML Basic [XHTML-BASIC] and XHTML 1.1 [XHTML11] — define specific profiles
based on the XHTML modularization.

Modules are
discrete divisions or functional groupings of the technology and
do not necessarily fit in a simple hierarchical structure.

Modules generally can be implemented independently of one another —
e.g., audio vs. video module. That notwithstanding, it is possible for one
module's definition (and therefore implementation) to have explicit
dependency upon another module. It is not only possible, but common to
implement multiple modules.

Functional levels — or in common
usage, simply levels — are used to group functionality into
nested subsets, ranging from minimal or core functionality to full or
complete functionally. Level 1 is the minimum or core of the technology.
Level 2 includes all of level 1 plus additional functionality. This nesting
continues until level n, which consists of the entire technology.

Diagram illustrating levels used to build up the Document Object Model.

Levels may result from progressive historical development and enrichment
of the technology in a series of specifications, as in the case of CSS and DOM. Levels could also be defined
explicitly in a single edition of the specification, but no examples of this
are found in W3C specifications. Rather, it is more common in current W3C
practice to use profiles to accomplish this. For example, SVG 1.1 [SVG11] together with SVG Mobile [Mobile [SVG-MOBILE] define three nested profiles
— Tiny, Basic, Full — which are each targeted at a specific
graphics hardware community (mobile phone, hand-held computer, desktop
computer).

As stated above, variability affects interoperability
and it is important for the specification writers to have this in mind while
designing the specification. But it is even more important to take
into account the multiplicative effect on variability created by combining
several dimensions of variability.

Hence,
each pair of dimensions of variability used in a specification needs to be
assessed with regard to the variability it creates; the writers should
document the limited ways an implementation can combine two dimensions. For
instance, deprecated features in HTML 4.01 [HTML4] are allowed in the Transitional profile and
forbidden in the Strict profile.