W3C

Variability in Specifications

W3C Working Draft 28 April 2005

This version:
http://www.w3.org/TR/2005/WD-spec-variability-20050428/
Latest version:
http://www.w3.org/TR/spec-variability/
Previous version:
http://www.w3.org/TR/2004/WD-spec-variability-20040830/
Editors:
Dominique Hazaël-Massieux, W3C
Lynne Rosenthal, NIST
Contributors:
See Acknowledgments.

Abstract

This document details and deepens some of the most important conformance-related concepts evoked in the QA Specification Guidelines, developing some of the analysis axes that need to be considered while designing a specification and providing advanced techniques, particularly for dealing with conformance variability and complexity

Status of this document

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 the second public Working Draft of Variability in Specifications made available by the the QA Working Group of the W3C Quality Assurance (QA) Activity for discussion by W3C members and other interested parties. For more information about the QA Activity, please see the QA Activity statement.

This version includes a few additions from the previous version, moved from the November 2004 version of the Specification Guidelines. It also includes the planned structure of new sections that have not been completed yet. This document does not represent explicit consensus of the Working Group. There are a few open issues, marked with a capitalized ISSUE keyword.

Publication as a Working Draft 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 will be published and maintained as a Working Group Note.

You may email comments on this document to www-qa@w3.org, the publicly archived list of the QA Interest Group.

Table of contents

  1. Introduction
  2. Dimensions of Variability (DoV)
  3. Classes of products and specification category
  4. Subdivisions of a technology
  5. Extensibility
  6. Optional features
  7. Acknowledgments
  8. References

1. Introduction

Scope and Goals

This document analyzes how design decisions of the conformance model of a specification 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.

Audience

Like the Specification Guidelines, 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:

Structure of this document

This document first introduces the concept of dimensions of variability, and then analyzes specific aspects related to some of these dimensions, more specifically the classes of products, and the subdividing dimensions profiles, modules and levels, extensions and optional features.

2. Dimensions of Variability (DoV)

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 (DoV). The QA Working Group has identified the following seven dimensions of variability :

  1. classes of product - the generic name for the group of products that would implement, for the same purpose, the specification,
  2. profiles - a subset of a technology that is tailored to meet specific functional requirements of a particular application community,
  3. modules - a collection of semantically-related features that represents a unit of functionality,
  4. levels - a technology subset that is one of a hierarchy of nested subsets, ranging from minimal or core functionality to full or complete functionally ,
  5. deprecation - the process of marking certain features as outdated and being phased out,
  6. discretionary items - deliberate and explicit grants of discretion by the specification to the implementations, that describe or allow optionality of behavior, functionality, parameter values, error handling, etc.,
  7. extensibility - a mechanism allowing any party to create extensions.

These seven DoV 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 DoV. 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 DoV get special attention because they are at the core of the definition of a specification's conformance model, 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 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 which goes beyond that needed for a positive interoperability trade-off, and which 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.

3. Classes of products and specification category

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 6 classes of product: SVG document fragments, SVG stand-alone files, SVG included documents fragments, SVG generators, SVG interpreters, SVG viewers.

Defining these classes of products is thus one of the most important step in the design of a conformance model for a specification. This section provides advice on how to do identify classes of products. To do this, it introduces the this design concept of specification categories.

Classes of products

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.

Specification category

ISSUE: needs to explain the different categories, how to actually make a specification category analysis

To answer the question "what needs to conform?" it can help to first look at the nature of the specification and categorize it . This provides a basis for classifying the software that may be affected by the specification.

The following is a list of some of the most common specification categories:

The categories indicate what the specification describes. One specification could potentially fall into more than one category. This list does not exhaust all possibilities.

4. Subdivisions of a technology

4.1. Profiles, modules, and levels

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 showing how profiles were used in SVG 1.1
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.

Diagram showing how modules were used in XHTML 1.1
Diagram illustrating modules used to divide XHTML 1.1 in re-usable components.

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 showing how levels were used in WCAG
Diagrams illustrating levels of conformance in the Web Content Accessibility Guidelines 1.0
Diagram showing how levels were used in the DOM
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, as in the Web Content Accessibility Guidelines.

Sometimes, the nesting goal of levels is achieved through profiles. 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).

4.2. Umbrella specifications

A specification is a document that prescribes technical requirements to be fulfilled by a product, process or service.

