spec-variability
49.3 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Variability in Specifications</title>
<link title="W3C QA Glossary" href="http://www.w3.org/QA/glossary" rel="glossary" />
<link title="Latest version of the QA Framework Specification Guidelines" href="http://www.w3.org/TR/qaframe-spec/" rel="bookmark" />
<link title="Latest version of the QA Handbook" href="http://www.w3.org/TR/qa-handbook/" rel="chapter" />
<meta name="Keywords" content="qa, quality assurance, conformance, specification" />
<meta name="Description" content="This document details and deepens some of the most important conformance-related concepts by developing some of the analysis axes that need to be considered while designing a specification" />
<link rel="schema.DC" href="http://dublincore.org/" />
<meta name="DC.Subject" xml:lang="en" lang="en" content="qa, quality assurance, conformance, specification" />
<meta name="DC.Title" xml:lang="en" lang="en" content="QA Framework: Variability in Specifications" />
<meta name="DC.Description.Abstract" xml:lang="en" lang="en" content="This document details and deepens some of the most important conformance-related concepts by developing some of the analysis axes that need to be considered while designing a specification" />
<meta name="DC.Language" scheme="RFC1766" content="en" />
<meta name="DC.Publisher" content="W3C - World Wide Web Consortium - http://www.w3.org" />
<meta name="DC.Rights" content="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright" />
<link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" />
</head>
<body lang="en" xml:lang="en">
<div class="head">
<a href="http://www.w3.org/"><img height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home" width="72" /></a>
<h1><a id="spec-title" name="spec-title">Variability in Specifications</a></h1>
<h2><a id="dated-subtitle" name="dated-subtitle">W3C Working Group Note 31 August 2005</a></h2>
<dl>
<dt>This version:</dt>
<dd><a href="http://www.w3.org/TR/2005/NOTE-spec-variability-20050831/">http://www.w3.org/TR/2005/NOTE-spec-variability-20050831/</a></dd>
<dt>Latest version:</dt>
<dd><a href="http://www.w3.org/TR/spec-variability/">http://www.w3.org/TR/spec-variability/</a></dd>
<dt>Previous version:</dt>
<dd><a href="http://www.w3.org/TR/2005/WD-spec-variability-20050629/">http://www.w3.org/TR/2005/WD-spec-variability-20050629/</a></dd>
<dt>Editors:</dt>
<dd>Dominique Hazaël-Massieux, W3C</dd>
<dd>Lynne Rosenthal, NIST</dd>
<dt>Contributors:</dt>
<dd><a href="#acknowledgments">See Acknowledgments.</a></dd>
</dl>
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004-2005 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
<hr class="rule" />
</div>
<h2><a id="abstract" name="abstract">Abstract</a></h2>
<p>This document details and deepens some of the most important concepts related to conformance when designing a specification. It is a companion document of <a href="http://www.w3.org/TR/qaframe-spec/">QA Specification Guidelines</a>. It analyzes how design decisions of a specification's conformance model may affect its implementability and the interoperability of its implementations.</p>
<h2><a id="status" name="status">Status of this document</a></h2>
<p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
<p>This document is a W3C Working Group Note. It has been produced by the <a href="http://www.w3.org/QA/WG/">Quality Assurance Working Group</a>, 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 <a href="http://www.w3.org/QA/Activity">QA Activity statement</a>. <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=spec-variability">Translations</a> of this document may be available.</p>
<p>This version features a reorganization of the content of the <a href="http://www.w3.org/TR/2005/WD-spec-variability-20050629/">previous version</a>, with a few additional sections completing the description of the various Dimensions of Variability.</p>
<p>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.</p>
<p>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.</p>
<p>You may email comments on this document to <a href="mailto:www-qa@w3.org">www-qa@w3.org</a>, the <a href="http://lists.w3.org/Archives/Public/www-qa/">publicly archived</a> list of the QA Interest Group.</p>
<h2><a id="contents1" name="contents1">Table of contents</a></h2>
<ol>
<li><a href="#intro">Introduction</a></li>
<li><a href="#variability">Dimensions of Variability</a></li>
<li><a href="#spec-cat-cop">Classes of products and specification category</a></li>
<li><a href="#subdivision-profile">Subdivisions by profiles</a></li>
<li><a href="#subdivision-module">Subdivisions by modules</a></li>
<li><a href="#subdivision-level">Subdivisions by levels</a></li>
<li><a href="#optionality">Discretionary items</a></li>
<li><a href="#deprecated">Deprecated features</a></li>
<li><a href="#extensibility">Extensibility</a></li>
</ol>
<h3 id="app">Appendices</h3>
<ul>
<li>A. <a href="#umbrella">Umbrella specifications</a></li>
<li>B. <a href="#acknowledgments">Acknowledgments</a></li>
<li>C. <a href="#references">References</a></li>
</ul>
<h2>1. <a id="intro" name="intro">Introduction</a></h2>
<h3><a id="scope" name="scope">Scope and Goals</a></h3>
<p>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 <dfn>variability</dfn> - how much implementations conforming to a given specification may vary among themselves - and presents a set of well-known <dfn>dimensions of variability</dfn>.</p>
<p>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.</p>
<p>It completes and deepens the concepts evoked in the <a href="http://www.w3.org/TR/qaframe-spec/">Specification Guidelines</a> [<a href="#SPECGL">SPECGL</a>].</p>
<h3><a id="audience" name="audience">Audience</a></h3>
<p>Like the <a href="http://www.w3.org/TR/qaframe-spec/">Specification Guidelines</a> [<a href="#SPECGL">SPECGL</a>], 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:</p>
<ul>
<li>Working Group members developing the technology and specifications</li>
<li>Those who review specifications during their development</li>
<li>Implementers of specifications</li>
<li>Builders of test materials, including conformance test suites and tools</li>
</ul>
<h3><a id="structure" name="structure">Structure of this document</a></h3>
<p>This document first introduces the concept of <a href="#variability">dimensions of variability</a>, and then analyzes specific aspects related to these dimensions. Some of the dimensions are discussed in the Specification Guidelines [<a href="#SPECGL">SPECGL</a>] 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.</p>
<h2>2. <a id="variability" name="variability">Dimensions of Variability</a></h2>
<p>Many of the requirements in the Specification Guidelines [<a href="#SPECGL">SPECGL</a>] address ways in which a specification might allow <strong>variation among conforming implementations</strong>. 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.</p>
<p>The ways in which a specification can allow variability are referred to as <dfn>dimensions of variability</dfn>. The QA Working Group has identified the following seven dimensions of variability:</p>
<ol>
<li>Classes of product - The generic name for the group of products that would implement, for the same purpose, the specification.</li>
<li>Profiles - a subset of a technology that is tailored to meet specific functional requirements of a particular application community.</li>
<li>Modules - A collection of semantically related features that represents a unit of functionality.</li>
<li>Levels - A technology subset that is one of a hierarchy of nested subsets, ranging from minimal or core functionality to full or complete functionally.</li>
<li>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.</li>
<li>Deprecation - The process of marking certain features as outdated and phasing them out.</li>
<li>Extensibility - A mechanism allowing any party to create extensions.</li>
</ol>
<p>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.</p>
<p>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.</p>
<p>As a general principle, <strong>variability complicates interoperability</strong>. In theory, interoperability is best when there are numerous <em>identical</em>, 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.</p>
<p>Different sorts of variability have different negative and positive impacts. The <strong>principal danger is "excessive" variability</strong> - 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.</p>
<p>It is even more important to <strong>take into account the multiplicative effect on variability created by combining several dimensions of variability</strong>. 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 <cite><a href="http://www.w3.org/TR/html401/">HTML 4.01</a></cite> [<a href="#HTML4">HTML4</a>] are allowed in the Transitional profile and forbidden in the Strict profile.</p>
<p>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.</p>
<h2>3. <a id="spec-cat-cop" name="spec-cat-cop">Classes of products and specification category</a></h2>
<p>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, <cite><a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/conform.html#Introduction">SVG 1.1</a></cite> [<a href="#SVG11">SVG11</a>] 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.</p>
<p>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.</p>
<h3><a id="cop" name="cop">Classes of products</a></h3>
<p>From this categorization of specifications, a Working Group can identify the <dfn>class of products</dfn> that are affected by the specification. Classes of products can be generalized as either producers or consumers, or as content itself.</p>
<p>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 <acronym title="Extensible Markup Language">XML</acronym> 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.</p>
<p>The following is a list of the most common <a id="product-classes-list" name="product-classes-list">classes of products</a> for W3C specifications:</p>
<ul>
<li>Content (of type, meaning, and format as defined in the specification)</li>
<li>Producer of content (may be divided into initiators and modifiers)</li>
<li>Player (read-only consumer, conveys content in non- <acronym title="Extensible Markup Language">XML</acronym> way)</li>
<li>Consumer in a one-way pipeline</li>
<li>Responding agent (e.g., server) of <acronym title="Application Programmer Interface">API</acronym> (consumer and producer)</li>
<li>Processor (consumer of its vocabulary/instructions)</li>
<li>Module that hosts the processor</li>
<li>Producer of instructions/commands to processor</li>
<li>Profile derived from the specification's Rules for Profiles</li>
<li>Specification (guidelines)</li>
</ul>
<p>This list does not exhaust all possibilities. Specifications may have to define their own classes of product if none of these fits.</p>
<h3><a id="spec-cat" name="spec-cat">Specification category</a></h3>
<p>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 <em>what</em> 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.</p>
<p>The following is a non-exhaustive list of specification categories:</p>
<ul>
<li>
<p><em>Set of guidelines</em> - describes desirable attributes of content intended for human consumption.</p>
<p>Examples: QA Specification Guidelines, Web Content Accessibility Guidelines.</p>
</li>
<li>
<p><em>Foundation or abstract</em> - describes an abstraction around which several other specs will synchronize, but which is not implemented in code.</p>
<p>Example: XML InfoSet [<a href='#INFOSET'>INFOSET</a>] 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.</p>
</li>
<li>
<p><em>Notation/syntax</em> - 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.</p>
<p>Example: XPath [<a href="#XPATH">XPATH</a>] is a non-XML-based notation for expressions that is used as the W3C-standard expression language for XSLT [<a href="#XSLT">XSLT</a>], XPointer [<a href="#XPOINTER">XPOINTER</a>], and XForms [<a href="#XFORMS">XFORMS</a>]. The specifications of those other technologies do not treat XPath as a black box, but rather impose limits, add extensions, and/or recognize the range of potential values of an XPath expression. By doing so, the other technologies require a certain level of precision in the XPath specification, <em>including precision about its variability,</em> to use the hooks and impose their limits.</p>
</li>
<li>
<p><em>Content/data</em> - describes a markup language whose downstream usage is to express meaning to an end user or to applications specific to a discipline other than the Web itself.</p>
<p>Example: MathML [<a href='#MATHML'>MATHML</a>] is a markup language for the math discipline, and may be used to express mathematical ideas to a person or to math software. SVG is a language for expressing graphical ideas.</p>
</li>
<li>
<p><em>Set of events</em> - describes a coherent set of events that software may need to raise or listen for.</p>
<p>Example: one part of XForms [<a href="#XFORMS">XFORMS</a>] is a set of form-related events.</p>
</li>
<li>
<p><em>Protocol</em> - describes the interaction between two parties.</p>
<p>Example: SOAP [<a href="#SOAP">SOAP</a>].</p>
</li>
<li>
<p><em>Processor</em> - describes the behavior of a piece of software that takes well-defined inputs and operates on them to produce specified output.</p>
<p>Example: the <cite>XSL Transformations</cite> language [<a href="#XSLT">XSLT</a>] specifies the behavior of an XSLT processor. The specification describes an XML-based style sheet language that directs the operations of a processor, but it clearly states that conformance determinations apply to the processor, not the style sheets.</p>
<p>Example: XML Query specifies the behavior of a processor that takes the query language and fetches data, typically arranging that data in a convenient form for XML/Web use. It allows flexibility of the storage system from which data is fetched.</p>
</li>
<li>
<p><em title="Application Programming Interfaces">APIs</em> - describes a programmatic interface, allowing independent implementation of software that occupies the roles on either side of the interface.</p>
<p>Example: DOM [<a href='#DOM'>DOM</a>] specifies an interface that can be implemented by a parser or other processor that intends to offer an XML document in navigable form. Other software that wishes to navigate an XML document (e.g., an XSLT processor) can be written to use the DOM interface.</p>
</li>
<li>
<p><em>Rules for deriving profiles</em> - describes how implementers, or any parties other than the WG itself, may produce a <a href="#subdivision-profile">profile</a> for a particular situation that cannot be anticipated in complete detail at the time the WG is writing its specification.</p>
<p>Example: part of SMIL.</p>
</li>
</ul>
<p>From this categorization of specifications, the Working Group can identify the class of products that are affected by the specification.</p>
<h2><a id="profile-module-level" name="profile-module-level"></a><a id="subdivision" name="subdivision">4.</a> <a id="subdivision-profile" name="subdivision-profile">Subdivisions by profiles</a></h2>
<p>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.</p>
<p class="definition">A <dfn>profile</dfn> 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 <acronym title="Mathematical Markup Language">MathML</acronym> plus <acronym title="Scalable Vector Graphics">SVG</acronym> [<a href="#X-M-S">X-M-S</a>]).</p>
<p>Profiles can be based on hardware considerations associated with target product classes — for example, <acronym title="Scalable Vector Graphics">SVG</acronym> 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.</p>
<div class="illustration">
<img alt="Diagram showing how profiles were used in SVG 1.1" src="qaframe-spec-profiles" /><br />
Diagram illustrating profiles used to adapt the SVG Technology to different platforms.
</div>
<p>The use of profiles to divide the technology is described in the specification. Profiles may or may not be reflected and paralleled by the structure and organization of the specification.</p>
<p>Specifications may define individual profiles or rules for profiles or both. An <dfn>individual profile</dfn> defines the requirements for classes of products that conform to that profile. <dfn>Rules for profiles</dfn> define validity criteria for profiles themselves — i.e., if others (users, applications, or other standards) define their own profiles of the standard (called <dfn><a id="derived-profile" name="derived-profile">derived profiles</a></dfn> 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.</p>
<p>For example, <cite>XHTML Modularization</cite> ([<a href="#XHTML-MOD">XHTML-MOD</a>], section 3) and <cite>Synchronized Multimedia Integration Language (SMIL 2.0)</cite>, [<a href="#SMIL20">SMIL20</a>] 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 -- <cite>XHTML Basic</cite> [<a href="#XHTML-BASIC">XHTML-BASIC</a>] and <cite>XHTML 1.1</cite> [<a href="#XHTML11">XHTML11</a>] — define specific profiles based on the XHTML modularization.</p>
<h2>5. <a name="subdivision-module" id="subdivision-module">Subdivision by modules</a></h2>
<p class="definition"><dfn>Modules</dfn> are discrete divisions or functional groupings of the technology and do not necessarily fit in a simple hierarchical structure.</p>
<div class="illustration">
<img alt="Diagram showing how modules were used in XHTML 1.1" src="qaframe-spec-modules" /><br />
Diagram illustrating modules used to divide XHTML 1.1 in re-usable components.
</div>
<p>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 also common to implement multiple modules.</p>
<h2>6. <a name="subdivision-level" id="subdivision-level">Subdivision by levels</a></h2>
<p class="definition"><dfn>Functional levels</dfn> — or in common usage simply <dfn>levels</dfn> — 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.</p>
<div class="illustration">
<img alt="Diagram showing how levels were used in WCAG" src="spec-variability-levels-wcag" /><br />
Diagrams illustrating levels of conformance in the <cite>Web Content Accessibility Guidelines 1.0</cite> [<a href="#WCAG">WCAG</a>]
</div>
<div class="illustration">
<img alt="Diagram showing how levels were used in the DOM" src="qaframe-spec-levels" /><br />
Diagram illustrating levels used to build up the Document Object Model.
</div>
<p>Levels may result from progressive historical development and enrichment of the technology in a series of specifications, as in the case of <acronym title="Cascading Style Sheets">CSS</acronym> and <acronym title="Document Object Model">DOM</acronym>. Levels could also be defined explicitly in a single edition of the specification, as in the Web Content Accessibility Guidelines.</p>
<p>Sometimes, the nesting goal of levels is achieved through profiles. For example, SVG 1.1 [<a href="#SVG11">SVG11</a>] together with SVG Mobile [Mobile [<a href="#SVG-MOBILE">SVG-MOBILE</a>] define three nested profiles — Tiny, Basic, Full — which are each targeted at a specific graphics hardware community (mobile phone, hand-held computer, desktop computer).</p>
<h2>7. <a id="optionality" name="optionality">Discretionary items</a></h2>
<p>Discretionary items are defined as 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.</p>
<p>Discretionary items are often made available in specifications to give implementers of the technology the opportunity to decide from alternatives when building applications and tools. Discretionary items may be considered necessary because of environmental conditions (e.g., hardware limitations, software configuration, or external systems), locality (e.g., time zone or language), optional choices providing flexibility of implementation, dependence on other specifications, etc. By explicitly mentioning discretionary items, the specification calls attention to variability that will be of interest to both implementers and consumers of the technology. Of course, conformance testers will also want to know about such variability.</p>
<p>Discretionary items come in three basic variants:</p>
<dl>
<dt>1. Discretionary choices</dt>
<dd>A value or behavior may be chosen from a well-defined enumerated set of two or more possibilities. In some cases, the implementer may be able to provide a parameter that will allow the end-user to choose among all the values/behaviors that the implementer has implemented.</dd>
<dt>2. Optional features</dt>
<dd>A well-defined feature may be supported or not (if supported, then the requirements are clear and unambiguous). For example, XML data may be validated or not. Any discretionary item that may fit this definition should be reviewed to determine whether it is significant enough to rise to the level of being a <a href="#subdivision-module">module</a>. A module is substantial enough that a consumer of the technology would probably want to know at time of purchase whether the module has been implemented. Another situation that warrants designating a module occurs when several facets of the technology are affected and must be consistent.</dd>
<dt>3. Implementation dependent values (or features)</dt>
<dd>The set of values an element or attribute may have is open-ended and undefined with the possible exception of a required value. For example, character collations have open-ended variation, but specifications that require collation capability will often require one particular collation (based on Unicode code-point values) to establish common ground. An implementation-dependent feature is one whose end result must occur, but the behavior that leads to that end result is discretionary. For example, XQuery [<a href="#XQUERY">XQUERY</a>] addresses a data store as if it were an XML-style tree structure, but allows the actual storage to be implementation-dependent as long as the fetched values are consistent with the tree structure.</dd>
</dl>
<p>The above have the following common traits: the Working Group recognized that variation is possible, they recognized that users of the technology will need to know the behavior of any given implementation, and they chose not to force uniform behavior. This can be contrasted to other types of implementation-defined behavior that the Working Group chose to leave unspecified. A common example of this is the behavior when multiple errors are present in the input.</p>
<p>Since explicit recognition of discretionary items has benefits for many stakeholders, it is good practice to provide an identifier for each item. Where individual choices have been identified, those can also be given names (exact <code>NMTOKEN</code> values if used as parameters or attributes). This will promote proper comparison of different implementations.</p>
<h2>8. <a id="deprecated" name="deprecated">Deprecated features</a></h2>
<p>The need for deprecation occurs when features defined in the specification have become outdated and are being phased out, usually in favor of a specified replacement. Discussion of deprecation appears in part <a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#deprecation">2.4.4 of the <cite>Specification Guidelines</cite></a> [<a href="#SPECGL">SPECGL</a>].</p>
<h2>9. <a id="extensibility" name="extensibility">Extensibility</a></h2>
<p>To accommodate changes in technology and information on the Web, a specification can be designed for extensibility. A specification is extensible when it provides a mechanism to allow an external party to create extensions. Extensions incorporate additional features beyond what is defined in the specification. Extensibility could apply to a particular module or profile. Additional discussion of extensibility appears in part <a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#extensions">2.4.3 of the <cite>Specification Guidelines</cite></a> [<a href="#SPECGL">SPECGL</a>].</p>
<h2>Appendix A: <a id="umbrella" name="umbrella">Umbrella specifications</a></h2>
<p>It is not always practical, desirable, or possible to have a monolithic specification - that is, one that presents the requirements for a technology in a single document. The Working Group may produce several documents that act collectively to specify the technology (e.g., Web Ontology Language OWL). There are all sorts of reasons for having or needing a collection or series of specifications to describe a technology. These reasons include:</p>
<ul>
<li>the technology is too big to present in one document,</li>
<li>the technology evolves over time</li>
<li>the technology is easier to understand or organize as multiple documents</li>
<li>the technology consists of several modules or subdivisions that revolve around a single information model or framework.</li>
</ul>
<p>In these cases, there should be a single document, called an umbrella specification that ties all the documents together. The umbrella specification serves as foundation or "Read me First" document for the entire collection or series. It can provide:</p>
<ul>
<li>a roadmap to the documents, including listing them</li>
<li>a global view to the technology,</li>
<li>an explanation or rationale for creating a series of documents</li>
<li>a description of each document</li>
<li>terminology that applies across the technology</li>
<li>describe the relationship among the documents</li>
<li>conformance clause for the technology</li>
<li>discussion of the conformance model and/or conformance consequences when selection among the documents.</li>
<li>PICs for the technology</li>
<li>a tutorial to the technology</li>
</ul>
<div class="figure" id="fig-Umbrella">
<p class="figure-title">Figure 1: Umbrella specification</p>
<p><img height="240" alt="Diagram illustrating the notion of umbrella specification as a composite document specification." src="Umbrella-Specification.png" width="319" /></p>
<p class="figure-description">In 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.</p>
</div>
<h3 id="umbrella-example">Examples of umbrella specifications</h3>
<p><cite><a href="http://www.w3.org/TR/xmlschema-0/">XML Schema Part 0: Primer Second Edition</a></cite> is <q>a non-normative document intended to provide an easily readable description of the XML Schema facilities, and is oriented towards quickly understanding how to create schemas using the XML Schema language.<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html">XML Schema Part 1: Structures</a> and <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html">XML Schema Part 2: Datatypes</a> provide the complete normative description of the XML Schema language. This primer describes the language features through numerous examples which are complemented by extensive references to the normative texts.</q></p>
<p><cite><a href="http://www.w3.org/TR/rdf-primer/">RDF Primer</a></cite> is <q>one document in a set of six (Primer, Concepts, Syntax, Semantics, Vocabulary, and Test Cases) intended to jointly replace the original Resource Description Framework specifications, RDF Model and Syntax (1999 Recommendation) and RDF Schema (2000 Candidate Recommendation). The Primer is designed to provide the reader with the basic knowledge required to effectively use RDF. It introduces the basic concepts of RDF and describes its XML syntax. It describes how to define RDF vocabularies using the RDF Vocabulary Description Language, and gives an overview of some deployed RDF applications. It also describes the content and purpose of other RDF specification documents.</q></p>
<p><cite><a href="http://www.w3.org/TR/owl-guide/">OWL Guide</a></cite> and <cite><a href="http://www.w3.org/TR/owl-features/">OWL Overview</a></cite> are other examples which approach the concept of Umbrella Specification. All documents of the OWL series refer to the <a href="http://www.w3.org/TR/2004/REC-owl-features-20040210/#s1.1">Document Roadmap</a> which gives more context.</p>
<h2>Appendix B. <a id="acknowledgments" name="acknowledgments">Acknowledgments</a></h2>
<p>The following QA Working Group and Interest Group participants have contributed significantly to the content of this document:</p>
<ul>
<li>Tim Boland (NIST)</li>
<li>Patrick Curran (Sun Microsystems)</li>
<li>Dimitris Dimitriadis (Ontologicon)</li>
<li>Karl Dubost (W3C)</li>
<li>Dominique Hazaël-Massieux (W3C)</li>
<li>Lofton Henderson (CGM Open)</li>
<li>Ian Jacobs (W3C)</li>
<li>Richard T. Kennedy (Boeing)</li>
<li>Sandra Martinez (NIST)</li>
<li>David Marston (IBM Research)</li>
<li>Lynne Rosenthal (NIST)</li>
<li>Alex Rouskov (Measurement Factory)</li>
<li>Mark Skall (NIST)</li>
<li>Andrew Thackrah (Open Group)</li>
<li>Olivier Théreaux (W3C)</li>
</ul>
<h2>Appendix C. <a id="references" name="references">References</a></h2>
<p>These references are informative.</p>
<dl>
<!-- Generated from http://www.w3.org/2002/01/tr-automation/tr-biblio-ui with:
DOM http://www.w3.org/TR/DOM-Level-3-Core/ HTML4 http://www.w3.org/TR/html401 INFOSET http://www.w3.org/TR/xml-infoset MATHML http://www.w3.org/TR/MathML2/ OWL http://www.w3.org/TR/owl-ref/ SMIL20 http://www.w3.org/TR/SMIL/ SOAP http://www.w3.org/TR/soap12-part1/ SPECGL http://www.w3.org/TR/qaframe-spec/ SVG11 http://www.w3.org/TR/SVG11/ SVG-MOBILE http://www.w3.org/TR/SVGMobile/ X-M-S http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ XFORMS http://www.w3.org/TR/xforms/ XHTML-MOD http://www.w3.org/TR/xhtml-modularization/ XHTML-BASIC http://www.w3.org/TR/xhtml-basic XHTML11 http://www.w3.org/TR/xhtml11/ XMLSCHEMA2 http://www.w3.org/TR/xmlschema-2/ XPATH http://www.w3.org/TR/xpath XPOINTER http://www.w3.org/TR/xptr-framework/ XQUERY http://www.w3.org/TR/xquery XSLT http://www.w3.org/TR/xslt WCAG http://www.w3.org/TR/WAI-WEBCONTENT
-->
<dt><a name="DOM" id="DOM">DOM</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407">Document Object Model (DOM) Level 3 Core Specification</a></cite> , G. Nicol, S. Byrne, P. Le Hégaret, J. Robie, M. Champion, A. Le Hors, L. Wood, Editors, W3C Recommendation, 7 April 2004, http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407 . <a href="http://www.w3.org/TR/DOM-Level-3-Core/" title="Latest version of Document Object Model (DOM) Level 3 Core Specification">Latest version</a> available at http://www.w3.org/TR/DOM-Level-3-Core/ .</dd>
<dt><a name="HTML4" id="HTML4">HTML4</a></dt>
<dd><cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a></cite> , D. Raggett, I. Jacobs, A. Le Hors, Editors, W3C Recommendation, 24 December 1999, http://www.w3.org/TR/1999/REC-html401-19991224 . <a href="http://www.w3.org/TR/html401" title="Latest version of HTML 4.01 Specification">Latest version</a> available at http://www.w3.org/TR/html401 .</dd>
<dt><a name="INFOSET" id="INFOSET">INFOSET</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204">XML Information Set (Second Edition)</a></cite> , J. Cowan, R. Tobin, Editors, W3C Recommendation, 4 February 2004, http://www.w3.org/TR/2004/REC-xml-infoset-20040204 . <a href="http://www.w3.org/TR/xml-infoset" title="Latest version of XML Information Set (Second Edition)">Latest version</a> available at http://www.w3.org/TR/xml-infoset .</dd>
<dt><a name="MATHML" id="MATHML">MATHML</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2003/REC-MathML2-20031021/">Mathematical Markup Language (MathML) Version 2.0 (Second Edition)</a></cite> , D. Carlisle, P. Ion, N. Poppelier, R. Miner, Editors, W3C Recommendation, 21 October 2003, http://www.w3.org/TR/2003/REC-MathML2-20031021/ . <a href="http://www.w3.org/TR/MathML2/" title="Latest version of Mathematical Markup Language (MathML) Version 2.0 (Second Edition)">Latest version</a> available at http://www.w3.org/TR/MathML2/ .</dd>
<dt><a name="OWL" id="OWL">OWL</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-owl-ref-20040210/">OWL Web Ontology Language Reference</a></cite> , G. Schreiber, M. Dean, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/ . <a href="http://www.w3.org/TR/owl-ref/" title="Latest version of OWL Web Ontology Language Reference">Latest version</a> available at http://www.w3.org/TR/owl-ref/ .</dd>
<dt><a name="SMIL20" id="SMIL20">SMIL20</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2005/REC-SMIL2-20050107/">Synchronized Multimedia Integration Language (SMIL 2.0) - [Second Edition]</a></cite> , T. Michel, J. Ayars, Editors, W3C Recommendation, 7 January 2005, http://www.w3.org/TR/2005/REC-SMIL2-20050107/ . <a href="http://www.w3.org/TR/SMIL/" title="Latest version of Synchronized Multimedia Integration Language (SMIL 2.0) - [Second Edition]">Latest version</a> available at http://www.w3.org/TR/SMIL/ .</dd>
<dt><a name="SOAP" id="SOAP">SOAP</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/">SOAP Version 1.2 Part 1: Messaging Framework</a></cite> , H. Frystyk Nielsen, J. Moreau, M. Gudgin, N. Mendelsohn, M. Hadley, Editors, W3C Recommendation, 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ . <a href="http://www.w3.org/TR/soap12-part1/" title="Latest version of SOAP Version 1.2 Part 1: Messaging Framework">Latest version</a> available at http://www.w3.org/TR/soap12-part1/ .</dd>
<dt><a name="SPECGL" id="SPECGL">SPECGL</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/">QA Framework: Specification Guidelines</a></cite> , K. Dubost, L. Rosenthal, D. Hazaël-Massieux, L. Henderson, Editors, W3C Recommendation, 17 August 2005, http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/ . <a href="http://www.w3.org/TR/qaframe-spec/" title="Latest version of QA Framework: Specification Guidelines">Latest version</a> available at http://www.w3.org/TR/qaframe-spec/ .</dd>
<dt><a name="SVG11" id="SVG11">SVG11</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/">Scalable Vector Graphics (SVG) 1.1 Specification</a></cite> , D. Jackson, J. Ferraiolo, \u85e4\u6ca2, Editors, W3C Recommendation, 14 January 2003, http://www.w3.org/TR/2003/REC-SVG11-20030114/ . <a href="http://www.w3.org/TR/SVG11/" title="Latest version of Scalable Vector Graphics (SVG) 1.1 Specification">Latest version</a> available at http://www.w3.org/TR/SVG11/ .</dd>
<dt><a name="SVG-MOBILE" id="SVG-MOBILE">SVG-MOBILE</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2003/REC-SVGMobile-20030114/">Mobile SVG Profiles: SVG Tiny and SVG Basic</a></cite> , T. Capin, Editor, W3C Recommendation, 14 January 2003, http://www.w3.org/TR/2003/REC-SVGMobile-20030114/ . <a href="http://www.w3.org/TR/SVGMobile/" title="Latest version of Mobile SVG Profiles: SVG Tiny and SVG Basic ">Latest version</a> available at http://www.w3.org/TR/SVGMobile/ .</dd>
<dt><a name="X-M-S" id="X-M-S">X-M-S</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSVG-20020809/">An XHTML + MathML + SVG Profile</a></cite> , M. Ishikawa, Editor, W3C Working Draft (work in progress), 9 August 2002, http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSVG-20020809/ . <a href="http://www.w3.org/TR/XHTMLplusMathMLplusSVG/" title="Latest version of An XHTML + MathML + SVG Profile">Latest version</a> available at http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ .</dd>
<dt><a name="XFORMS" id="XFORMS">XFORMS</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2003/REC-xforms-20031014/">XForms 1.0</a></cite> , R. Merrick, M. Dubinko, L. L. Klotz, T. V. Raman, Editors, W3C Recommendation, 14 October 2003, http://www.w3.org/TR/2003/REC-xforms-20031014/ . <a href="http://www.w3.org/TR/xforms/" title="Latest version of XForms 1.0">Latest version</a> available at http://www.w3.org/TR/xforms/ .</dd>
<dt><a name="XHTML-MOD" id="XHTML-MOD">XHTML-MOD</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/">Modularization of XHTML\u2122</a></cite> , S. Dooley, S. Schnitzenbaumer, F. Boumphrey, T. Wugofski, M. Altheim, S. McCarron, Editors, W3C Recommendation, 10 April 2001, http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/ . <a href="http://www.w3.org/TR/xhtml-modularization/" title="Latest version of Modularization of XHTML\u2122">Latest version</a> available at http://www.w3.org/TR/xhtml-modularization/ .</dd>
<dt><a name="XHTML-BASIC" id="XHTML-BASIC">XHTML-BASIC</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2000/REC-xhtml-basic-20001219">XHTML\u2122 Basic</a></cite> , P. Stark, T. Wugofski, M. Ishikawa, S. Matsui, T. Yamakami, M. Baker, Editors, W3C Recommendation, 19 December 2000, http://www.w3.org/TR/2000/REC-xhtml-basic-20001219 . <a href="http://www.w3.org/TR/xhtml-basic" title="Latest version of XHTML\u2122 Basic">Latest version</a> available at http://www.w3.org/TR/xhtml-basic .</dd>
<dt><a name="XHTML11" id="XHTML11">XHTML11</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2001/REC-xhtml11-20010531">XHTML\u2122 1.1 - Module-based XHTML</a></cite> , M. Altheim, S. McCarron, Editors, W3C Recommendation, 31 May 2001, http://www.w3.org/TR/2001/REC-xhtml11-20010531 . <a href="http://www.w3.org/TR/xhtml11/" title="Latest version of XHTML\u2122 1.1 - Module-based XHTML">Latest version</a> available at http://www.w3.org/TR/xhtml11/ .</dd>
<dt><a name="XMLSCHEMA2" id="XMLSCHEMA2">XMLSCHEMA2</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema Part 2: Datatypes Second Edition</a></cite> , P. V. Biron, A. Malhotra, Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ . <a href="http://www.w3.org/TR/xmlschema-2/" title="Latest version of XML Schema Part 2: Datatypes Second Edition">Latest version</a> available at http://www.w3.org/TR/xmlschema-2/ .</dd>
<dt><a name="XPATH" id="XPATH">XPATH</a></dt>
<dd><cite><a href="http://www.w3.org/TR/1999/REC-xpath-19991116">XML Path Language (XPath) Version 1.0</a></cite> , J. Clark, S. J. DeRose, Editors, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xpath-19991116 . <a href="http://www.w3.org/TR/xpath" title="Latest version of XML Path Language (XPath) Version 1.0">Latest version</a> available at http://www.w3.org/TR/xpath .</dd>
<dt><a name="XPOINTER" id="XPOINTER">XPOINTER</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2003/REC-xptr-framework-20030325/">XPointer Framework</a></cite> , N. Walsh, P. Grosso, E. Maler, J. Marsh, Editors, W3C Recommendation, 25 March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ . <a href="http://www.w3.org/TR/xptr-framework/" title="Latest version of XPointer Framework">Latest version</a> available at http://www.w3.org/TR/xptr-framework/ .</dd>
<dt><a name="XQUERY" id="XQUERY">XQUERY</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2005/WD-xquery-20050404/">XQuery 1.0: An XML Query Language</a></cite> , J. Robie, D. Florescu, J. Siméon, D. Chamberlin, S. Boag, M. F. Fernández, Editors, W3C Working Draft (work in progress), 4 April 2005, http://www.w3.org/TR/2005/WD-xquery-20050404/ . <a href="http://www.w3.org/TR/xquery" title="Latest version of XQuery 1.0: An XML Query Language">Latest version</a> available at http://www.w3.org/TR/xquery .</dd>
<dt><a name="XSLT" id="XSLT">XSLT</a></dt>
<dd><cite><a href="http://www.w3.org/TR/1999/REC-xslt-19991116">XSL Transformations (XSLT) Version 1.0</a></cite> , J. Clark, Editor, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xslt-19991116 . <a href="http://www.w3.org/TR/xslt" title="Latest version of XSL Transformations (XSLT) Version 1.0">Latest version</a> available at http://www.w3.org/TR/xslt .</dd>
<dt><a name="WCAG" id="WCAG">WCAG</a></dt>
<dd><cite><a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/">Web Content Accessibility Guidelines 1.0</a></cite> , W. Chisholm, G. Vanderheiden, I. Jacobs, Editors, W3C Recommendation, 5 May 1999, http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/ . <a href="http://www.w3.org/TR/WAI-WEBCONTENT" title="Latest version of Web Content Accessibility Guidelines 1.0">Latest version</a> available at http://www.w3.org/TR/WAI-WEBCONTENT .</dd>
</dl>
</body>
</html>