Copyright © 2004-2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document details and deepens some of the most important concepts related to conformance when designing a specification. It is a companion document of QA Specification Guidelines. It analyzes how design decisions of a specification's conformance model may affect its implementability and the interoperability of its implementations.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a W3C Working Group Note. It has been produced by the Quality Assurance Working Group, which is part of the Quality Assurance Activity. It has been made available for discussion by W3C members and other interested parties. For more information about the QA Activity, please see the QA Activity statement. Translations of this document may be available.
This version features a reorganization of the content of the previous version, with a few additional sections completing the description of the various Dimensions of Variability.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The QA Working Group does not expect this document to become a Recommendation. Rather, after further development, review and refinement, it may be updated and maintained as a Interest Group Note.
You may email comments on this document to www-qa@w3.org, the publicly archived list of the QA Interest Group.
This document analyzes how design decisions of a specification's conformance model may affect its implementability and the interoperability of its implementations. To do so, it introduces the concept of variability - how much implementations conforming to a given specification may vary among themselves - and presents a set of well-known dimensions of variability.
Its goal is to raise awareness of the potential cost that some benign-looking decisions may have on interoperability and to provide guidance on how to avoid these pitfalls by better understanding the mechanisms induced by variability.
It completes and deepens the concepts evoked in the Specification Guidelines [SPECGL].
Like the Specification Guidelines [SPECGL], the primary audience of this document is editors and authors (henceforth referred to collectively as editors). However, it is also applicable to a broader audience including:
This document first introduces the concept of dimensions of variability, and then analyzes specific aspects related to these dimensions. Some of the dimensions are discussed in the Specification Guidelines [SPECGL] and are briefly treated here. The rest are discussed in depth. The seven dimensions are presented in a sequence from most to least independence from other design factors. After the seven dimensions, there is a section discussing how a Working Group might organize documents if variability is a factor encouraging the issuance of a package of several documents.
Many of the requirements in the Specification Guidelines [SPECGL] address ways in which 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 ways in which a specification can allow variability are referred to as dimensions of variability. The QA Working Group has identified the following seven dimensions of variability:
These seven dimensions of variability are not necessarily orthogonal to one another. There are many possible associations, dependencies, and interrelationships. As a general policy, this document and the Specification Guidelines do not attempt to legislate correct or proper relationships among the dimensions of variability. Rather, they try to clarify the nature of each dimension and suggest that specifications editors make deliberate and well-documented choices.
The dimensions of variability are one of the principal concepts in the Specification Guidelines with respect to organizing, classifying and assessing the conformance characteristics of W3C specifications. The seven dimensions of variability get special attention because they are at the core of the definition of a specification's conformance model. 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, and correct implementations. However, when compared to the alternatives, the net effect of conformance variability is not necessarily negative in all cases. 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 implementers 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 that goes beyond what is needed for a positive interoperability trade-off and that unnecessarily complicates the conformance model. Specification editors need to carefully consider and justify any variability allowed and its affect on conformance. This can be done by referencing project requirements and use cases and/or explicitly documenting the choices made.
It is even more important to take into account the multiplicative effect on variability created by combining several dimensions of variability. Each pair of dimensions of variability used in a specification needs to be assessed with regard to the variability it creates. The editors should document any limitations on the ways an implementation can combine dimensions. For instance, deprecated features in HTML 4.01 [HTML4] are allowed in the Transitional profile and forbidden in the Strict profile.
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.
The most basic dimension of variability is class of product. The class of product separates the different kinds of implementations a specification may have. For instance, SVG 1.1 [SVG11] defines conformance for six classes of product: SVG document fragments, SVG stand-alone files, SVG included documents fragments, SVG generators, SVG interpreters, and SVG viewers.
Defining these classes of products is thus one of the most important steps in the design of a specification's conformance model. This section provides advice on how to identify classes of products. To do this, it introduces the design concept of specification categories.
From this categorization of specifications, a Working Group 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" or "read" it in some way.
The following is a list of the most common classes of products for W3C specifications:
This list does not exhaust all possibilities. Specifications may have to define their own classes of product if none of these fits.
To answer the question "what needs to conform?" it can help to first look at the nature of the specification and categorize it. Often, the scope of the specification can be determined by placing the specification in one, or possibly more, categories based on what the specification describes. This will help the Working Group decide whether they need to address a particular view of the technology, possibly including its variability, or simply declare that the specification(s) are independent of that view. Further, categorization is a first step to determining which Dimensions of Variability are likely to be in scope for the specification.
The following is a non-exhaustive list of specification categories:
Set of guidelines - describes desirable attributes of content intended for human consumption.
Examples: QA Specification Guidelines, Web Content Accessibility Guidelines.
Foundation or abstract - describes an abstraction around which several other specs will synchronize, but which is not implemented in code.
Example: XML InfoSet [INFOSET] is a foundation for various specs that have a "data model" of the usable content of an XML document. However, there is no "InfoSet API" or "InfoSet Parser" specified.
Notation/syntax - describes a language that will be expressed as an actual character stream in XML or Web content and whose semantics will be understood by other W3C-specified technologies.
Example: XPath [XPATH] is a non-XML-based notation for expressions that is used as the W3C-standard expression language for XSLT [