There is a tension between defining a technology by setting as many requirements as possible inside one document and setting a few requirements in many documents. The former allows to get a more cohesive set of requirements, while the latter enables a more flexible development.

It also allows specification authors to offer pieces of their work for different breadths of adoption. For example, XML Schema Part 2 (Data Types) is offered by the XML Schema Working Group as the W3C-wide standard for data types.

A monolithic specification sets all the requirements created for a given technology in a single document.

The W3C Process document provides a framework for Working Groups to help them publish their specifications and enforce some quality practices (for example, implementation phase during Candite Recommendation). But it doesn't require nor prohibit a monolithic specification, but rather leaves the Working Group discretion to decide how many documents they may issue. Neither does it define of what a technology consists, nor how a technology relates to one or several specifications.

Defined in one or several documents, specifications can import requirements of other specifications with normative references. Some specifications, denoted below as umbrella specifications, create all the requirements of the technology they define by simply grouping requirements of existing specifications in a well-defined manner.

When a Working Group intends to produce several documents that act collectively to specify their technology (e.g., OWL), it would be wasteful and confusing to have every document describe its relationship to every other document. For that purpose, the Working Group can produce an umbrella specification that states relationships among the documents in one place. All other documents can then make one reference to the umbrella document as the source of the global view of the technology.

Figure 1: Umbrella specification

Diagram illustrating  the notion of umbrella specification as a composite document specification.

On this figure, the technology is composed of two modules (defining functional division of the technology), a profile (defining the requirement of implementation for a specific device) and a primer (introducing the technology and its basic concepts). An "umbrella specification" document groups them together making it a logical, usable and complete technology.

5. Extensibility

6. Optional features

ISSUE: needs to address discretionary items, and more largely, the remaining DoV.

7. Acknowledgments

The following QA Working Group and Interest Group participants have contributed significantly to the content of this document:

8. References

These references are informative.

HTML4
HTML 4.01 Specification , D. Raggett, A. Le Hors, I. Jacobs, Editors, W3C Recommendation, 24 December 1999, http://www.w3.org/TR/1999/REC-html401-19991224 . Latest version available at http://www.w3.org/TR/html401 .
SMIL20
Synchronized Multimedia Integration Language (SMIL 2.0) - [Second Edition] , T. Michel, J. Ayars, Editors, W3C Recommendation, 7 January 2005, http://www.w3.org/TR/2005/REC-SMIL2-20050107/ . Latest version available at http://www.w3.org/TR/SMIL/ .
SPECGL
QA Framework: Specification Guidelines , L. Henderson, D. Hazaël-Massieux, K. Dubost, L. Rosenthal, Editors, W3C Working Draft (work in progress), 28 April 2005, http://www.w3.org/TR/2005/WD-qaframe-spec-20050428/ . Latest version available at http://www.w3.org/TR/qaframe-spec/ .
SVG11
Scalable Vector Graphics (SVG) 1.1 Specification , J. Ferraiolo, 藤沢, D. Jackson, Editors, W3C Recommendation, 14 January 2003, http://www.w3.org/TR/2003/REC-SVG11-20030114/ . Latest version available at http://www.w3.org/TR/SVG11/ .
SVG-MOBILE
Mobile SVG Profiles: SVG Tiny and SVG Basic , T. Capin, Editor, W3C Recommendation, 14 January 2003, http://www.w3.org/TR/2003/REC-SVGMobile-20030114/ . Latest version available at http://www.w3.org/TR/SVGMobile/ .
XHTML-MOD
Modularization of XHTML™ , T. Wugofski, M. Altheim, S. Schnitzenbaumer, F. Boumphrey, S. McCarron, S. Dooley, Editors, W3C Recommendation, 10 April 2001, http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/ . Latest version available at http://www.w3.org/TR/xhtml-modularization/ .
XHTML-BASIC
XHTML™ Basic , T. Yamakami, P. Stark, M. Ishikawa, M. Baker, S. Matsui, T. Wugofski, Editors, W3C Recommendation, 19 December 2000, http://www.w3.org/TR/2000/REC-xhtml-basic-20001219 . Latest version available at http://www.w3.org/TR/xhtml-basic .
XHTML11
XHTML™ 1.1 - Module-based XHTML , M. Altheim, S. McCarron, Editors, W3C Recommendation, 31 May 2001, http://www.w3.org/TR/2001/REC-xhtml11-20010531 . Latest version available at http://www.w3.org/TR/xhtml11/ .