index.html 193 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="utf-8"?>
<!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" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

  <title>QA Framework: Specification Guidelines</title>

  <meta name="Keywords" content="qa, quality assurance, conformance, specification" />
  <meta name="Description" content="The goal of this document is to help W3C editors write better specifications, by making a specification easier to interpret without ambiguity and clearer as to what is required in order to conform." />

  <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: Specification Guidelines Recommendation" />
  <meta name="DC.Description.Abstract" xml:lang="en" lang="en" content="The goal of this document is to help W3C editors write better specifications, by making a specification easier to interpret without ambiguity and clearer as to what is required in order to conform." />
  <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="style/guideline.css" />
    <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-REC" />
</head>

<body>

<div class="head">
<a href="http://www.w3.org/"><img height="48" width="72" alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a>

<h1 id="spec-title">QA Framework: Specification Guidelines</h1>

<h2 id="dated-subtitle">W3C Recommendation 17 August 2005</h2>

<dl>
  <dt>This version:</dt>
    <dd><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/">http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/</a></dd>
  <dt>Latest version:</dt>
    <dd><a href="http://www.w3.org/TR/qaframe-spec/">http://www.w3.org/TR/qaframe-spec/</a></dd>
  <dt>Previous version:</dt>
<dd><a href="http://www.w3.org/TR/2005/PR-qaframe-spec-20050629/">http://www.w3.org/TR/2005/PR-qaframe-spec-20050629/</a></dd>
  <dt>Editors:</dt>
    <dd>Karl Dubost, W3C</dd>
    <dd>Lynne Rosenthal, NIST</dd>
    <dd>Dominique Hazaël-Massieux, W3C</dd>
    <dd>Lofton Henderson, CGM Open</dd>


  <dt>Contributors:</dt>
    <dd><a href="#acknowledgments">See Acknowledgments.</a></dd>
</dl>

<p>Please refer to the <a
href="http://www.w3.org/QA/2005/08/specgl-errata"><strong>errata</strong></a>
for this document, which may include some normative corrections.</p>

<p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=qaframe-spec"><strong>translations</strong></a>.</p>

<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright"> Copyright</a> &#xa9;2002-2005 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&#xae;</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 id="abstract">Abstract</h2>

<p>The goal of this document is to help W3C editors write better specifications, by making a specification easier to interpret without ambiguity and clearer as to what is required in order to conform. It focuses on how to define and specify conformance. It also addresses how a specification might allow variation among conforming implementations. The document presents guidelines or requirements, supplemented with good practices, examples and techniques.</p>

<h2 id="status">Status of This Document</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 <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#RecsW3C">W3C
Recommendation</a>. It has been reviewed by W3C Members and other interested
parties and has been endorsed by the Director. It is a stable document and
may be used as reference material or cited as a normative reference from
another document. W3C's role in making the Recommendation is to draw
attention to the specification and to promote its widespread deployment. This
enhances the functionality and interoperability of the Web.</p>

<p>This document has been produced by the <a
href="http://www.w3.org/QA/WG/" shape="rect">QA Working Group</a>, as part of the <a href="http://www.w3.org/QA/Activity">QA Activity</a>.
The English version of this specification is the only normative version. <a
href="http://www.w3.org/2003/03/Translations/byTechnology?technology=qaframe-spec">Translations</a> of this document may be available.</p>

<p>If you have any comments on this document, send them to <a
href="mailto:www-qa@w3.org" shape="rect">www-qa@w3.org</a>, a mailing
list with a <a href="http://lists.w3.org/Archives/Public/www-qa/"
shape="rect">public archives</a>. An <a href="http://www.w3.org/QA/2005/08/specgl-errata">errata
list</a> for this edition is available.</p>

<p>This document only had minor editorial corrections since it was published as a Proposed Recommendation.  Evidence of interoperation between at least two implementations of this specification are documented in the <a href="http://www.w3.org/QA/WG/2005/04/specgl-implementation-report">Implementation Report</a>.</p>

<p>The Working Group's <a href="http://www.w3.org/2004/01/pp-impl/34282/status" rel="disclosure">Patent disclosure page</a>, in conformance with the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">W3C Patent
Policy</a> of 5 February 2004, contains patent disclosures relevant to this specification. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">section 6 of the W3C Patent Policy</a>.</p>


<h2 id="table-contents">Table of contents</h2>
<ul id="contents"><li><a href="#introduction-title">1. Introduction</a><ul><li><a href="#scope-goals">1.1 Scope</a></li><li><a href="#motivation">1.2 Goals and Motivation</a></li><li><a href="#why-spec-gl">1.3 Why Specification Guidelines?</a></li><li><a href="#audience">1.4 Audience of This Document</a></li><li><a href="#about">1.5 About This Document</a></li></ul></li><li><a href="#guidelines">2. Guidelines</a><ul><li><a href="#specifying-conformance">2.1 Specifying Conformance</a><ul><li><a href="#conformance-clause">2.1.1 A conformance clause is essential.</a></li><li><a href="#specify-conformance">2.1.2 Specify how to make conformance claims.</a></li></ul></li><li><a href="#nature">2.2 Setting Up Ground Rules</a><ul><li><a href="#scope">2.2.1 Scope</a></li><li><a href="#what-conform">2.2.2 What needs to conform?</a></li><li><a href="#reference">2.2.3 Normative (and Non-Normative) References</a></li></ul></li><li><a href="#specify-conformance-need">2.3 Defining and Using Terminology</a><ul><li><a href="#define-terms-section">2.3.1 Define  terms.</a></li><li><a href="#what-mandatory">2.3.2 What is mandatory?</a></li></ul></li><li><a href="#variability">2.4 Managing Variability</a><ul><li><a href="#subdivide">2.4.1 Subdivide.</a></li><li><a href="#option">2.4.2 Optionality and Options</a></li><li><a href="#extensions">2.4.3 Extensibility and Extensions</a></li><li><a href="#deprecation">2.4.4 Deprecation</a></li><li><a href="#error">2.4.5 Error Handling</a></li></ul></li></ul></li><li><a href="#beyond-conformance">3. Beyond Conformance</a><ul><li><a href="#practice-principle">3.1 Define an internal publication and review process.</a></li><li><a href="#review-gp">3.2 Do a systematic and thorough review.</a></li><li><a href="#address-other-topics">3.3 Accessibility, Internationalization, and Device Independence Considerations</a></li></ul></li><li><a href="#conformance">4. Conformance to this document</a><ul><li><a href="#conformance-criteria">4.1 Conformance Criteria</a></li><li><a href="#normative-parts">4.2 Normative Parts</a></li><li><a href="#specgl-extensibility">4.3 Specification Guidelines Extensibility</a></li><li><a href="#specgl-claim">4.4 Conformance Claims</a></li></ul></li><li><a href="#acknowledgments">5. Acknowledgments</a></li><li><a href="#references">6. References</a></li><li><a href="#glossary">7. Glossary</a></li></ul><p>List of Requirements:</p><ul><li><a href="#include-conformance-clause-principle">Requirement 1:
Include a conformance clause.</a></li><li><a href="#define-scope-principle">Requirement 2: Define the scope.</a></li><li><a href="#implement-principle">Requirement 3:
Identify who and/or what will implement the specification.</a></li><li><a href="#ref-norm-principle">Requirement 4: Make a list of normative references.
</a></li><li><a href="#define-terms-principle">Requirement 5:
Define the terms used in the normative parts of the specification.</a></li><li><a href="#conf-label-principle">Requirement 6:
Create conformance labels for each part of the conformance model.</a></li><li><a href="#consistent-style-principle">Requirement 7:
Use a consistent style for conformance requirements and explain how to distinguish them.</a></li><li><a href="#req-opt-conf-principle">Requirement 8:
Indicate which conformance requirements are mandatory, which are recommended, and which are optional.</a></li><li><a href="#subdivide-mandatory-principle">Requirement 9:
If the technology is subdivided, then indicate which subdivisions are mandatory for conformance.</a></li><li><a href="#subdiv-constraints-principle">Requirement 10:
If the technology is subdivided, then address subdivision  constraints.</a></li><li><a href="#likehood-extension-principle">Requirement 11:
Address extensibility.</a></li><li><a href="#deprecated-feature-principle">Requirement 12:
 Identify deprecated features.</a></li><li><a href="#degree-support-principle">Requirement 13:
Define how each class of products handles each deprecated feature.</a></li></ul><p>List of Good Practices:</p><ul><li><a href="#conformance-model-gp">Good Practice 1:
Define the specification's conformance model in the conformance clause.</a></li><li><a href="#norm-informative-gp">Good Practice 2:
Specify in the conformance clause how to distinguish normative from informative content.</a></li><li><a href="#conformance-claim-gp">Good Practice 3:
Provide the wording for conformance claims.</a></li><li><a href="#ics-gp">Good Practice 4:
 Provide an Implementation Conformance Statement Pro Forma.</a></li><li><a href="#ics-claim-gp">Good Practice 5:
Require an Implementation Conformance Statement  as part of conformance claims.</a></li><li><a href="#use-example-gp">Good Practice 6:
Provide examples, use cases, and graphics.</a></li><li><a href="#write-sample-gp">Good Practice 7: Write sample code or tests.</a></li><li><a href="#ref-define-practice">Good Practice 8: When imposing requirements by normative references, address conformance dependencies.</a></li><li><a href="#define-terms-inline-gp">Good Practice 9:
Define unfamiliar terms in-line and consolidate the definitions in a glossary section.</a></li><li><a href="#reuse-terms-gp">Good Practice 10:
Use terms already defined without changing their definition.</a></li><li><a href="#formal-language-gp">Good Practice 11:
 Use formal languages when possible.</a></li><li><a href="#write-assertion-gp">Good Practice 12:
Write test assertions.</a></li><li><a href="#subdivide-foster-gp">Good Practice 13:
Create subdivisions of the technology when warranted.</a></li><li><a href="#rules-profiles-gp">Good Practice  14:
If the technology is profiled, define rules for creating new profiles.</a></li><li><a href="#need-option-gp">Good Practice 15: Use optional features as warranted.</a></li><li><a href="#label-options-gp">Good Practice 16:
Clearly identify optional features.</a></li><li><a href="#constraints-gp">Good Practice 17:
 Indicate any limitations or constraints on optional features.</a></li><li><a href="#extensions-prohibited-gp">Good Practice 18:
If extensibility is allowed, define an extension mechanism.</a></li><li><a href="#breaking-conformance-gp">Good Practice 19:
  Warn extension creators to create extensions that do not interfere with conformance.</a></li><li><a href="#define-error-gp">Good Practice 20:
Define error-handling for unknown extensions.</a></li><li><a href="#workaround-gp">Good Practice 21:
Explain how to avoid using a deprecated feature.</a></li><li><a href="#obsolete-gp">Good Practice 22:
Identify obsolete features.</a></li><li><a href="#error-handling-gp">Good Practice 23:
Define an error handling mechanism.</a></li></ul>

<h3 id="appendix">Appendix</h3>

<ul>
<li><a href="specgl-ics">QA Specification Guidelines - Implementation Conformance Statement</a></li>
</ul>

<div id="introduction">
<h2 id="introduction-title">1. Introduction</h2>

<h3 id="scope-goals">1.1 Scope</h3>

<p>This document is a guide for editors of W3C specifications. It provides guidelines for improving conformance-related characteristics.  In that respect, this document differs from other W3C process and publication-related documents. It addresses the most basic and critical topics with respect to conformance, including how to convey what is required for an implementation in order to conform and how to allow variation among conforming implementations.</p>

<p>The term <dfn>specification</dfn> is used as defined in <cite>ISO Guide 2-4</cite> [<a href="#isoguide24">ISO-GUIDE</a>] as meaning a document that prescribes requirements to be fulfilled by a product, process or service. Specifications can be defined in one document or as a coherent set of several documents (see <cite><a href="http://www.w3.org/TR/2005/WD-spec-variability-20050629/#umbrella">Umbrella specifications</a></cite> in <cite><a href="http://www.w3.org/TR/spec-variability/">Variability in Specifications</a></cite> [<a href="#VIS">VIS</a>] for more discussion), and can import requirements of other specifications with normative references.
</p>

<p>In addition to conformance, there are several other topics that should be addressed when writing a specification, such as accessibility, internationalization, security, and device independence.  These topics are not directly in the scope of this document, but are evoked in <a href="#address-other-topics">section 3.3</a>. Specification authors and editors are encouraged to consider these topics and coordinate their efforts in these areas with the relevant W3C Working Groups.</p>

<h3 id="motivation">1.2 Goals and Motivation</h3>

<p>The goal is to enable Working Groups to produce specifications that are precise, easier to interpret without ambiguity or confusion, and clearer as to what is required in order to conform. Good specifications lead to better and more interoperable implementations and foster the development of test suites and tools.</p>

<p>Everyone benefits from having well-written specifications. Editors may have less rework and thus, fewer issues raised during the development of the specification, and fewer errata once it is finished. Implementers can implement sooner and have a better chance to conform to the specification. Test developers are able to derive unambiguous test assertions. End users benefit from having interoperable solutions. W3C gains by having recommendations produced with higher quality and reduced maintenance.</p>


<h3 id="why-spec-gl">1.3 Why Specification Guidelines?</h3>

<p>It is not an easy task to write accurate, clear, complete, unbiased specifications. It requires planning, organization, and foresight about the technology, how it will be implemented and used, and how technical decisions affect conformance. This document provides a collection of requirements, good practices, examples, and techniques that lead the reader through the decisions necessary to write precise requirements and establish, define, and specify conformance for specifications.</p>

<p>Editors and authors are busy, under pressure to get the specification published, and already have a reading list of W3C documents. A good place to start is <cite><a href="http://www.w3.org/2003/Editors/">W3C Editor's Home Page</a></cite> [<a href="#EDITOR">EDITOR</a>]. This document can be used as a checklist of things to consider, a how-to guide with examples and techniques that can be adapted, and a reference for understanding conformance concepts and terminology.</p>


<h3 id="audience">1.4 Audience of This Document</h3>

<p>The primary audience of this document is editors; however, it is applicable to a broader audience including:</p>
<ul>
  <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>

<p>This document makes no distinction between the terms editors and authors and  refers to them collectively as editors.</p>


<h3 id="about">1.5 About This Document</h3>

<p>
This document is a practical guide to writing a specification, presenting editors with topics to consider. The normative content is contained in a collection of a <strong>small number of Requirements</strong>, and somewhat more <strong>Good Practices</strong>.  As explained in this specification's <a href="#conformance">conformance clause</a>, the Requirements are necessary for claiming conformance to Specification Guidelines, and the Good Practices are recommendations that will further benefit the quality of a specification.</p>

<p>The overall objective of these requirements and good practices is to facilitate the creation of a complete conformance clause in every specification. A <cite><a href="http://www.w3.org/QA/2004/08/SpecGL-template-root.html">conformance clause template</a></cite> [<a href="#CONF-TEMPLATE">CONF-TEMPLATE</a>] is provided to assist editors satisfy the requirements of this document and end up with a conformance clause. Note that for some technical reports (e.g., <cite><a href="http://www.w3.org/TR/2004/NOTE-qa-handbook-20041122/">The QA Handbook</a></cite> [<a href="#QA-HANDBOOK">QA-HANDBOOK</a>], <cite><a href="http://www.w3.org/TR/2004/REC-webarch-20041215/">Architecture of the World Wide Web, Volume One</a></cite> [<a href="#WEB-ARCH">WEB-ARCH</a>]) where conformance is not an issue (e.g., no normative content), the conformance clause may be an explanation of why there is no “conformance to this document” and may be presented in another section rather than in a separate conformance section.</p>

<p>The topics presented herein are inclusive (self-contained) and provide information needed to understand and successfully apply the Requirement or Good Practice, although related information and advanced topics may be referenced.</p>

<p>If in a hurry just read the <a href="#specifying-conformance">first guidelines section</a>, <cite>Specifying conformance</cite> — this may be all you need to read in order to reach the expected outcome of adhering to this document, i.e. specifying conformance. It serves as a roadmap to other parts of this document, which help  achieve specifying conformance.</p>


<h4 id="structure">1.5.1 Structure of This Document</h4>

<p>This document is organized into a series of guidelines such as <cite>Specifying Conformance</cite> and <cite>Managing Variability</cite>. Each of these guidelines present and explain <em>Requirements</em> and <em>Good Practices</em>.  <em>Techniques</em> and <em>Examples</em> accompany each Requirement and Good Practice. The techniques illustrate basic (and nonexhaustive) questions or methods to help  realize the Requirement/Good Practice and produce specification text.  The examples are explanations or extractions from existing W3C specifications that specifically illustrate the point  made in the Requirement/Good Practice.</p>

<p>The <a href="#conformance">conformance clause</a> of this document describes the conformance requirements  for claiming conformance to this Specification Guidelines. A specification editor who wishes to write a specification conformant to Specification Guidelines must ensure it satisfies the conformance requirements in the conformance section of this document.</p>


<h4 id="relationships">1.5.2 Other QA Framework Documents</h4>

<p>This document is useful as a standalone document or as part of a family of QA Framework documents designed to help the Working Groups improve all aspects of their quality practices.</p>
<ul>
	<li><cite><a href="http://www.w3.org/TR/2004/NOTE-qa-handbook-20041122/">The QA Handbook</a></cite> [<a href="#QA-HANDBOOK">QA-HANDBOOK</a>] is a non-normative handbook about the process and operational aspects of the quality practices of W3C Working Groups.</li>
  <li><cite><a href="http://www.w3.org/TR/spec-variability/">Variability in Specifications</a></cite> models how design decisions affecting conformance change the interoperability landscape for a specification.</li>
  <li><cite><a href="http://www.w3.org/QA/WG/2005/01/test-faq">The Test Development <abbr title="Frequently Asked Questions">F.A.Q.</abbr></a></cite> addresses some of the usual issues Working Groups have to deal with when they start developing a test suite for their specifications.</li>
  <li>Various pages in the <a href="http://esw.w3.org/topic/QA">QA Wiki</a> provide information on developing a test suite.</li>

</ul>

</div>


<h2 id="guidelines">2. Guidelines</h2>

<h3 id="specifying-conformance">2.1 Specifying Conformance</h3>

<p><dfn>Conformance</dfn> is the fulfillment of specified requirements by a product, process, or service. These requirements are detailed in a specification as part of a conformance clause and in the body of the specification. A <dfn>conformance clause</dfn> is the section of a specification that identifies all the  criteria that must be satisfied in order to claim conformance to the specification.</p>

<p>A clear presentation of conformance is  crucial to successful interoperability of implementations. The conformance model and the language used for normative information determine the testability of a specification.  They also influence the overall implementation landscape, ranging from a narrow conformance with few allowable variations in implementations to multiple conformance types, resulting in numerous variations in conforming implementations.  The model must be chosen carefully, to produce the intended implementation range.
</p>


<h4 id="conformance-clause">2.1.1 A conformance clause is essential.</h4>

<p>A good conformance clause is the ultimate goal of these guidelines, and is sanctioned by  conformance to this specification.</p>

<p>The conformance clause of a specification is a high-level description of what is required of implementations. It, in turn,  refers to other parts of the specification for  details. Ideally, readers can find any conformance-related information from its conformance clause which serves as a root source.</p>

<p>For some specifications, the conformance model may be straightforward and simple, and the <cite><a href="http://www.w3.org/QA/2004/08/SpecGL-template-root.html">conformance clause template</a></cite> [<a href="#CONF-TEMPLATE">CONF-TEMPLATE</a>] when completed, may provide most of the information needed in a conformance clause.  For other specifications, when the conformance model is complex or convoluted, the <cite>Advanced Topics</cite> references (see <cite><a href="http://www.w3.org/TR/spec-variability/">Variability in Specifications</a></cite> [<a href="#VIS">VIS</a>]) may be invaluable.</p>


<div id="include-conformance-clause">
<div class="principle">
<h5 id="include-conformance-clause-principle"><span class="principle-label">Requirement 1:</span>
Include a conformance clause.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean? </span>The conformance clause provides the answers to the important questions: what may conform and how? The conformance clause defines at a high-level, what is required of implementers of the specification.  It, in turn can refer to other parts of the specification or other specifications.  The conformance clause may partition the technology into functional subsets, such as profiles, modules or other structures.  Additionally, it may specify minimal requirements for certain functions, as well as extensibility, optional features and alternative approaches and how they are to be handled.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
The conformance clause defines what is required to claim conformance: as such, it provides communication between the specification's creators, implementers, and users as to what is required, and gives meaning to the phrase, “conforming implementation.”  Moreover, it facilitates the consistent application of conformance within a specification and across related specifications.  It promotes interoperability. </p>
</div>

<div class="related">
<p><span class="related-label">Related</span></p>
<ul>
<li><cite><a href="http://www.w3.org/QA/2004/08/SpecGL-template-root.html">Conformance clause template</a></cite> [<a href="#CONF-TEMPLATE">CONF-TEMPLATE</a>]</li>
</ul>


</div>


<div class="technique">
<h6 id="include-conformance-clause-tech">Techniques</h6>

<ul>
	<li>Use the template to create the conformance clause.
	<ul>
	<li><p>Simply complete the conformance clause template and put the result into the specification.</p> <p>To be honest, answering the questions in the conformance clause template may not be a simple matter, and may lead the Working Group into thorny issues. However, these are questions that need to be answered if the specification is to be successful, i.e., if it is to foster multiple high quality interoperating implementations.</p></li>
	<li>Create an item in the table of contents for the conformance section.
	<p>If the technology consists of multiple individual recommendations, create a table of contents item for conformance, and explain that the conformance section is in another document.</p></li>
</ul>
</li>
</ul>
</div>

<div class="example">
<h6 id="include-conformance-clause-ex">Examples</h6>
<div class="indiv-example"><p>The <cite><a href="http://www.w3.org/TR/2001/REC-ruby-20010531/">Ruby Annotation</a></cite> [<a href="#RUBY">RUBY</a>] specification is an example of a short specification with a detailed conformance clause.</p></div>
<div class="indiv-example"><p>The <cite><a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/">SVG 1.0</a></cite> [<a href="#SVG11">SVG11</a>] specification contains a detailed conformance clause for a complex modular technology.</p></div>
</div>
</div>


<div id="conformance-model">
<div class="practice">
<h5 id="conformance-model-gp"><span class="practice-label">Good Practice 1:</span>
Define the specification's conformance model in the conformance clause.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> The conformance model is the conceptual framework in which conformance is defined. It consists of and is defined by addressing at least these three topics:</p>
<ul>

	<li>What needs to conform and how — hereafter designated as <dfn>class of products</dfn>.</li>
	<li>Any special designations or concepts used to distinguish conformance categories, types, etc. (e.g., profile/module/level, well-formed/valid, A/AA/AAA).</li>
	<li>Ways that conforming implementations can vary from each other (e.g.,  optionality and extensions).</li>
</ul>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> The key is to communicate to the reader what conformance to the specification is all about. The model provides a framework for implementers, describes what they need to build in order to conform, and explains the different ways that they could claim conformance.  It provides users and customers with a basis on which to express their requirements.</p>
</div>

<div class="related">
<p><span class="related-label">Related</span> The conformance model overlaps several other topics in <cite>QA Specification Guidelines</cite>, most particularly:</p>
<ul>
	<li>Class of products, see <a href="#what-conform">section 2.2.2</a></li>
	<li>Profile, modules, levels see <a href="#subdivide">section 2.4.1</a></li>
	<li>Optionality, see <a href="#option">section 2.4.2</a></li>
	<li>Extensibility, see <a href="#extensions">section 2.4.3</a></li>
	<li>Advanced topics, see <cite><a href="http://www.w3.org/TR/spec-variability/">Variability in Specifications</a></cite> [<a href="#VIS">VIS</a>]</li>
</ul>
</div>


<div class="technique">
<h6 id="conformance-model-tech">Techniques</h6>

<ol>
<li>List the classes of products targeted by the specification.

<ol style="list-style-type:lower-alpha;">
	<li>Identify the types of products that will implement the specification.</li>
	<li>If not already done (above step), group the products into generic categories – these are the classes of products  (e.g., content, user agent, protocol, API, specification).</li>
</ol></li>

<li>List the conformance designations or conformance concepts.  To help realize this, consider these questions.

<ol style="list-style-type:lower-alpha;">
	<li>Does conformance mean something different for different classes of products?</li>
	<li>Is more than one type of conformance defined – e.g., different designations (well-formed, valid) or degrees of conformance (A, AA, AAA)?</li>
	<li>Is conformance tied to the class of products and similarly named (e.g., host-language conformance, document conformance)?</li>
</ol></li>


<li>Create a name for each way that conformance can be qualified – i.e., label it.

<ol style="list-style-type:lower-alpha;">
	<li>For specifications subdivided into modules, profiles and/or levels, is there a conformance designation associated with each type of subdivision?</li>
	<li>If the specification has options and extensibility, will these have an affect or be affected by the conformance designation?</li>
</ol>
</li>

<li>Draw a diagram to put it all together – sometimes it is easier to work from a picture.

<ol style="list-style-type:lower-alpha;">
	<li>Diagram the classes of products with associated conformance designations.</li>
	<li>Add in the subdivisions and any other variability (e.g., options, extensibility).</li>
	<li>Extract from this diagram and define the conformance model.</li>
	<li>Write the description into the specification.  Bonus - if the diagram helps to understand the model, include it. </li>
</ol>
</li>
</ol>
<div id="fig-Ruby" class="figure">
<p class="figure-title">Figure 1: Conformance Model of Ruby Specification</p>
<p><img src="Ruby-conformance-model.png" alt="Graph illustrating the Ruby Conformance Model" width="564" height="357" /></p>
<p class="figure-description">The <cite><a href="http://www.w3.org/TR/2001/REC-ruby-20010531/">Ruby Annotation</a></cite> [<a href="#RUBY">RUBY</a>] specification defines two types of conformance  tied to the content models: Simple and Full. The specification defines six types of products that we could group in three classes of products (content, specification, user agent). For each of them, the conformance section defines the requirements to fulfill Simple or Full conformance.</p>
 </div>


</div>

<div class="example">
<h6 id="conformance-model-ex">Examples</h6>

<div class="indiv-example"><p>
<cite><a href="http://www.w3.org/TR/2004/REC-xml-20040204/">XML 1.0</a></cite> [<a href="#XML10">XML10</a>] has two classes of products (document and processor). Each of those has two conformance degrees (well-formed/valid and validating/non-validating). <code>xml:base</code>, XML Namespaces and XLink could also be considered as “modules” for XML even though they have not been formally defined as such.</p></div>

<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/">SVG 1.1</a></cite> [<a href="#SVG11">SVG11</a>] has roughly four classes of products (markup fragments with various extents, generators, interpreters and viewers).  Some of these classes of products have <a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/conform.html">various degrees of conformance</a> (Appendix G: Conformance Criteria [<a href="#SVG11">SVG11</a>]), e.g., static / dynamic for interpreters and static / dynamic for high-quality for viewers. SVG 1.1 also defines modules that are grouped into profiles (tiny/mobile/full).</p></div>
</div>
</div>

<div id="norm-informative">
<div class="practice">
<h5 id="norm-informative-gp"><span class="practice-label">Good Practice 2:</span>
Specify in the conformance clause how to distinguish normative from informative content.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
Normative content is the prescriptive part of the specification, whereas informative content is for informational purposes and assists in the understanding and use of the specification. Content includes all sorts of different forms — not only descriptive prose, but also illustrations, examples, use cases, formulas and other formalisms.
</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
Conformance of implementations is defined by and measured against normative content.  Distinguishing normative content from that which is informative helps to make sure the reader can find the normative content, knows for sure that it is normative, and does not fail to notice a normative section.  This good practice aims at the high level partitioning of information (e.g., sections) in a specification.</p>
</div>

<div class="related">
<p><span class="related-label">Related</span> What is mandatory? (See <a href="#what-mandatory">section 2.3.2</a>.)</p>
</div>


<div class="technique">
<h6 id="norm-informative-tech">Techniques</h6>
<ol>


	<li>For each section in the specification:

<ul>
	<li>Determine if the content is normative or informative and explicitly label it as either “normative” or “informative.”</li>
	<li>Make the label part of the section heading (e.g., Informative References), as parenthetical text with the heading, e.g., “Glossary (Normative).”</li>
	<li><strong>Alternatively</strong>, create a list of all sections and indicate their normativity, (e.g., “<a href="#normative-parts"><cite>Normative Parts</cite></a> in this document’s conformance section”).</li>
</ul>
</li>
	<li> In the conformance clause, explain what the use and meaning (if necessary) of the words used to convey the normality and informality of the content. See <cite>Requirement 7: <a href="#consistent-style">Use a consistent style for conformance requirements and explain how to distinguish them.</a></cite> </li>
	<li>Try to avoid  language that sounds normative in an informative section. It might lead the readers to wrong assumptions.</li>
</ol>
</div>

<div class="example">
<h6 id="norm-informative-ex">Examples</h6>
<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/2002/REC-xhtml1-20020801/">XHTML 1.0</a></cite> [<a href="#XHTML10">XHTML10</a>] uses the words of RFC2119 but in an <a href="http://www.w3.org/TR/2002/REC-xhtml1-20020801/#defs">extended way</a> (See Definitions [<a href="#XHTML10">XHTML10</a>]). The specification defines each word.</p></div>
</div>
</div>


<h4 id="specify-conformance">2.1.2 Specify how to make conformance claims.</h4>

<p>The central message of this section — “have a good conformance clause” — has many ancillary details. Because the conformance clause is the foundation for defining and measuring conformance, it is also the basis for assessing conformance claims. One detail worthy of attention is “conformance claims.”</p>

<p>Rather than live with the infinite varieties of creative conformance claims that can arise in a vacuum, the specification can be proactive.</p>

<div id="conformance-claim">
<div class="practice">
<h5 id="conformance-claim-gp"><span class="practice-label">Good Practice 3:</span>
Provide the wording for conformance claims.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
It is inevitable that people (e.g., vendors, purchasers) will either claim conformance or demand conformance to a technology.    In fact, claiming conformance to a technology may be required in certain situations.  Thus, it is important to provide a consistent and unambiguous way to make these claims. Identification of the specification version, class of products, and conformance label are some of the items that could be part of such wording.
</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
Having a framework, by which to make conformance claims for a particular usage of the technology, minimizes confusion by people who are interested in such claims. Many contexts use conformance claims, including legal as part of regulations, laws, or policies and commercial when selling or buying a product.</p>
</div>

<div class="related">
<p><span class="related-label">Related</span>
Conformance claims are closely related to issues of logos and branding. See <a href="http://www.w3.org/TR/2004/NOTE-qa-handbook-20041122/#IANAL">4. Licensing and branding</a> in <cite><a href="http://www.w3.org/TR/2004/NOTE-qa-handbook-20041122/">The QA Handbook</a></cite> [<a href="#QA-HANDBOOK">QA-HANDBOOK</a>].</p>
</div>


<div class="technique">
<h6 id="conformance-claim-tech">Techniques</h6>

<ul>
<li>Provide a template for the conformance claim, including:
<ol>
	<li>The full name of the specification along with information to  identify it uniquely – version, date and the URI if applicable.</li>
	<li>Placeholders for:
   <ol style="list-style-type:lower-alpha;">
 		<li>The conformance designation – the label or type of conformance that is being claimed.</li>
		<li>The product claiming conformance with information to identify it uniquely – version, date.</li>
		<li>The date of the claim.</li>
		<li>Implementation Conformance Statement (if one exists, see <a href="#ics-gp">the next Good Practice</a>).</li>
 	</ol></li>
</ol>
</li>
</ul>

<p>Conformance Claim Template:</p>

<p>Form 1:</p>
<div class="conformance-claim">
<ul>
	<li>Specification title, date, and version:  Foo Specification, version 1.0, 29 February 2003:</li>
	<li>Specification URI: http://www.example.org/TR/2003/FOO-20032902 </li>
	<li>Completed <abbr title="Implementation Conformance Statement">ICS</abbr> URI: http://mycompany.example.com/ICS-20032902</li>
	<li>Conformance designation satisfied: “conformant processor”</li>
	<li>Product name: My_Processor, version 1.2, 1 January 2004 </li>
	<li>Date of claim:  1 April 2004</li>
</ul>
</div>

<p>Form 2:</p>
<div class="conformance-claim">
<p>On 1 April 2004, My_Processor, version 1.2, 1 January 2004, claims conformance as a “conformant processor” to the FOO Specification 1.0, 29 February 2003, available at http://www.example.org/TR/2003/FOO-20032902</p>
</div>
</div>

<div class="example">
<h6 id="conformance-claim-ex">Examples</h6>
<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/">WCAG 1.0</a></cite> [<a href="#WCAG10">WCAG10</a>] is a good example of a specification explaining how to make a conformance claim depending on the                    degree of conformance.</p></div>
</div>

<div class="indiv-example"><p><cite>Specification Guidelines</cite> <a href="#specgl-claim">section 4.4 Conformance Claims</a> provides this document's template for conformance claims.</p></div>

</div>


<div id="ics">
<div class="practice">
<h5 id="ics-gp"><span class="practice-label">Good Practice 4:</span>
 Provide an Implementation Conformance Statement pro forma.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> An <dfn>Implementation Conformance Statement</dfn> (<acronym title="Implementation Conformance Statement">ICS</acronym>) provides information about an implementation to a specification, by presenting in a uniform manner the implemented capabilities (e.g., functions, features) and options as well as limitations of the implementation. An <acronym title="Implementation Conformance Statement">ICS</acronym> pro forma typically takes the form of a blank questionnaire or checklist for an implementation.  It provides the implementer a way to indicate  the features implemented. Think of it as an inventory of what has been implemented.  Note that a completed <acronym title="Implementation Conformance Statement">ICS</acronym> does not indicate conformance of the implementation.  Hence, answering “yes” to indicate a capability is supported does not mean that the capability has been tested.</p>

<p>This Good Practice suggests that the specification itself include an <acronym title="Implementation Conformance Statement">ICS</acronym> pro forma.  Providing an <acronym title="Implementation Conformance Statement">ICS</acronym> pro forma is conducive to the statement being completed and helps to ensure consistency among completed <acronym title="Implementation Conformance Statement">ICS</acronym>es. </p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> An <acronym title="Implementation Conformance Statement">ICS</acronym> pro forma provides a concise summary of a specification, i.e., the capabilities and options defined in the specification as well as any defined subdivisions (e.g., profiles, modules) and conformance designations. The <acronym title="Implementation Conformance Statement">ICS</acronym> provided with the specification is blank, waiting for the implementer to complete.  This blank ICS provides implementers and users a quick overview of features defined in the specification. A completed <acronym title="Implementation Conformance Statement">ICS</acronym> not only provides information on what has been implemented (mandatory and optional features), but can also be used to document the presence of extensions or any specializations that have been made.  A completed <acronym title="Implementation Conformance Statement">ICS</acronym> provides information useful to facilitate the selection of applicable tests for the particular implementation.  However, that is not all.  Although the <acronym title="Implementation Conformance Statement">ICS</acronym> content is independent of testing,  associating it with conformance tests makes it an essential piece in the reporting of conformance results (see techniques in <a href="#ics-claim-gp">Good Practice 5</a>).</p>
</div>

<div class="related">
<p><span class="related-label">Related</span></p>
<ul>
	<li>Optionality, see <a href="#option">section 2.4.2</a></li>
	<li>Require an Implementation Conformance Statement as part of conformance claims. See <a href="#ics-claim-gp">Good Practice 5</a>.</li>
	<li><a href="http://portal.etsi.org/mbs/Testing/conformance/conformance.asp#PICS">ETSI Making Better Standards</a></li>
</ul>
</div>

<div class="technique">
<h6 id="ics-tech">Techniques</h6>

<ol>
	<li>Create a list, table or form listing all features (capabilities) and  indicating which are mandatory to implement.</li>
	<li>Provide space for the implementer to check:  “Yes” (to indicate the feature is implemented), “No” (to indicate it is not implemented), “Not Applicable,” and space for comments.</li>
	<li>Organize the features according to the subdivisions of the  specification or in the order they occur in the specification or in some  other logical grouping.</li>
	<li>If there are dependencies, express them. (For instance, “If you answered 'No' to this question, jump to the next section.”)</li>
	<li>Provide a tool to help implementers fill out the ICS and produce a report (e.g., in <cite><a href="http://www.w3.org/TR/2002/WD-EARL10-20021206/">EARL</a></cite> [<a href="#EARL" title="EARL Reference in Bibliography">EARL</a>]).</li>
</ol>

</div>


<div class="example">
<h6 id="ics-ex">Examples</h6>
<div class="indiv-example"><p><cite>QA Specification Guidelines</cite> provides an <acronym title="Implementation Conformance Statement"><a href="specgl-ics">ICS</a></acronym> [<a href="#QA-SPEC-ICS">QA-SPEC-ICS</a>] to help implementers to asses conformance to this document. Good Practices (informative) and Requirements (normative) are given in a table where implementers can check “Yes,” “No,” or “Not Applicable” and add comments.</p></div>

<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/">Web Content Accessibility Guidelines 1.0</a></cite> [<a href="#WCAG10">WCAG10</a>] provides a <a href="http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html">checklist of checkpoints</a> which helps the implementer to verify the accessibility of HTML documents.</p></div>

</div>
</div>


<div id="ics-claim">
<div class="practice">
<h5 id="ics-claim-gp"><span class="practice-label">Good Practice 5:</span>
Require an Implementation Conformance Statement  as part of conformance claims.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> Good Practice 5 simply puts together the previous two Good Practices. The specification not only could provide an <acronym title="Implementation Conformance Statement">ICS</acronym> pro forma for implementers, but also could require a link to the <acronym title="Implementation Conformance Statement">ICS</acronym> pro forma from its standardized conformance claim template.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> Providing a completed <acronym title="Implementation Conformance Statement">ICS</acronym> with the conformance claim might help customers and users to determine quickly the implemented capabilities as well as easily verify the level of support for individual requirements of the specifications.  Combining the <acronym title="Implementation Conformance Statement">ICS</acronym> with a conformance test suite can strengthen the claim.  Specifically, the <acronym title="Implementation Conformance Statement">ICS</acronym>, augmented with links to conformance tests, provides a very nice way to indicate not only what has been implemented, but also, what has been implemented correctly (i.e., conforms to the specification).</p>
</div>

<div class="related">
<p><span class="related-label">Related</span></p>
<ul>
	<li>See “Provide the wording for conformance claims” in <a href="#conformance-claim">section 2.1.2</a>.</li>
</ul>
</div>

<div class="technique">
<h6 id="ics-claim-tech">Techniques</h6>
<ol>

	<li>Give precise instructions for how the <acronym title="Implementation Conformance Statement">ICS</acronym> becomes part of the conformance claim. The <acronym title="Implementation Conformance Statement">ICS</acronym>  might be an external document, or the specification may link to  a precise dated document, etc.</li>
	<li>Augment the <acronym title="Implementation Conformance Statement">ICS</acronym> by providing links to the test suite, such that each feature has a test (or set of tests) associated with it.  Explain what it means to check “Yes” or “No.” Specifically, does Yes/No indicate that the implementation has  the relevant feature <em>and</em> passes the applicable tests or does Yes/No only indicate that the feature is implemented. In the latter case, to avoid confusion, we recommend adding an additional column for indicating the results of executing the tests.</li>
</ol>
</div>

<div class="example">
<h6 id="ics-claim-ex">Examples</h6>
<div class="indiv-example"><p>The WebCGM specification requires an ICS as part of a conformance claim.  The <a href="http://www.ematek.de/viewer-proforma.html">WebCGM checklist</a> describes the conformance of the subject viewer product to the WebCGM specification, according to its performance on the WebCGM Test Suite.</p></div>
</div>


</div>


<h3 id="nature">2.2 Setting Up Ground Rules</h3>

<h4 id="scope">2.2.1 Scope</h4>

<p>The path to a quality specification begins with its scope.  It is critical to convey what the specification is about by describing its intent and applicability.  As the specification develops, it is a good idea to revisit the scope to make sure it still reflects the intent of the specification or if it needs to be modified.
</p>

<div id="define-scope">
<div class="principle">
<h5 id="define-scope-principle"><span class="principle-label">Requirement 2:</span> Define the scope.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
Describe what the specification is about.  Let the reader know the topics covered in the specification.
</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
Scope is one of the first sections a reader reads, so it is important to capture their attention and make sure they understand what the specification is about.  It helps to keep the specification content focused. It helps reviewers determine when the specification is over-stepping its mandate and offers the possibility for revising the specification while it is in development. It also  helps readers know the limits or boundaries of the specification and whether it is of interest to them.</p>
</div>

<div class="technique">
<h6 id="define-scope-tech">Techniques</h6>
<ul>
	<li>Make the scope easy to find.
<ol>
	<li>Include the scope section in the beginning of the document.</li>
	<li>Make “Scope” an item in the table of contents.</li>
</ol></li>
<li>Write simple, direct statements of fact. Do not include any requirements in the scope section.  Use statements such as “This document”:
<ul>
	<li> — specifies a method of….</li>
	<li> — specifies the characteristics of….</li>
	<li> — defines….</li>
	<li> — establishes a system for….</li>
	<li> — establishes general principles for….</li>
	<li> — is a guide for….</li>
</ul>
</li>
<li> In addition to describing the subject of the specification, address the following to achieve a more complete scope:
<ul>
	<li>Applicability of the specification</li>
	<li>Purpose, objectives, and goals</li>
	<li>Types of products or services (i.e., classes of products) to which the specification applies</li>
	<li>Relationship to other specifications or technologies</li>
	<li>What is not in scope, i.e., what the specification is not about</li>
	<li>Limitations on the application of the specification.</li>
</ul>
Note that it is not necessary to write a separate statement for each of these items; rather, they can be combined.
</li>
</ul>

</div>

<div class="example">
<h6 id="define-scope-ex">Examples</h6>
<p>Many W3C specifications have included scope prose in the Abstract section. We advocate making the scope a separate section in the body of the specification, making it easy to find, and ensuring that it is an item in the table of contents.</p>

<div class="indiv-example"><p><strong>Good Scope section</strong>:</p>
<ul>
	<li><cite><a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/">SVG 1.1</a></cite> [<a href="#SVG11">SVG11</a>] in the section <a href="http://www.w3.org/TR/SVG11/intro.html">About SVG</a> </li>
	<li><cite><a href="http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/">Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0</a></cite> [<a href="#CCPP-VOCAB">CCPP-VOCAB</a>] in the section 1.1 <a href="http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/#ScopeOfDocument">Scope and Normative Elements</a></li>
</ul>
</div>

<div class="indiv-example"><p><strong>Could have been better</strong>: </p>
<ul>
	<li><cite><a href="http://www.w3.org/TR/2003/REC-MathML2-20031021/">Mathematical Markup Language (MathML) Version 2.0 (Second Edition)</a></cite> [<a href="#MATHML20">MATHML20</a>] – Introduction, although very extensive and complete, does not give a quick view of what MathML is about.  The Abstract is much better at providing a concise description of the scope of the Recommendation.</li>
	<li><cite><a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/">WCAG 1.0</a></cite> [<a href="#WCAG10">WCAG10</a>]  has an extensive and complete Introduction, but no scope.  The Abstract provides a very direct statement on the scope of the Guidelines.</li>
</ul>
</div>


</div>
</div>


<div id="use-example">
<div class="practice">
<h5 id="use-example-gp"><span class="practice-label">Good Practice 6:</span>
Provide examples, use cases, and graphics.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
Illustrate concepts, behaviors, functionality, interaction, etc. through whatever means make sense, such as examples, use cases, graphics, and sample code. They aid the understanding of the specification, especially areas that are innately complex or which the Working Group has had to explain to W3C Members or the public.  Additionally, a set of broad examples and use cases can help to clarify the specification’s scope. </p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
It is difficult to understand some concepts, behaviors, functionality, or other aspects of a specification without informative interpretations to aid the reader. Providing the reader with additional information beyond the specification’s prose, can only help in achieving implementation and interoperability.</p>
</div>

<div class="technique">
<h6 id="use-example-tech">Techniques</h6>
<p>It is up to the Working Group to determine the best way to illustrate the scope and other parts of the specification. Typically, the nature of the specification  influences the type of examples, uses cases, graphics, etc. that make sense.</p>
<ul>
	<li>Develop use cases to illustrate the specification scope.  Use easy-to-understand narrative to describe situations that are applicable to the specification. </li>
	<li>Provide examples:
	<ul>
	<li>For each behavior or functionality that was resolved from an issue.</li>
	<li>To illustrate the meaning of abstract notations (e.g., BNF).</li>
	<li>For each chapter in the specification.</li>
</ul></li>
	<li>Describe the technology features through numerous examples and complement them by references to the normative texts.</li>
	<li>Reference a non-normative tutorial document that includes informative explanation of concepts, behavior, or functionality.</li>
	<li>Provide non-normative references to resources such as books, specification annotation, test sets. These references provide annotations to the specification, pictorial illustrations, and explanations of specification rules.</li></ul>

</div>

<div class="example">
<h6 id="use-example-ex">Examples</h6>
<p>For markup specifications, provide at least one example of each markup construct; illustrate each transformation capability with an example showing input and output.</p>

<div class="indiv-example">
<p><cite><a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/">SVG 1.1</a></cite> [<a href="#SVG11">SVG11</a>]: For each element of the SVG specification, there is a verbose definition of the element, the DTD definition, the attribute definitions and an example. For instance, in the definition of the element <code>rect</code>, there are precise examples with the markup needed to generate a rectangle, a rendering of the markup as an image to help people  visualize it and a separate file with the said markup.</p>
</div>

<div class="indiv-example">
<p><cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224/">HTML 4.01</a></cite> [<a href="#HTML401">HTML401</a>]: The HTML 4.01 specification, designed in a very educative way, has some very good examples.</p>
</div>
</div>
</div>

<div id="write-sample">
<div class="practice">
<h5 id="write-sample-gp"><span class="practice-label">Good Practice 7:</span> Write sample code or tests.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
For each feature, the Working Group might seek  early implementation to demonstrate the feature. If early implementations are not available (e.g., due to commercial constraints, <abbr title="Intellectual Property Rights">IPR</abbr>, etc.), it is beneficial to write test cases to illustrate a concept or use case of the technology. This provides a way to to study the interactions between the different parts of the specification and reveal problems. Additionally, these test cases can be incorporated into a test suite.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
Developing a partial implementation (sample code) or test cases can provide an understanding of a concept or feature as well as help to keep the concept or feature focused.  Partial implementation (sample code) or test cases can save the Working Group and eventually implementers time and resources by:</p>
<ul>
	<li>Providing examples to illustrate the specification.</li>
	<li>Facilitating issue resolution.</li>
	<li>Helping to have a pre-implementation report at the Candidate Recommendation maturity level.</li>
	<li>Contributing to the development of a complete test suite.</li>
	<li>Encouraging external implementations and therefore a more complete implementation report.</li>
</ul>
</div>

<div class="related">
<p><span class="related-label">Related</span></p>
<ul>
	<li><cite><a href="http://www.w3.org/Style/CSS/Test/testsuitedocumentation-20030129.html">CSS Test Suite Documentation</a></cite> [<a href="#CSS-TEST-DOC">CSS-TEST-DOC</a>]</li>
	<li><cite><a href="http://www.w3.org/TR/2004/REC-owl-test-20040210/">OWL Test Cases</a></cite> [<a href="#OWL-TEST">OWL-TEST</a>]</li>
</ul>
</div>

<div class="technique">
<h6 id="write-sample-tech">Techniques</h6>
<ol>
	<li>Encourage the development of proofs of
concept implementations of the technology.</li>
	<li>Provide at least one example of each feature, which may also be used as the basis of a future test case.</li>
	<li>Do not put a feature into a specification without the corresponding test cases.</li>
	<li>Create a template for new feature proposals that includes a request for associated test cases.</li>
</ol>

</div>

<div class="example">
<h6 id="write-sample-ex">Examples</h6>

<div class="indiv-example"><p>The OWL Working Group synchronized the publication of their specification and the publication of the <cite><a href="http://www.w3.org/TR/2004/REC-owl-test-20040210/">OWL Test Cases</a></cite> [<a href="#OWL-TEST">OWL-TEST</a>]. They even went a bit further by making the test case the necessary step to develop a feature with its requirements.</p>
</div>
</div>
</div>

<h4 id="what-conform">2.2.2 What needs to conform?</h4>

<div id="implement">
<div class="principle">
<h5 id="implement-principle"><span class="principle-label">Requirement 3:</span>
Identify who and/or what will implement the specification.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> Clearly identify the <a href="#cop-def">class of products</a> (i.e., type of products or services) upon which the requirements are imposed.  If multiple classes of products are targeted by the specification, make sure each is described.   Examples of classes of products include: content, producer of content, player, protocol, API, agent, and guidelines.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> The class of products helps define the scope of the specification and is needed when defining conformance. It also helps the reader know the target of the specification – that is, to discover and focus on what they have turned to the document for and avoid what they may find immaterial.</p>
</div>


<div class="related">
<p><span class="related-label">Related</span></p>
<ul>
<li>Classes of Products in <cite><a href="http://www.w3.org/TR/spec-variability/">Variability in Specifications</a></cite> [<a href="#VIS">VIS</a>]</li>
</ul>
</div>


<div class="technique">
<h6 id="implement-tech">Techniques</h6>

<ul><li>Give the classes of products in the specification:
<ol>
	<li>Think about all the types of products or services that will implement this technology, group those that are similar or  achieve the same purpose, and determine the generic name for the group.  These groups are the classes of products.</li>
	<li>List these classes of products in the specification.</li>
	<li>Describe them as part of the scope.</li>
</ol></li>
</ul>
</div>

<div class="example">
<h6 id="implement-ex">Examples</h6>


<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/2003/REC-MathML2-20031021/">Mathematical Markup Language (MathML) Version 2.0 (Second Edition)</a></cite> [<a href="#MATHML20">MATHML20</a>] defines output-compliant authoring tools and input-compliant rendering/reading tools.</p></div>

<div class="indiv-example"><p><a href="http://www.w3.org/TR/2005/REC-SMIL2-20050107/smil20-profile.html">SMIL 2.0 Language Profile</a> ([<a href="#SMIL20">SMIL20</a>],
chapter 13) has two classes of products: documents and basic user
agents.</p></div>


<div class="indiv-example"><p>The <a href="http://www.w3.org/TR/ruby/#conformance">conformance section of Ruby</a> [<a href="#RUBY">RUBY</a>] is very explicit and detailed about classes of products. For each of these classes, the Ruby conformance
section defines a set of rules the implementers must
respect. Ruby defines rules for markup, DTD, document, module, generator,
and interpreter.</p></div>


</div>

</div>


<h4 id="reference">2.2.3 Normative (and Non-Normative) References</h4>


<p>Rarely written in isolation, a specification inherits from previously defined technologies. It also might set the future of other specifications by defining their base. Thus, it is essential to clearly define the nature of references to previous specifications (normative or informative) and the implications of these references for the future of the technology.</p>


<div id="ref-norm">
<div class="principle">
<h5 id="ref-norm-principle"><span class="principle-label">Requirement 4:</span> Make a list of normative references.
</h5>
</div>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> A specification is rarely developed from scratch: it usually relies on other technologies defined in different specifications. The Working Group has to identify any specifications that define the core technologies of the developed technology.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
For the Working Group, normative references have an immediate benefit: “Do not reinvent the wheel.” Using features  already defined in other documents helps to minimize the size of the specification and to avoid ambiguities by rewriting the same concepts.</p>
<p>Knowing that a part of a specification is based on another technology is a  huge benefit for implementers as it clarifies the implications for  conformance. Normative references may help implementers to minimize their work by using conformant libraries already implemented elsewhere.</p>
<p>More generally, normative references might help readers  understand where the technology is coming from and therefore how to use it in combination with other technologies they may already know.</p>
</div>

<div class="related">
<p><span class="related-label">Related</span> </p>

<ul>
	<li>Wiki Topic: <cite><a href="http://esw.w3.org/topic/NormativeReferences">Normative References</a></cite> [<a href="#WIKI-NORMATIVE-REF">WIKI-NORMATIVE-REF</a>]</li>
	<li><cite><a href="http://www.w3.org/2001/06/manual/#References">Manual of Style: References</a></cite> [<a href="#MANUAL-STYLE">MANUAL-STYLE</a>]</li>

</ul>


</div>

<div class="technique">
<h6 id="ref-norm-tech">Techniques</h6>

<ul>
	<li><p>Create a normative references list.</p><ol>
	<li>List all technologies on which the specification depends.</li>
	<li>Define precisely which version of the technologies is used in the specification.</li>
	<li>Identify each reference to these technologies in the body of the document with a clear and unique label.</li>
	<li>Make a list of all these references in a section of the document called <q>Normative References</q>.</li>
</ol></li>
      <li>Use the <a href="http://www.w3.org/2002/01/tr-automation/tr-biblio-ui">Technical Reports Bibliography Extractor</a> to generate the markup for a proper bibliography.</li>
</ul>


</div>

<div class="example">
<h6 id="ref-norm-ex">Examples</h6>

<div class="indiv-example">
<p>Most W3C specifications contain a list of normative references,  clearly identified as such, at the end of the document.</p>
</div>
</div>


<div id="ref-define">
<div class="practice">
<h5 id="ref-define-practice"><span class="practice-label">Good Practice 8:</span> When imposing requirements by normative references, address conformance dependencies.</h5>
</div>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> Each addition of  a normative reference to the specification has deep implications on the technology. Specification editors are responsible for reviewing the consequences in terms of consistency, precision, possible future changes or obsolescence as well as use of the technology under specific conditions.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> A specification defines a technology with a potentially long lifespan. The choice of precise and exact normative references is thus fundamental. Using a normative reference that evolves over time might endanger the specification or other specifications relying on it. A vague reference to the other specification as a whole may leave room for conflicting interpretations or choices among variations permitted by the other specification.</p>

<p>For the Working Group, reducing the degree of ambiguity or variation in the normative references minimizes or removes the possibility of misunderstanding. For implementers, it removes ambiguities and contradictions between different sets of technologies. It creates a stable environment for their development efforts.</p>

<p>For conformance testing to be practical, all requirements need to be unambiguous, including those imposed by normative reference to other specifications. </p>
</div>

<div class="related">
<p><span class="related-label">Related</span> </p>

<ul>
	<li>Wiki Topic: <cite><a href="http://esw.w3.org/topic/NormativeReferences">Normative References</a></cite> [<a href="#WIKI-NORMATIVE-REF">WIKI-NORMATIVE-REF</a>]</li>
</ul>

</div>

<div class="technique">
<h6 id="ref-define-tech">Techniques</h6>
<ul>
	<li><p>Each normative reference to another specification (from W3C or not) should adhere to as many of the following principles as apply:</p>
<ul>
	<li>Make reference to a precise and unique version of the other specification.</li>
	<li>When referencing a generic technology and all its future versions, be sure that the technology is orthogonal to yours and that future versions will not create incompatibilities for conformance or implementation.</li>
	<li>When referencing a generic technology and all its future versions, make it clear that the conformance requirements to a fixed version of your specification will potentially change over time to reflect changes made in the referenced technology as it changes in future versions.</li>
	<li>When using a specific feature of another specification, use the precise designation, wording of the feature and a unique and precise way to identify this feature in the specification (using the URI to the definition of the feature, using the exact section denomination).</li>
	<li>Use only the meaning defined in the reference; do not interpret or assume intention of the technology, as it may lead to different interpretations depending on the readers.</li>
	<li>Indicate any clear constraints on the reference without making it contradictory to the conformance model of the external reference.</li>
	<li>Clearly identify any normative reference that, if changed, could affect the publication schedule of your specification. Make sure that it has no implication on your conformance requirements for this version.</li>
        <li> If the referenced technology has extensibility points, indicate for each point whether your technology also extends at that point, restricts the range of extensions allowed at that point, or is transparent to that point.</li>
</ul>


	</li>
</ul>

</div>

<div class="example">
<h6 id="ref-define-ex">Examples</h6>
<p>For the purpose of illustration, the following cases demonstrate some of the problems and implications that may occur for a theoretical technology using the notion of URI or URI references — this example is <strong>not an exhaustive review</strong> of all possible cases. The definition of URI and URI references technology  exists in a specification  called RFC2396 entitled “Uniform Resource Identifiers (URI): Generic Syntax.”</p>

<p>Let us create a simple definition and give examples of possible problems that arise from this definition:</p>

<blockquote>
<p>The value of the attribute is a URI as in [RFC2396].</p>
</blockquote>
<p>For instance:</p>

<pre xml:space="preserve">
…="http://www.example.org/#foo"
…="http://[3ffe:2a00:100:7031::1]/"
…="http://666.666.666.666/"
…="foo"
…="http://www.example.org/~anaïs-nin"
</pre>

<div class="indiv-example">
<p><strong>Precise designation and reference</strong>: The first example is illegal as the example uses a URI reference as opposed to only a URI; RFC 2396 clearly distinguishes between those constructs. To make the first example a valid construct, the text should have said:</p>
<blockquote>
<p>The value of the attribute is a URI reference as defined in section 4 of [RFC2396].</p>
</blockquote>
</div>

<div class="indiv-example">
<p><strong>Superset of the reference and interpretation</strong>: RFC 2396 does not include support for IPv6 literals;  RFC 2732 introduced the syntax but it does <strong>not</strong> update RFC 2396. It is not correct to assume that it does even if it seems logical. Do not interpret the intention of the external reference.</p>
</div>


<div class="indiv-example">
<p>As a separate example, any specification that defines the behavior of a class of products that creates XML should address XML 1.1 and anticipate future XML versions. In XSLT, creation of XML is specified by <code>&lt;xsl:output method="xml" version="1.0" /&gt;</code>, and each version of XSLT defines the allowable range of values for the version attribute. Another option is to reference the XML Infoset - for instance, XML Inclusions are compatible both with XML 1.0 and XML 1.1 since they reference normatively the XML Infoset, which is the same for the two versions of XML.</p>
</div>

<div class="indiv-example">
<p>In its section <cite><a href="http://www.w3.org/TR/2005/REC-charmod-20050215/#sec-RefUnicode">Referencing the Unicode Standard
	and  ISO/IEC 10646</a></cite>, the specification <cite><a href="http://www.w3.org/TR/2005/REC-charmod-20050215/">Character
	Model for the World Wide Web 1.0: Fundamentals</a></cite>
	[<a href="#CHARMOD">CHARMOD</a>] gives detailed instructions for referencing the Unicode Standard and  ISO/IEC 10646. Specification editors are
	encouraged to follow these recommendations.</p>
</div>
</div>


<div id="specify-conformance-section">

<h3 id="specify-conformance-need">2.3 Defining and Using Terminology</h3>

<h4 id="define-terms-section">2.3.1 Define terms.</h4>

<div id="define-terms">
<div class="principle">
<h5 id="define-terms-principle"><span class="principle-label">Requirement 5:</span>
Define the terms used in the normative parts of the specification.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
The normative parts of a specification often use technical terms in a
very restricted sense; write down the definitions behind these terms. Use the same phrases to convey the same meaning. Repetition, considered a stylistic error in prose, diminishes ambiguity in a technical specification and lowers the threshold of vocabulary needed to understand the specification.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
English (like any other natural language) is ambiguous, such that a term's interpretation is context dependent. Implementers can achieve interoperability between implementations only if they have the same understanding of the specification; defining the terms used in the normative parts promotes a common understanding that contributes to accurate implementation.</p>

<p>In addition,  well-defined terms are reusable in other specifications.</p>
</div>

<div class="technique">
<h6 id="define-terms-tech">Techniques</h6>
<ol>
	<li>Review the conformance requirements/test assertions: the most important terms to define in the specification are usually easy to identify when reviewing conformance requirements or test assertions.</li>
	<li>Use the element <code>dfn</code> in HTML to indicate that this is the defining instance of the enclosed term. It will be easier to create a glossary of your terms later on. For example in this document
<pre class="indiv-example" xml:space="preserve">
&lt;dfn&gt;Conformance&lt;/dfn&gt; is the fulfillment
of a product, process, or service of specified
requirements.
</pre></li>
</ol>

</div>

<div class="example">
<h6 id="define-terms-ex">Examples</h6>
<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/">Cascading Style Sheets, level 2 (CSS2) Specification</a></cite> [<a href="#CSS20">CSS20</a>]: The interoperability of the implementation of the CSS2 box model has been problematic, due to the lack of definition for when a <q>property is set</q> (see <a href="http://lists.w3.org/Archives/Public/www-style/2001Mar/0153.html">discussion on this topic</a> on the www-style@w3.org mailing list in March 2001).</p></div>
</div>
</div>


<div id="conf-label">
<div class="principle">
<h5 id="conf-label-principle"><span class="principle-label">Requirement 6:</span>
Create conformance labels for each part of the conformance model.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
Many specifications define more than one type of conformance, where each type is applicable to a different class of products.  For example, a language specification may define two conformance types – one for a parser and another for documents (i.e. content). Associate a well-defined label for each different type of conformance.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
Having a label associated with each type of conformance helps interoperability, testing, and branding.  It gives implementers a way to identify and discuss their implementations and express the degree to which an implementation has met a  specific set of requirements in the conformance clause.  It gives test developers a meaningful set of requirements to develop tests for and against which to make conformance verdicts. It gives users a way to articulate their purchasing requirements by having a unique way to refer to conforming implementations.</p>
</div>

<div class="technique">
<h6 id="conf-label-tech">Techniques</h6>
<ol>
	<li>Review all the different types of conformance in the specification (ideally, they should be listed in the conformance clause).</li>
	<li>Make sure all types  have an associated label and that this label is clearly defined. Provide a summary of the conformance labels, including the label and its definition.</li>
</ol>
</div>

<div class="example">
<h6 id="conf-label-ex">Examples</h6>
<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/2004/REC-xml-20040204/">XML 1.0</a></cite> [<a href="#XML10">XML10</a>] defines a well-formed XML document, a valid XML document.</p></div>
<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/">WCAG 1.0</a></cite> [<a href="#WCAG10">WCAG10</a>]
 defines a level A conformant document.
</p></div>
<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/">SVG 1.1</a></cite> [<a href="#SVG11">SVG11</a>] defines “conforming SVG document fragments,” “conforming interpreters,” “conforming viewers.”</p></div>
</div>

</div>

<div id="define-terms-inline">
<div class="practice">
<h5 id="define-terms-inline-gp"><span class="practice-label">Good Practice 9:</span>
Define unfamiliar terms in-line and consolidate the definitions in a glossary section.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
Put the definition of any new term along with its first occurrence in
the text, but make sure that all the definitions are also available from
a central glossary section.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
Having the definition in-line makes it easier to read the whole
specification from top to bottom, while a centralized glossary section is handy both for a reader who is consulting a
specific section of the specification, and for others who may reuse the definitions.
</p>
</div>

<div class="technique">
<h6 id="define-terms-inline-tech">Techniques</h6>
<ul>
	<li>With <cite><a href="http://www.w3.org/2002/xmlspec/">XMLspec</a></cite> [<a href="#XMLSPEC">XMLSPEC</a>], <code>&lt;termdef&gt;</code> and <code>&lt;term&gt;</code> markup in-line make it possible to build a glossary automatically with <code>&lt;glist&gt;</code>.</li>
	<li>With XHTML, <a href="http://www.w3.org/2004/07/def-to-glossary.xsl">an XSLT style sheet</a> can extract the glossary from the in-line definitions.</li>
</ul>
</div>

<div class="example">
<h6 id="define-terms-inline-ex">Examples</h6>
<div class="indiv-example"><p>Thanks to  XMLspec, <cite><a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema Part 1</a></cite> [<a href="#XML-SCHEMA-1">XML-SCHEMA-1</a>] has both <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#key-va">in-line definitions</a>  and a <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#normative-glossary">glossary</a>.</p></div>
</div>
</div>

<div id="reuse-terms">
<div class="practice">
<h5 id="reuse-terms-gp"><span class="practice-label">Good Practice 10:</span>
Use terms already defined without changing their definition.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
When a definition for a term already exists (e.g. in a different
specification) and matches the specification needs, reuse the term and its
definition without changing it, and provide a reference to the source.
</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
Reusing existing terms reduces the cost of creating new definitions and
makes it easier for readers already familiar with other specifications
to get into the new one. In addition, conflicting definitions for the same term
lead to reduced interoperability.
</p>
</div>

<div class="technique">
<h6 id="reuse-terms-tech">Techniques</h6>
<ul>
	<li>Use the <cite><a href="http://www.w3.org/2003/glossary/">W3C Glossary</a></cite> [<a href="#W3C-GLOSSARY">W3C-GLOSSARY</a>] system to check if there are existing definitions of the given term.</li>
	<li>When quoting a definition from another specification, put a link back to the specification.</li>
</ul>
</div>

<div class="example">
<h6 id="reuse-terms-ex">Examples</h6>
<div class="indiv-example"><p><cite>QA Specification Guidelines</cite> reuses the terms defined globally in the <cite>QA Glossary</cite> [<a href="#QA-GLOSSARY">QA-GLOSSARY</a>] and used by all documents of the QA Framework.</p></div>
</div>
</div>

<h4 id="what-mandatory">2.3.2 What is mandatory?</h4>

<div id="consistent-style">
<div class="principle">
<h5 id="consistent-style-principle"><span class="principle-label">Requirement 7:</span>
Use a consistent style for conformance requirements and explain how to distinguish them.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
Specifications use different styles to convey conformance requirements: <cite><a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a></cite> [<a href="#RFC2119">RFC2119</a>] keywords, imperative voice, descriptive assertions, etc. Tell the readers what styles are used, especially when the specification uses different styles for different parts of the specification.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
It is important for readers to be able to differentiate requirements in the specification from non-requirements in order to either implement or review them.</p>
</div>

<div class="technique">
<h6 id="consistent-style-tech">Techniques</h6>
<ul>
<li><p>Using <cite><a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a></cite> [<a href="#RFC2119">RFC2119</a>] key words (MUST, SHOULD, MAY, …) makes it easy to spot conformance requirements. According to the RFC itself, they should be <a href="http://esw.w3.org/topic/RfcKeywords">used only to establish interoperation</a> [<a href="#WIKI-RFC-KEYWORDS">WIKI-RFC-KEYWORDS</a>]. They are usually written with distinctive formatting, such as uppercase or bold. It is a good idea to create a specific markup for them too. It will be easier to extract conformance requirements and better for accessibility (See <a href="http://www.w3.org/2001/06/manual/#RFC"><cite>The Manual of Style: RFC 2119 Key Words</cite></a> [<a href="#MANUAL-STYLE">MANUAL-STYLE</a>]).</p>
<p>A good conformance requirement using RFC Keyword is of the form: <var>subject</var> <var>rfc_keyword</var> <var>operation</var>, where <var>subject</var> is one of the classes of products, <var>rfc_keyword</var> one of MUST, SHOULD, MAY, and <var>operation</var> a verb describing one of the operations the classes of products can do (e.g. “send a message,” “process a request”).</p>
</li>

<li>The descriptive style takes a different approach. It describes the semantics of the language, rather than how it must be handled. The benefit of this approach is that it allows a wider reuse of the said semantics, but at the cost of not defining a common behavior between implementations, which may lead to interoperability issues (see also the Wiki discussion on <cite><a href="http://esw.w3.org/topic/MeaningVsBehavior">Meaning <abbr title="versus">vs.</abbr> Behavior</a></cite> [<a href="#WIKI-MEANING-BEHAVIOR">WIKI-MEANING-BEHAVIOR</a>]). Whatever descriptive style is chosen, stick to it.</li>

<li>The imperative style uses the imperative form to convey the
requirement;  guidelines or specifications that need the
reader's involvement often use it. Its weaknesses are that it does not necessarily make
clear <strong>what</strong> needs to conform (since there is no subject), and that the imperative voice may be harder to translate in some languages.</li>

<li>Avoid using language that looks normative (e.g., with RFC 2119 key words) in informative sections.</li>
</ul>

<p>Using one of these styles does not preclude using another style in a
different part of the specification, provided the reader is adequately informed. For instance, when defining a language, it is a good idea
to define first its semantics using the descriptive style, and then the
behavior of one (or more) type of implementations using RFC 2119 key words.</p>
</div>

<div class="example">
<h6 id="consistent-style-ex">Examples</h6>
<div class="indiv-example"><p>In the <cite><a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/">SVG 1.1</a></cite> [<a href="#SVG11">SVG11</a>] Recommendation, the semantics are defined in descriptive style, and the implementation
requirements are defined in RFC 2119 key words in the <a href="http://www.w3.org/TR/SVG11/conform.html">SVG 1.1 Conformance</a> section.</p></div>
</div>
</div>

<div id="req-opt-conf">
<div class="principle">
<h5 id="req-opt-conf-principle"><span class="principle-label">Requirement 8:</span>
Indicate which conformance requirements are mandatory, which are recommended, and which are optional.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
Depending on the way  conformance requirements are specified, it may or
may not be clear if an implementation needs to implement all of them or
only part of them. Try to make sure the readers can easily distinguish the different types of requirements.
</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
If implementers do not have the same understanding of what is required,
interoperability is likely to suffer in the end.</p>
</div>

<div class="technique">
<h6 id="req-opt-conf-tech">Techniques</h6>
<ul>
	<li>Use RFC 2119 key words (see Requirement A in section 3.2 above: <a href="#consistent-style">Use a consistent style for conformance requirements and explain how to distinguish them</a>).</li>

</ul>

</div>

<div class="example">
<h6 id="req-opt-conf-ex">Examples</h6>
<div class="indiv-example"><p>For instance, <cite><a href="http://www.ietf.org/rfc/rfc2616.txt">HTTP 1.1</a></cite> [<a href="#HTTP11">HTTP11</a>] defines two types of conformance, one where all the MUST are respected, and one where all the MUST and the SHOULD are implemented.</p>
</div>
</div>
</div>


<div id="formal-language">
<div class="practice">
<h5 id="formal-language-gp"><span class="practice-label">Good Practice 11:</span>
 Use formal languages when possible.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> If an existing formal language (e.g. DTD, XML Schema, …) is expressive enough to describe the technical requirements of the specification, use it, and when the English prose and the formal language overlap, make it clear which one takes precedence in case of discrepancy. Taking such a position doesn't relieve the Working Group from dealing with any discrepancies as <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#errata">errata</a> as defined in the <cite>W3C Process Document</cite> [<a href="#PROCESS-DOC">PROCESS-DOC</a>].</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>There is an immediate benefit of using a formal language, where possible, to describe conformance requirements. A formal language minimizes ambiguities introduced by the interpretation of the prose.  There is also the possibility of using existing tools for the given language to facilitate testing and validation.</p>

<p>However, prose remains necessary to allow implementers to understand the specification, as well as to express additional requirements the formal language cannot express; this means that there are possible overlaps between the prose and the formal language, in which case, it is important to define which one is the main point of reference in case of disjunction.</p>
</div>

<div class="related">
<p><span class="related-label">Related</span></p>
<ul>
	<li>Wiki: <a href="http://esw.w3.org/topic/FormalLanguageVsProse">Formal Language vs. Prose</a>? [<a href="#WIKI-FORMAL-LANGUAGE">WIKI-FORMAL-LANGUAGE</a>]</li>
    <li><cite><a href="http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt">Guidelines for the use of formal languages in IETF specifications</a></cite> [<a href="#IETF-FORMAL">IETF-FORMAL</a>]</li>
	<li><ins><cite><a href="http://www.w3.org/2004/02/Process-20040205/tr.html#errata">Errata Management</a></cite> [<a href="#PROCESS-DOC">PROCESS-DOC</a>]</ins></li>
</ul>
</div>

<div class="technique">
<h6 id="formal-language-tech">Techniques</h6>
<ul>
<li>There are plenty of formal languages used across W3C specifications: <abbr title="Document Type Definition">DTD</abbr>, XML Schema, Relax NG, <abbr title="Extended Backus-Naur Form">EBNF</abbr>, Z Notation, etc. Picking the right one depends on the kind of specifications developed (language, XML or not, protocol) and the benefit from the formal language.</li>
<li>To avoid discrepancies between the English prose and the formal language, set up a process so that a given section is bound to a given part of the formal language, and one cannot be modified without the other.</li>
<li>Use the formal language tools to validate the examples given in the specification,  to ensure they match.</li>
<li>When using several formal languages in combination, generate random content according to the rules defined in one of them and try to validate it with the others, to find discrepancies.</li>
</ul>
</div>

<div class="example">
<h6 id="formal-language-ex">Examples</h6>
<div class="indiv-example">
<p><cite><a href="http://www.w3.org/TR/2005/WD-xquery-semantics-20050404/">XQuery Formal Semantics</a></cite> [<a href="#XQUERY-SEMANTICS">XQUERY-SEMANTICS</a>] section 1.1 defines where the document is normative over the grammar specs (separate for XPath and XQuery) and where the grammar specs are normative.</p>
</div>
</div>
</div>

<div id="write-assertion">
<div class="practice">
<h5 id="write-assertion-gp"><span class="practice-label">Good Practice 12:</span>
Write test assertions.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>A <dfn>test assertion</dfn> is a measurable or testable statement of behavior, action, or condition. It is contained within or derived from the specification's requirements and provides a normative foundation from which one or more test cases can be built.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> Test assertions facilitate the development of consistent, complete specifications and promote the early development of test cases. Developing or extracting test assertions helps  uncover inconsistencies, ambiguities, gaps, and non-testable statements in the specification. It can provide early feedback to the editors regarding areas that need attention. An added benefit is that the assertions are usable as input to test development efforts.</p>
</div>

<div class="related">
<p><span class="related-label">Related</span></p>
<ul>
	<li>Wiki: <a href="http://esw.w3.org/topic/TestableOrNot">Testable or not</a>? [<a href="#WIKI-TESTABLE-NOT">WIKI-TESTABLE-NOT</a>]</li>
</ul>
</div>

<div class="technique">
<h6 id="write-assertion-tech">Techniques</h6>
<ul>
	<li>Create a template for new feature proposals that includes a section for adding test assertions.</li>
	<li>Identify all requirements in the specification and try to write corresponding test assertions.</li>
	<li>Try writing test assertions when adding features  to a specification.  Not being able to write a test assertion for the feature suggests that there is a problem in the way the feature is designed or explained.</li>
</ul>
</div>

<div class="example">
<h6 id="write-assertion-ex">Examples</h6>


<div class="indiv-example">
<p>Example 1: <cite><a href="http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/">SOAP
version 1.2 Test Assertions</a></cite> [<a href="#SOAP12-TA">SOAP12-TA</a>]</p>

<blockquote>
  <p>Assertion x1-conformance-part2</p>

  <p>Location of the assertion: SOAP 1.2 Part 1, Section 1.2</p>

  <p>Text from the specification: The implementation of an Adjunct MUST implement all the pertinent mandatory requirements expressed in the specification of the Adjunct to claim conformance with the Adjunct.</p>

  <p>Comments: This statement applies to all assertions in part 2 and as such will not be tested separately.</p>
</blockquote>
</div>

<div class="indiv-example"><p>Example 2: <cite><a href="http://www.w3.org/MarkUp/Test/HTML401/20030123/assertions/assertions_toc.html">HTML 4.01 Test Suite</a></cite> [<a href="#HTML401-TEST">HTML401-TEST</a>]</p>

<blockquote>
  <p>Assertion 6.14-1</p>

  <p>Reference: Section 6.14</p>

  <p>(must) Script data ( %Script; in the DTD) can be the content of the
  SCRIPT element and the value of intrinsic event attributes. User agents
  must not evaluate script data as HTML markup but instead must pass it on as
  data to a script engine.</p>

  <p>Tests: 6_14-BF-01.html</p>
</blockquote></div>

<div class="indiv-example"><p>Example 3: <cite><a href="http://www.w3.org/XML/Test/">XML Test Suite</a></cite> [<a href="#XML-TEST">XML-TEST</a>]</p>

<blockquote>
  <p>Section: Documents</p>

  <p>Type: Well_Formed</p>

  <p>Purpose: A well formed document must have one or more elements.</p>

  <p>Level 1</p>
</blockquote>
</div>
</div>
</div>
</div>

<h3 id="variability">2.4 Managing Variability</h3>

<p>Specifications allow for variation between conforming implementations for different reasons, e.g., adaptation to hardware capacities and extensibility.  Variability, while it can provide for broader usage of the technology, may impede interoperability.  Watch out for excessive variability – that which goes beyond the necessary.  Look for a balance between what is needed to allow for flexibility while still achieving the desired interoperability.</p>

<p>This section gives advice on finding the right balance; the reader
will also benefit from reading,  <cite><a href="/TR/spec-variability/">Variability in Specifications</a></cite>
[<a href="#VIS">VIS</a>] which goes into more detail and the analysis of variability.</p>

<div id="subdivide-section">
<h4 id="subdivide">2.4.1 Subdivide.</h4>

<p> Subdividing the technology should be done carefully.  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).  Be smart when dividing the technology so that the subdivisions provide a positive impact on implementation and interoperability and the subdivisions are not excessive.  The benefits of subdividing should outweigh the drawbacks.</p>


<div style="display:table;">
<div style="display:table-cell;width:50%;padding: 0 2em;">
<p><a name="benef" id="benef">Benefits</a>: Subdividing can:</p>
<ul>
	<li>Make the technology easier to implement.</li>
	<li>Facilitate incremental implementation.</li>
	<li>Increase interoperability by focusing the technology on specific needs.</li>
	<li>Help organize the structure of the technology.</li>
	<li>Provide better normative guidance than recommended or provide optional features in the “core” spec. </li>
	<li>Provide names for feature bundles, facilitating automated negotiation between sending and receiving products.</li>
</ul>
</div>

<div style="display:table-cell;width:50%;padding: 0 2em;">
<p>Drawbacks: Too many divisions can:</p>
<ul>
	<li>Complicate conformance by creating the need to account for more interrelationships with other subdivisions and variability (e.g., extensibility).</li>
	<li>Hurt interoperability by increasing the likelihood of incompatible implementations.</li>
	<li>Increase misinterpretation or cause conflict of requirements due to multiple or duplicated requirements.  </li>
</ul>
</div>
</div>


<div id="subdivide-foster">
<div class="practice">
<h5 id="subdivide-foster-gp"><span class="practice-label">Good Practice 13:</span>
Create subdivisions of the technology when warranted.</h5>

</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
 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., but consider carefully the <a href="#benef">costs/benefits analysis</a> before doing so.</p>

<p>If the technology is subdivided, indicate what subdivisions exist; if it is not, state that in the conformance section.</p>

<div id="fig-MPL" class="figure">
<p class="figure-title">Figure 2: One possible organization of Profiles, Modules and Levels</p>
<p><img src="SpecGL-ModProfileLevel.png" alt="Graph illustrating one possible organization of profiles, modules and levels" width="456" height="231" /></p>
<ul class="figure-description">
	<li>Module A and Module B are core modules. They are mandatory for all implementations. We could say that they define the first level of conformance which we might call Basic Conformance.</li>
	<li>Implementing Module C and Module D is required to reach the second level of conformance.  Level 2 includes Level 1.</li>
	<li>Module E is an optional module of the technology.</li>
	<li>Profile X defines an implementation of Level 2 (and thus, implicitly, Level 1 also) for a specific class of products for example.</li>
	<li>Profile Z defines an implementation of Level 1 and an optional Module E.</li>
</ul>

</div>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
 For some specifications (e.g., huge, multi-disciplined), bundling functionality into named or anonymous packages can: </p>

<ul>
	<li>Provide an additional level of scoping control. </li>
	<li>Improve readability and the ability to find areas of interest.</li>
	<li>Facilitate implementation and interoperability, since implementing the entire, monolithic specification may be impractical and undesirable.</li>
</ul>
</div>

<div class="related">
<p><span class="related-label">Related</span> <cite><a href="http://www.w3.org/TR/spec-variability/">Variability in Specifications</a></cite> [<a href="#VIS">VIS</a>] contains additional information on  three methods to subdivide technologies: Profiles, Levels and Modules. </p>
</div>


<div class="technique">
<h6 id="divide-foster-tech">Techniques</h6>
<ul>
	<li><strong>Use profiles</strong>. <dfn>Profiles</dfn> are subsets of a technology tailored to meet specific functional requirements of application communities.  The specification may define individual profiles, and may also define rules for creating new profiles. An individual profile defines the requirements for classes of products that conform to that profile.  Rules for profiles define validity criteria for profiles themselves.</li>
	<li><strong>Use functional levels (<abbr title="also known as">a.k.a.</abbr> levels)</strong>.   <dfn>Functional levels</dfn> are a hierarchy of nested subsets, ranging from minimal or core functionality to full  functionality.  Levels are a good way to facilitate incremental development and implementation.   </li>
	<li><strong>Use modules</strong>.  <dfn>Modules</dfn> 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., an audio and a video module.  Implementers commonly  choose multiple modules to implement.</li>
</ul>
</div>

<div class="example">
<h6 id="divide-foster-ex">Examples</h6>

<div class="indiv-example"><p>Profile:  <cite><a href="http://www.w3.org/TR/2003/REC-SVGMobile-20030114/">Mobile SVG Profiles: SVG Tiny and SVG Basic</a></cite> [<a href="#SVG-TINY">SVG-TINY</a>] is a profile aimed at mobile phones.</p></div>

<div class="indiv-example"><p>Profile: <cite><a href="http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/">XHTML Modularization</a></cite> [<a href="#XHTML-MOD">XHTML-MOD</a>] in section 3 and <cite><a href="http://www.w3.org/TR/2005/REC-SMIL2-20050107/">Synchronized Multimedia Integration Language (SMIL 2.0) Specification</a></cite> [<a href="#SMIL20">SMIL20</a>] define rules for profiles.</p></div>

<div class="indiv-example"><p>In <acronym title="Cascading Style Sheet">CSS</acronym> and <acronym title="Document Object Model">DOM</acronym>, levels are the result of progressive historical development and technology enrichment realized in a series of specifications. </p></div>

<div class="indiv-example"><p>Profile/Level combination: <cite><a href="http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/">Mobile SVG Profile: SVG Tiny, Version 1.2</a></cite> [<a href="#SVG-MOBILE">SVG-MOBILE</a>] define three  profiles -  Tiny, Basic and Full  - which are nested, like levels, each targeted at specific hardware communities. </p></div>

<div class="indiv-example"><p> Modules: <cite><a href="http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/">XHTML Modularization</a></cite> [<a href="#XHTML-MOD">XHTML-MOD</a>] and <cite><a href="http://www.w3.org/TR/2005/REC-SMIL2-20050107/">Synchronized Multimedia Integration Language (SMIL 2.0) Specification</a></cite> [<a href="#SMIL20">SMIL20</a>]
  give good examples of modules usage.</p></div>
</div>


</div>

<div id="subdivide-mandatory">
<div class="principle">
<h5 id="subdivide-mandatory-principle"><span class="principle-label">Requirement 9:</span>
If the technology is subdivided, then indicate which subdivisions are mandatory for conformance.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
 Regardless of the subdivision technique (i.e., profile, level or module) used, state whether one or more of the subdivisions is required for conformance.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
 Subdividing the technology affects and can complicate conformance with all the various combination of choices it provides.  Thinking about the various possibilities helps to structure the conformance model, taking into account how the subdivision can affect various classes of products.  Implementers as well as users need to know what is mandatory, optional, prohibited or conditional with respect to choosing what to implement and still be conforming.</p></div>


<div class="technique">
<h6 id="subdivide-mandatory-tech">Techniques</h6>

<p>In the conformance clause, list the subdivisions that are mandatory for conformance. To help build this list, consider the following questions for each subdivision:</p>

<ol>
	<li>Can an implementation conform without implementing the subdivision?</li>
	<li>Does the subdivision apply to specific classes of products and not to others?</li>
	<li>Is the subdivision dependent upon other subdivisions (that is, if it is implemented must others also be implemented)?</li>
</ol>
</div>

<div class="example">
<h6 id="subdivide-mandatory-ex">Examples</h6>
<p> Content can be required to conform to one of the subdivisions (e.g., profiles)  or it may be conformant to the specification independently of a subdivision. For example, a question might arise for a producer of content: Is an implementation conforming if it generates content that is otherwise valid but does not conform to the subdivision? </p>

<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/">WCAG 1.0</a></cite> [<a href="#WCAG10">WCAG10</a>]
 defines three levels of conformance.</p></div>

<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/">XHTML Modularization</a></cite> [<a href="#XHTML-MOD">XHTML-MOD</a>]
 defines minimal requirements for including certain basic modules when designing an XHTML Modularization-conformant document.</p></div>
</div>
</div>

<div id="subdiv-constraints">
<div class="principle">
<h5 id="subdiv-constraints-principle"><span class="principle-label">Requirement 10:</span>
If the technology is subdivided, then address subdivision  constraints.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
This Requirement is a corollary to <a href="#subdivide-mandatory-principle">Requirement 9</a>. Beyond being mandatory or not, subdivisions usually have conformance consequences due to minimal or new requirements, restrictions, interrelationships, and variability.  As part of the conformance clause, describe the  constraints associated with each subdivision.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
 Creating subdivisions can get complicated, not just for the specification editors but also for implementers who have to  choose from the set of subdivisions. Well-designed subdivisions that convey the conditions, constraints, interrelationships, etc. can improve the clarity and understanding of the specification, conformance to the specification, and facilitate implementation and interoperability. </p>
</div>

<div class="technique">
<h6 id="subdiv-constraints-tech">Techniques</h6>
<p> In the conformance clause, describe the conditions or constraints on subdivision usage.  To help accomplish this, model or graph the subdivisions indicating what applies from the following list:</p>
<ol>
	<li>Atomicity of the subdivisions: Show whether each subdivision can be used only as a whole or not.</li>
	<li>Mandatory subdivisions: Label the mandatory subdivisions as such.</li>
	<li>Minimal requirements: List the minimal requirements for each subdivision.</li>
	<li>Dependencies among subdivisions: Show the dependencies and interrelationships of the subdivisions. For example, show the modules that require and build on functionally related modules, i.e., modules that require modules from other functional areas.</li>
	<li>Conditions and constraints on subdivisions groups: Indicate conditions and constraints for combined occurrences of subdivision pairs or groups.</li>
	<li>Conditions or constraints associated with specific classes of products:  Indicate which conditions and constraints are applicable to specific classes of products.</li>
	<li>Other conditions or constraints beyond these:  Indicate any other conditions or constraints.</li>
</ol>


</div>

<div class="example">
<h6 id="subdiv-constraints-ex">Examples</h6>
<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/2005/REC-SMIL2-20050107/">Synchronized Multimedia Integration Language (SMIL 2.0) Specification</a></cite> [<a href="#SMIL20">SMIL20</a>] has a <a href="http://www.w3.org/TR/2005/REC-SMIL2-20050107/smil20-profile.html#SMILProfileNS-AgentConformance">SMIL 2.0 Language Profile for user agents</a> (see section 13 [<a href="#SMIL20">SMIL20</a>]) but also provides a <a href="http://www.w3.org/TR/2005/REC-SMIL2-20050107/smil-basic.html#smilBasicNS-Basic">SMIL 2.0 Basic Profile for wireless and embedded devices</a> (see section 14.3 in [<a href="#SMIL20">SMIL20</a>]). The SMIL 2.0 Language Profile requires that a user agent implement the <code>BasicAnimation</code> module but not the <code>SplineAnimation</code> module.  The SMIL 2.0 Basic Profile on the other hand does not require implementation of any of the animation modules.</p></div>

<div class="indiv-example"><p>Dependency or intertwined relationship between profiles and modules is common. The combination of <cite><a href="http://www.w3.org/TR/2002/REC-xhtml1-20020801/">XHTML 1.0</a></cite> [<a href="#XHTML10">XHTML10</a>], <cite><a href="http://www.w3.org/TR/2005/REC-SMIL2-20050107/">SMIL 2.0</a></cite> [<a href="#SMIL20">SMIL20</a>] and <cite><a href="http://www.w3.org/TR/2003/REC-SVG11-20030114/">SVG 1.1</a></cite> [<a href="#SVG11">SVG11</a>] is an example.</p></div>


</div>
</div>


<div id="rules-profiles">
<div class="practice">
<h5 id="rules-profiles-gp"><span class="practice-label">Good Practice  14:</span>
If the technology is profiled, define rules for creating new profiles.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
 If the specification defines profiles of the technology and allows other profiles to be developed outside of the specification itself, then provide the rules for creating these derived profiles.  These profile rules provide instructions for building profiles (e.g., requirements on structure, functionality, encoding, etc.). Derived profiles should not contradict predefined profiles, if there are any in the base specification. </p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> Well-defined rules  facilitate the creation of derived profiles that are well specified, implementable, testable, and can foster better interoperability across profiles.  If these rules are defined and followed, then the derived profile would conform to the specification. </p>
</div>

<div class="related">
<p><span class="related-label">Related</span> </p>
<ul>
<li>Advanced topics, see <cite><a href="http://www.w3.org/TR/spec-variability/">Variability in Specifications</a></cite> [<a href="#VIS">VIS</a>]</li>
</ul></div>


<div class="technique">
<h6 id="rules-profiles-tech">Techniques</h6>
<ol>
	<li>Create two particular profiles.</li>
	<li>Identify the common requirements in these two profiles.</li>
	<li>Identify the rules that you have followed to create these profiles and write them down.</li>
	<li>Try to create a third profile using the defined rules.</li>
</ol>
</div>

<div class="example">
<h6 id="rules-profiles-ex">Examples</h6>
<div class="indiv-example"><p><a href="http://www.w3.org/TR/2001/REC-WebCGM-20011217/">WebCGM 1.0</a> [<a href="#WEBCGM10">WEBCGM10</a>] defines <a href="http://www.w3.org/TR/2001/REC-WebCGM-20011217/REC-01-CGM-Intro.html#webcgm_1_2">rules to create Profiles</a> (see section 1.2 in [<a href="#WEBCGM10">WEBCGM10</a>]).</p></div>
</div>

</div>


</div> <!--end of D1-->


<h4 id="option">2.4.2 Optionality and Options</h4>

<p>Options in specifications provide implementers the freedom to make
choices about:</p>
<ul>
  <li>Whether or not to support a well-defined feature.</li>
  <li>Which value or behavior to choose from a well-defined enumerated set of possibilities.</li>
  <li>Implementation-dependent values or features.</li>
</ul>

<p>These choices, also called <dfn>discretionary items,</dfn> give implementers of the technology the opportunity to decide from alternatives when building their applications and tools. They describe or allow optionality of behavior, functionality, parameter values, error handling, etc. They may be considered necessary because of environmental conditions (e.g., hardware limitations or software configuration), locality differences (e.g., language or time zones), dependencies on other technologies, or the need for flexibility.</p>

<p>Although there are perceived benefits to providing optional features, there is also a downside: optional features increase the variations that can exist among
implementations. The greatest way to undo the utility of a specification is with too many optional features. Different implementations may use different combinations of optional features. This makes comparisons between
implementations difficult, complicates conformance testing, and
increases the chance of non-interoperable implementations.</p>


<div class="story">
<h4 id="option-story"><span class="story-label">Story:</span></h4>

<p>A concise <cite>XSLT 1.0</cite> [<a href="#XSLT10">XSLT10</a>] example: the specification grants implementers  separate discretion about all of the following aspects of creating attributes in the output:</p>

<ul>
	<li>Whether to raise an error when the supplied name is not a valid <code>QName</code>.</li>
	<li>Whether to raise an error when  attempting to create an attribute after having created children of the element.</li>
	<li>Whether to raise an error when attempting to create an attribute on a node that is not an element.</li>
	<li>Whether to raise an error when the content of an attribute is not plain text.</li>
	<li>Whether to raise an error when two attribute-sets of the same precedence contain an attribute of the same name.</li>
	<li>Whether to raise an error when attempting to create an attribute directly under the root of a result tree fragment.</li>
</ul>

<p>In each case,  one prescribed behavior exists for an implementation that chooses not to raise an error. Thus, the six separate binary choices give rise to 64 different possible behaviors for conformant processors. Typically, an implementer would be content to make a more global choice about raising errors when there is an attempt to create non-well-formed XML results.</p>
</div>

<div id="need-option">
<div class="practice">
<h5 id="need-option-gp"><span class="practice-label">Good Practice 15:</span> Use optional features as warranted.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> Examine the reason for the optional feature - does it address a real, existing need? Should it really be  optional or should it be made a mandatory part of the specification? Be careful not to provide optional features in anticipation of something that sounds like a good idea but whose implementation is improbable - ask the implementers if they ever plan to need this. Think about the implications of both implementing the optional feature and of not implementing it. Do not make something an option just because the Working Group cannot decide on what to do or cannot reach consensus. As the specification progresses,  consider removing unimplemented features.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> A concise list of optional features helps to keep the specification focused and  greatly increases the likelihood of obtaining interoperable solutions. Ensuring that only necessary optional features are contained in the specification also makes the job of the implementer easier and reduces costs.</p>
</div>

<div class="technique">
<h6 id="need-option-tech">Techniques</h6>

<ul>
	<li>Make a list of use cases with the optional feature.</li>
	<li>Look at the optional feature and each class of products.  Is the feature something that this class of products would implement?  Consider if it really is an option - perhaps, for this class of products it is not really an option but should be mandatory.</li>
	<li>Develop an analyzer or set of tests to determine the need for  options.  Use the analyzer/tests to capture what implementations are doing – are they doing the same thing or is there variety and is that variety desired?</li>
</ul>
 </div>


<div class="story">
<h5 id="tests-story"><span class="story-label">Story:</span></h5>
<p> As part of its exit criteria for Candidate Recommendation, a Working Group created a set of tests to “test the specification.” The tests were able to show where there was need for optionality (e.g., when diversity among implementations and flexibility were justified) and where it was possible to narrow the choices (e.g., implementations used a much narrower set of values than those permitted).</p></div>

</div>
<div id="label-options">
<div class="practice">
<h5 id="label-options-gp"><span class="practice-label">Good Practice 16:</span>
Clearly identify optional features.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> When introducing an optional feature in the specification, label it as such, so that it is easy to find all the optional features defined in the specification. If there are no optional features, state that in the conformance section.</p>
</div>


<div class="care">
<p><span class="care-label">Why care?</span>  Options can be useful, but non-judicious use of optional features increases the variability among conforming implementations. In order to minimize the unnecessary optionality, it is a good idea to provide an easy way to identify them.  The use of labels for optional features also helps in constructing pro forma conformance claims, comparisons between two implementations, reports to the W3C Director about implementations, etc.</p>
</div>

<div class="technique">
<h6 id="label-options-tech">Techniques</h6>
<p>There are many ways to tag options. Any technique that distinguishes the optional feature from the required feature is acceptable. Some possibilities are:</p>
<ul>
	<li>List optional features in a separate section.</li>
	<li>Specify optional features in a different font (be careful of accessibility and printing problems).</li>
	<li>Include a unique designation to identify the optional feature.</li>
</ul>

</div>


</div>


<div id="constraints">
<div class="practice">
<h5 id="constraints-gp"><span class="practice-label">Good Practice 17:</span>
 Indicate any limitations or constraints on optional features.</h5>
</div>


<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> Provide as much information as possible to narrow the allowable choices and to increase predictability. For implementation-dependent values or
features, if possible, provide a range or set of permitted values rather than
leaving those values completely open.</p>
<p>Discuss the implications of either using the optional feature or not. It may be helpful to provide rationale for choosing one option over another or for not using the option at all. Consider the unintended consequence of the optional feature - on other optional features, other parts of the specification, and on other specifications.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> Narrowing choices and increasing predictability enhance the likelihood of interoperability since the implementer chooses from a reduced sample space. Narrowing choices, providing more information, and eliminating incorrect choices  increases the chances of correct implementations. An enumerated list of values is one way to constrain the choice of optionality.</p>
</div>

<div class="technique">
<h6 id="constraints-tech">Techniques</h6>
<p>For optional features, especially enumerated lists, make sure to indicate the number of choices/options available for implementation. Specifically, can none, exactly one, or several of the allowable choices be implemented? Does this number depend on other parts of the specification or other chosen options?</p>
<p>Questions to consider include:</p>
<ul>
  <li>What effect will implementing the optional feature have on a conforming
    implementation? On interoperability?</li>
  <li>Is there any effect or negative consequence if the option is not
    implemented?</li>
  <li>Is implementation of the option mandatory?</li>
  <li>Is there a default value for the option?</li>
  <li>Are there any dependencies, that is, can the option only be implemented
    if certain conditions are true?</li>
  <li>Are the optional features mutually exclusive, that is, can one option override
    and void another?</li>
</ul>

</div>

<div class="example">
<h6 id="constraints-ex">Examples</h6>


<div class="indiv-example"><p>In <cite><a href="http://www.w3.org/TR/2005/WD-xpath20-20050404/">XPath 2.0</a></cite> [<a href="#XPATH20">XPATH20</a>] and its associated functions, the Working Group intends to require support for collation by Unicode code-point, and allow implementations to implement as many other collations as they wish.</p></div>
</div>
</div>


<div id="extensibility" class="section">
<h4 id="extensions">2.4.3 Extensibility and Extensions</h4>

<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. <dfn>Extensions</dfn> incorporate additional features beyond those defined in the specification. However, extensions can compromise
interoperability if there are too many differences between implementations.
Features specifically designed to allow new functionality mitigate the impact of extensions. These features provide a “standard way
to be non-standard” by including hooks, conformance rules, or other
mechanisms by which new functionality may be added in a conforming way, designated as an <dfn>extensibility mechanism</dfn>.</p>


<div id="likehood-extension">
<div class="principle">
<h5 id="likehood-extension-principle"><span class="principle-label">Requirement 11:</span>
Address extensibility.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> Extensions might be encouraged or discouraged by the Working Group. There is a benefit to addressing the value or danger of using extensibility for the given technology. Formalizing the position of the Working Group in a clearly defined section and prose  removes ambiguities for the specification users about the possibility of developing extensions or not. This section should at least address whether the specification is extensible or not.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> Implementers will most likely want to extend functionalities if their specific needs are not defined in the specification. Defining clearly how to hook extended functionalities  into conforming implementations  helps ensure  consistency in the definition of extensions. This leads to predictable handling of extensions and minimizes issues such as interoperability problems, minimal support, and harmonious future development.</p>

<p>The Working Group may consider that the technology is complete, self-sufficient and does not need to be extensible. In this case, it is necessary to write this clearly in the specification and to explain why the technology is not considered extensible. The reason might be just for the social benefit of the community to ensure a maximum interoperability.</p>
</div>

<div class="related">
<p><span class="related-label">Related</span></p>
<ul>
	<li>Wiki topic: <cite><a href="http://esw.w3.org/topic/ExtensibilityGoodOrBad">Extensibility: Good or Bad?</a></cite> [<a href="#WIKI-GOOD-BAD">WIKI-GOOD-BAD</a>]</li>

	<li> See <a href="http://www.w3.org/TR/2004/REC-webarch-20041215/#ext-version">Extensibility and Versioning</a> in <cite><a href="http://www.w3.org/TR/2004/REC-webarch-20041215/">Architecture of the World Wide Web, Volume One</a></cite> [<a href="#WEB-ARCH">WEB-ARCH</a>].</li>
</ul>


</div>

<div class="technique">
<h6 id="likehood-extension-tech">Techniques</h6>
<ol>
	<li>Create a section in the specification dedicated to extensibility.</li>
	<li>Call it <q>Extensions</q>.</li>
	<li>Make a table of contents entry for it.</li>
	<li>Address the following  Good Practices in this section.</li>
</ol>
</div>

<div class="example">
<h6 id="likehood-extension-ex">Examples</h6>

<div class="indiv-example"><p>The specification <cite><a href="http://www.w3.org/TR/2003/WD-css3-syntax-20030813/">CSS3 module: Syntax</a></cite> [<a href="#CSS3-SYNTAX">CSS3-SYNTAX</a>] has addressed the topic of <a href="http://www.w3.org/TR/2003/WD-css3-syntax-20030813/#vendor-specific">extensions for CSS 3</a>. The specification clearly identifies extensibility in the table of contents and there is a specific section for it.</p></div>
</div>
</div>


<div id="extensions-prohibited">
<div class="practice">
<h5 id="extensions-prohibited-gp"><span class="practice-label">Good Practice 18:</span>
If extensibility is allowed, define an extension mechanism.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> Extensions increase variability between implementations. Defining a mechanism  helps to ensure the definition of extensions are  consistent. Consistent extension definitions lead to predictable handling of extensions, including the ability to take appropriate actions (e.g., do the extension, ignore, or take a fallback behavior). </p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>  By planning for extensions and designing a specification for extensibility, there is less chance that extensions will interfere with conformance to the base specification and a better chance at achieving interoperability. Conversely, there may be areas in a specification that would not benefit from extensibility and extensions are strictly forbidden (e.g., permissible characters in <cite>XML 1.0</cite> names for elements and attributes [<a href="#XML10">XML10</a>], most of the built-in data types in <cite>XML Schema Part 2</cite> [<a href="#XML-SCHEMA-1">XML-SCHEMA-2</a>]). This is an example of strict conformance. Conformance of an implementation that employs only the requirements and/or functionality defined in the specification and no more defines <dfn>strict conformance</dfn> .</p>

<p>Extension mechanisms designed into a specification:</p>
<ul>
  <li>Provide a stable, useful framework to manage the rapid pace of
    technological change.</li>
  <li>Reduce the chances that extensions will interfere with conformance and
    increasing the chances for achieving interoperability.</li>
  <li>Provide the ability to “test-drive” new functionality that may
    migrate into future specifications.</li>
  <li>Enable implementers to include functionality that they consider a customer requirement.</li>
</ul>
</div>

<div class="technique">
<h6 id="extensions-prohibited-tech">Techniques</h6>
<p>Technology and
application needs  dictate the best strategy for enabling
extensibility.</p>

<p>Designing for extensibility can become complicated. Points to
consider that can affect design decisions include, but are definitely not limited to, the following topics.</p>

<ul>
  <li>Address the use of extensions in the conformance section.</li>
  <li>Provide a well-defined template that implementers can use to create extensions.</li>
  <li>Verify that the extension mechanism prevents the creation of extensions that conflict with the semantics of the specification (see <a href="#breaking-conformance-gp">Good Practice 19</a>).</li>
  <li>When needed, define the scope of extensions (e.g., are extensions authorized only for certain parts of the technology?).</li>
  <li>As an example, make a fake extension showing implementers the right way to create an extension.</li>
  <li>Indicate whether extensions interact with other extensions.</li>
  <li>Indicate whether extensions may be combined or are mutually exclusive.</li>
  <li>Indicate whether extensions apply to a specification's profiles or modules and not to the core part of the specification.</li>
  <li>Avoid “untested hooks”: if an extensibility mechanism is defined, make sure it is well tested during the implementation phase. Experience has shown that untested extensibility just does not work.</li>
</ul>


</div>


<div class="example">
<h6 id="extensions-prohibited-ex">Examples</h6>

<h6 id="error-handling-extension">Mechanism defined within the specification, extension indicator, error handling instructions</h6>

<div class="indiv-example">
<p><cite><a href="http://www.w3.org/TR/1999/REC-xslt-19991116">XSLT 1.0</a></cite> [<a href="#XSLT10">XSLT10</a>] provides <a href="http://www.w3.org/TR/1999/REC-xslt-19991116#extension">extension mechanisms</a>. They allow an XSLT style sheet to determine
whether a XSLT processor by which it is being processed has implementations of particular extensions available. The extension mechanism also allows its implementer to specify what should happen if their extensions are not available.</p>

<p>XSLT 1.0 defines two Boolean functions: <code>function-available (<var>QName</var>)</code> and <code>element-available (<var>QName</var>)</code> that must be present in every implementation. These functions inform the XSLT processor that there is an extension. The XSLT processor can therefore return a value of false. The functions provide handling instructions (e.g., signal an error, perform fallback and do not signal error) if the extension is not available.</p>
</div>

<div class="indiv-example">
<p><cite><a href="http://www.w3.org/TR/2004/WD-wsdl20-20040803/">WSDL 2.0</a></cite> [<a href="#WSDL20">WSDL20</a>] defines <a href="http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Binding_extension_elements">binding extension elements</a> which are used to provide information specific to a particular binding. It is a two-part extensibility model based on namespace-qualified elements and attributes. It provides the syntax and semantics for signaling extensions. Extension elements can be marked as mandatory, meaning that they must be processed correctly by the WSDL processor - i.e., either agree to fully abide by all the rules and semantics signaled by the extension or immediate cease processing (fault).</p>
</div>


<h6 id="another-spec-extension">Mechanism based on another specification's extension mechanism</h6>

<div class="indiv-example">
<p><cite><a href="http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624">CC/PP exchange protocol based on HTTP Extension Framework</a></cite> <a href="#CCPP-EXCHANGE">[CCPP-EXCHANGE]</a> defines a HTTP extension to exchange
CC/PP descriptions effectively. The CC/PP exchange protocol conforms to
HTTP/1.1 and is a generic extension mechanism for <cite><a href="http://www.ietf.org/rfc/rfc2616.txt">HTTP 1.1</a></cite> <a href="#HTTP11">[HTTP11]</a> designed to interoperate with existing HTTP applications. The CC/PP exchange protocol uses an extension declaration to indicate that an extension has been applied to a message and possibly to reserve a part of the header namespace. It provides rules for which of the <cite><a href="http://www.ietf.org/rfc/rfc2774.txt">HTTP Extension Framework</a></cite> [<a href="#HTTP-EXTENSION">HTTP-EXTENSION</a>] extension declaration strengths and extension declaration scopes to use and defines the syntax and semantics of the header fields.</p>
</div>


<div class="indiv-example">
<p><cite><a href="http://www.w3.org/TR/2004/REC-owl-ref-20040210/">OWL Reference</a></cite> [<a href="#OWL-REF">OWL-REF</a>] is a vocabulary extension of <cite>RDF Semantics</cite> (See <a href="http://www.w3.org/TR/rdf-mt/#MonSemExt">section 6</a> in [<a href="#RDF-MT">RDF-MT</a>]). OWL  imposes additional semantic conditions on RDF called semantic extensions of RDF. These semantic extensions conform to the semantic conditions for simple interpretations described in the RDF Semantics Recommendation. OWL semantics are consistent with RDF semantics, but when it is  understood as RDF, OWL is “incomplete” in contrast to the same OWL when understood as OWL. Thus, by understanding OWL, a process learns more than what it learns from RDF alone, but the additional semantics does not contradict the RDF semantics.</p>
</div>


</div>


</div>
</div>


<div id="breaking-conformance">
<div class="practice">
<h5 id="breaking-conformance-gp"><span class="practice-label">Good Practice 19:</span>
  Warn extension creators to create extensions that do not interfere with conformance.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> Include in the specification a warning to those who are creating extensions that extensions should not contradict or negate conformance to the original specification. Extensions can be created in different contexts: directly by implementers, in other specifications, etc.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>   Conformance should be independent of  whether there is an extension or not – if an implementation conformed without the extension, then conformance should hold true with the extension.</p>
</div>

<div class="technique">
<h6 id="breaking-conformance-tech">Techniques</h6>
<p>Include statements in the
specification such as:</p>
<ul>
  <li>Each implementation must fully support all required functionality of the specification exactly as specified.</li>
  <li>The use of extensions must not contradict nor cause the non-conformance of functionality defined in the specification.</li>
  <li>Extensions must follow the requirements and guidelines of the
    specification they extend; i.e., the specifications must be extended
    in a standard manner.</li>
</ul>
</div>

<div class="example">
<h6 id="breaking-conformance-ex">Examples</h6>
<div class="indiv-example"><p>In <cite><a href="http://www.w3.org/TR/1999/REC-xslt-19991116">XSLT 1.0</a></cite> [<a href="#XSLT10">XSLT10</a>], extension attributes (from other namespaces) can  be present on the official XSLT elements, but they are prohibited from changing the specified behavior within the detectability of conforming behavior. Specifically, an element from the XSLT namespace may have an attribute not from the XSLT namespace. The presence of such attributes must not change the behavior of XSLT elements and functions defined in the XSLT specification.  Thus for example, an extension attribute can cause the element to perform faster but cannot change the result defined in this document.</p>
</div>

<div class="indiv-example"><p>The <cite><a href="http://www.w3.org/TR/CSS21/">CSS2.1</a></cite> [<a href="#CSS21">CSS2.1</a>] specification defines the notion of <a href="http://www.w3.org/TR/CSS21/syndata.html#q4">vendor-specific extension</a>. <q cite="http://www.w3.org/TR/CSS21/syndata.html#q4">An initial dash or underscore is guaranteed never to be used in a property or keyword by any current or future level of CSS. Thus typical CSS implementations may not recognize such properties and may ignore them according to the rules for handling parsing errors. However, because the initial dash or underscore is part of the grammar, CSS2.1 implementers should always be able to use a CSS-conforming parser, whether or not they support any vendor-specific extensions.</q></p>
</div>
</div>
</div>


<div id="define-error">
<div class="practice">
<h5 id="define-error-gp"><span class="practice-label">Good Practice 20:</span>
Define error-handling for unknown extensions.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> For each class of products  affected by an error condition, include error-handling instructions for when an extension is not available or understood. </p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> When using a strict conforming application, users might have to deal with documents and data  considered invalid because they contain errors, or documents extended syntactically. Developers  need to know the expected behavior of the application in such contexts.</p>


</div>

<div class="technique">
<h6 id="define-error-tech">Techniques</h6>
<p>There are typically two approaches (see section <a href="http://www.w3.org/TR/2004/REC-webarch-20041215/#extensibility">4.2.3 Extensibility</a> from Architecture of the World Wide Web, Volume One [<a href="#WEB-ARCH">WEB-ARCH</a>]):</p>


<ul>
	<li>The “must Understand” policy, as implemented in SOAP 1.2 by the <code>mustUnderstand</code> attribute. In this approach to error-handling, a processor encountering a syntax token not defined in the specification is required to know how to process the said token or must fail for the whole unit where the token appears.</li>
	<li>The “must Ignore” policy, as implemented in SOAP 1.2 by the <code>mustIgnore</code> attribute. In this approach, a processor not knowing how to process an unknown syntax token must skip part or the totality of the unit where the token appears.</li>
</ul>
<p>A good way to handle these two approaches is to have a way in the syntax to distinguish which behavior is expected (e.g., <code>mustUnderstand</code>/<code>mustIgnore</code> attributes in SOAP 1.2). Which policy to choose depends on the importance of the
data processing, user experience with applications based on the
said format, etc.</p>


<p>Do not forget to address all the classes of products. For example, an authoring tool and a rendering tool might behave in different ways.</p>

</div>


<div class="example">
<h6 id="define-error-ex">Examples</h6>

<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/2001/REC-ruby-20010531/">Ruby Annotation</a></cite> [<a href="#RUBY">RUBY</a>] defines what <a href="http://www.w3.org/TR/2001/REC-ruby-20010531/#simple-parenthesis">parts must be ignored and displayed</a> (see section 1.2.2 in [<a href="#RUBY">RUBY</a>]) when an unknown element is met).</p></div>

<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224/">HTML 4.01</a></cite> [<a href="#HTML401">HTML401</a>] defines the behavior of user agents with regard to <a href="http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.1">invalid documents</a> (see section B.1 [<a href="#HTML401">HTML401</a>]).</p></div>

</div>
</div>


<!-- end of section -->


<h4 id="deprecation">2.4.4 Deprecation</h4>

<p>The need for deprecation comes about when there are features (e.g., a function argument, element, attribute) defined in the specification that have become outdated and are being phased out, usually in favor of a specified replacement. It may mean for instance that the feature is still there and functional, but:</p>
<ol>
	<li>There is a better way of achieving the same thing and the Working Group prefers that this better way be used, or </li>
	<li>The feature is unused and the Working Group wants to clean up the specification and eventually remove the feature. </li>
</ol>
<p>From a user point of view, a deprecated feature is one that should not be used anymore, since it may be removed from future versions of the specification. Deprecated features are no longer recommended for use and may become obsolete and no longer defined in future versions of the specification.</p>

<div id="deprecated-feature">
<div class="principle">
<h5 id="deprecated-feature-principle"><span class="principle-label">Requirement 12:</span>
 Identify deprecated features.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> If the specified technology has already been published in a previous version of the specification, indicate the features from the previous version that are now deprecated or state in the conformance section that no features were deprecated.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>  It helps implementers as well as users to know which features may become obsolete in future versions of the technology. Identifying deprecated features gives them the opportunity to adjust their implementations to phase out the relevant features, and to provide new ways to accomplish the same task.</p>

</div>

<div class="related">
<p><span class="related-label">Related</span></p>
<ul>

	<li>Other Good Practices in this section.</li>
</ul>
</div>

<div class="technique">
<h6 id="deprecated-feature-tech">Techniques</h6>

<ol>
	<li>Create a list of all deprecated features.</li>
	<li>Create a dedicated section for it.</li>
	<li>Create an entry and link in the table of contents for this list.</li>
	<li>For each deprecated feature, create a link to the appropriate definition in the specification.</li>
</ol>

</div>


<div class="example">
<h6 id="deprecated-feature-ex">Examples</h6>
<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224/">HTML 4.01</a></cite> [<a href="#HTML401">HTML401</a>]: The specification has a full list of <a href="http://www.w3.org/TR/1999/REC-html401-19991224/index/elements.html">elements</a> and <a href="http://www.w3.org/TR/1999/REC-html401-19991224/index/attributes.html">attributes</a>. The deprecation status appears in both lists. There is an entry in the table of contents to these two lists. Each element and attribute has a link to its definition in the specification.</p>
</div>

<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/2004/REC-xml-names11-20040204/">Namespaces in XML 1.1</a></cite> [<a href="#NAMESPACES11">NAMESPACES11</a>], Section 2.2.2 <a href="http://www.w3.org/TR/xml-names11/#iri-use">Use of IRIs as Namespace Names</a> discusses the deprecation of relative IRI references, although the information is difficult to find.</p>
</div>
</div>
</div>


<div id="degree-support">
<div class="principle">
<h5 id="degree-support-principle"><span class="principle-label">Requirement 13:</span>
Define how each class of products handles each deprecated feature.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> By deprecating a feature, the Working Group indicates its desire that the feature disappear from a future version of the specification.  The motivation may be to convert an old feature to a newer one or to remove an old, dangerous, redundant or undesirable feature.  Regardless of the reason, it is important to define the effect this has on implementations that may encounter this feature (e.g., consumer products such as user agents or producer products such as authoring tools).  How will the user agents or producer products tolerate use of the deprecated feature?  Will they signal an error or a warning? Typically, use of a deprecated feature would not affect a consumer (e.g. user agent), while a producer (e.g. authoring tool) should issue a warning.</p>
</div>


<div class="care">
<p><span class="care-label">Why care?</span>  Defining how deprecated features are handled provides a smoother transition for the users of the specified technology and ensures more consistency of the behavior across implementations. It is also particularly important for implementations that need to support different versions of the specification.</p>
<p>For instance, a specification may require that an implementation
supports both the features of the new and the old specifications, or it may
suggest a conversion mechanism.</p>
</div>


<div class="technique">
<h6 id="degree-support-tech">Techniques</h6>
<ol>
	<li>Consider the effect of deprecation on all classes of products that implement the specification (e.g., authoring tools, converters, and user agents).</li>

	<li>Define how deprecation affects conformance.</li>
</ol>
</div>

<div class="example">
<h6 id="degree-support-ex">Examples</h6>
<div class="indiv-example"><p>In <cite><a href="http://www.w3.org/TR/2003/REC-MathML2-20031021/">Mathematical Markup Language (MathML) Version 2.0 (Second Edition)</a></cite> [<a href="#MATHML20">MATHML20</a>],
 <a href="http://www.w3.org/TR/MathML2/chapter7.html#interf.deprec">MathML2.0
section 7.2.1.2</a> describes deprecated MathML 1.x features in terms of
MathML-output-conformant authoring tools, MathML-input-conformant
rendering/reading tools, and MathML-roundtrip-conformant processors.</p></div>

<div class="indiv-example"><p>The conformance section of <cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224/">HTML 4.01</a></cite> [<a href="#HTML401">HTML401</a>] <a href="http://www.w3.org/TR/1999/REC-html401-19991224/conform.html#deprecated">defines deprecation</a> and what <a href="http://www.w3.org/TR/1999/REC-html401-19991224/conform.html#deprecated">user agents should do</a>. The behavior for other kinds of products is undefined.</p>

<blockquote cite="http://www.w3.org/TR/1999/REC-html401-19991224/conform.html#deprecated">
		<p>User agents should continue to support deprecated elements for reasons of backward compatibility.</p>
</blockquote>
</div>
</div>
</div>


<div id="workaround">
<div class="practice">
<h5 id="workaround-gp"><span class="practice-label">Good Practice 21:</span>
Explain how to avoid using a deprecated feature.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> Deprecating a feature implies that its  use is discouraged, often because there is a better technique available to achieve the same result. For each deprecated feature, it is necessary to explain how implementers and users can avoid using it. It might be helpful to give additional information providing insight into the motivation for the deprecation.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> Examples and information about each deprecated feature  help users  smoothly evolve toward the new version of the technology and  understand its benefits. This enables a faster adoption of the technology.</p>
<p>Explanations of deprecation help implementers understand the rationale for implementing the new technology and to implement an alternative mechanism, and can be used in tool tips or conversion scenarios to help users with the transition.</p>
</div>

<div class="technique">
<h6 id="workaround-tech">Techniques</h6>
<ol>
	<li>For each deprecated feature, give one or more examples showing the old way and the new way. </li>


</ol>
</div>

<div class="example">
<h6 id="workaround-ex">Examples</h6>
<div class="indiv-example"><p>The <cite><a href="http://www.w3.org/TR/2004/REC-xml-names11-20040204/">Namespaces XML
1.1</a></cite> [<a href="#NAMESPACES11">NAMESPACES11</a>] deprecation of IRI references includes a link to the <a href="http://www.w3.org/2000/09/xppa">deprecation ballot results</a>,
providing background information on the proposal to deprecate, what the deprecation
means with respect to conformance to XML 1.0 and namespaces as well as its
effect on other specifications (i.e., DOM, XPath).</p>
</div>

<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224/">HTML 4.01</a></cite> [<a href="#HTML401">HTML401</a>] gives numerous examples on how to avoid the markup that was used in previous versions for deprecated elements.</p></div>
</div>
</div>


<div id="obsolete">

<div class="practice">
<h5 id="obsolete-gp"><span class="practice-label">Good Practice 22:</span>
Identify obsolete features.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span> If the specified technology has been published in a previous version of the specification, indicate the features from the previous version that are now obsolete, or state  in the conformance section that no features were made obsolete.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span> Identifying obsolete features gives a clear message to users and implementers that those obsolete features are forbidden and not part of the specification anymore. This  helps to  avoid the creation of documents that mix the old and new techniques and that would be invalid.</p>
	<p>It also helps avoid name clashing. When creating an extension to a technology, implementers are likely to use a syntax token for their extended features name. Providing the name of obsolete features  helps implementers avoid using the names of previous features that are now obsolete.</p>
</div>

<div class="related">
<p><span class="related-label">Related</span></p>
<ul>
	<li>See also the section about <a href="#extensions">Extension</a>.</li>
</ul>
</div>

<div class="technique">
<h6 id="obsolete-tech">Techniques</h6>
<ol>
	<li>Create a list of all features that are obsolete.</li>
	<li>Create a dedicated section for it.</li>
	<li>Create an entry and link in the table of contents for this list.</li>
	<li>For each deprecated feature, create a link to the appropriate definition in the previous specification.</li>
</ol>
</div>

<div class="example">
<h6 id="obsolete-ex">Examples</h6>
<div class="indiv-example"><p>The <cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224/">HTML 4.01</a></cite> [<a href="#HTML401">HTML401</a>] specification has a full list of <a href="http://www.w3.org/TR/1999/REC-html401-19991224/index/elements.html">elements</a> and <a href="http://www.w3.org/TR/1999/REC-html401-19991224/index/attributes.html">attributes</a>. The obsolete status appears in both lists. There is an entry in the table of contents to these two lists. Each element and attribute has a link to its definition in the specification.</p>
</div>

<div class="indiv-example"><p><a href="http://www.w3.org/TR/html4/appendix/changes.html#h-A.3.1.3">HTML 4.01, Appendix A: Changes</a> lists obsolete elements and suggests an alternative element for use. <q cite="http://www.w3.org/TR/html4/appendix/changes.html#h-A.3.1.3">The following elements are obsolete: <code>LISTING</code>, <code>PLAINTEXT</code>, and <code>XMP</code>. For all of them, authors should use the <code>PRE</code> element instead.</q></p></div>
</div>
</div>


<h4 id="error">2.4.5 Error Handling</h4>

<div id="error-handling">
<div class="practice">
<h5 id="error-handling-gp"><span class="practice-label">Good Practice 23:</span>
Define an error handling mechanism.</h5>
</div>

<div class="meaning">
<p><span class="meaning-label">What does it mean?</span>
For each class of products  affected by an error
condition, address  error handling. For instance,
for a language, address what effect an error (be it syntactic or
semantic) in the input has on a processor of this language.
For a protocol, address how a party to this protocol should behave  when
a bogus message is received. For an <abbr title="Application Program Interface">A.P.I.</abbr>, indicate what exceptions are raised.</p>
</div>

<div class="care">
<p><span class="care-label">Why care?</span>
There are many reasons a system may fail; to make a technology reliable,
it is crucial to define how it should react to bogus input or conditions.
Defining error handling also makes it possible for a user of the
technology to react appropriately to the error condition.
</p>
</div>


<div class="technique">
<h6 id="error-handling-tech">Techniques</h6>
<p>Different methodologies exist to handle errors in a technology:</p>
<ul>
	<li>Identifying failure points and binding them with  well-known error messages allows better recovery and or reporting of these failures. This methodology is particularly useful in protocols.</li>
	<li>The technology can specify the handling of syntax errors (content that cannot be parsed) and semantic errors (meaningless content)  separately or together.</li>
        <li>One should keep in mind that extensibility may need new syntax tokens  (see <a href="#define-error-gp">Good Practice 20</a>).

        </li>
	<li>Try to limit the number of types of error defined by the specification. Also, processing errors of the same kind in the same way allows for greater interoperability.</li>
</ul>

</div>

<div class="example">
<h6 id="error-handling-ex">Examples</h6>

<div class="indiv-example"><p>The <cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224/">HTML 4.01</a></cite> [<a href="#HTML401">HTML401</a>] specification does not define an error handling policy, although it encourages a <a href="http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#notes-invalid-docs">“mustIgnore” policy</a>.</p></div>

<div class="indiv-example"><p>The <cite><a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/">Cascading Style Sheets, level 2 (CSS2) Specification</a></cite> [<a href="#CSS20">CSS20</a>] specification relies on a <a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/syndata.html#parsing-errors">well-defined “mustIgnore” policy</a>.</p></div>

<div class="indiv-example"><p><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> [<a href="#DOM-CORE-3">DOM-CORE-3</a>]  uses <a href="http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-17189187">well-defined exceptions and error values</a>.</p></div>

<div class="indiv-example"><p><cite><a href="http://www.w3.org/TR/2004/REC-xml-20040204/">XML 1.0</a></cite> [<a href="#XML10">XML10</a>] is well-known for its <a href="http://www.w3.org/TR/2004/REC-xml-20040204/#dt-fatal">strictness with error conditions</a>, where an ill-formed XML document must not be processed.</p></div>

<div class="indiv-example"><p>The <cite><a href="http://www.ietf.org/rfc/rfc2616.txt">HTTP 1.1</a></cite> [<a href="#HTTP11">HTTP11</a>] specification defines a set of well-known errors, standardized through their <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4">error codes</a>.</p></div>
<div class="indiv-example"><p>The <cite>XSLT 1.0</cite>  specification [<a href="#XSLT10">XSLT10</a>] allows a <a href="http://www.w3.org/TR/1999/REC-xslt-19991116#conformance">processor to recover from some of the defined errors</a>.</p></div>
</div>
</div>


<h2 id="beyond-conformance">3. Beyond Conformance</h2>


<p>As all editors know, the work is not finished when the writing is completed. In fact, various reviews and checks of all W3C documents are required prior to their publication and advancement. In addition to the <cite><a href="http://www.w3.org/Consortium/Process/">W3C Process Document</a></cite> [<a href="#PROCESS-DOC">PROCESS-DOC</a>] and <cite><a href="http://www.w3.org/Guide/pubrules">Publication Rules</a></cite> [<a href="#PUBRULES">PUBRULES</a>] and before Last Call reviews, other techniques improve the quality and clarity of the document. Many of these techniques can be an integrated part of the specification development. Ensuring a quality document prior to external reviews can save time and energy in that the Working Group may get fewer comments and issues to resolve.</p>


<div id="check">
<h3 id="practice-principle">3.1 Define an internal publication and review process.</h3>

<div class="story">
<h4 id="cr-story"><span class="story-label">Story:</span></h4>

<p>In 2004, QA Working Group documents entered Candidate Recommendation prior to a thorough
quality review, resulting in a huge number of issues to resolve and an
eventual retreat back to Working Draft for major revisions. Many of the
comments could have been prevented, such as inconsistency and incompleteness of the document (e.g., links to supplementary materials that did not exist or were not complete, overlapping and conflicting requirements), undefined terminology, and unimplementable requirements.</p>
</div>


<p>Define (formally or not) an internal process for reviewing and developing new parts of the specifications, and how they appear in W3C technical reports. </p>

<p>The more that the specification work is organized,  the more chances there are to move smoothly across W3C process, and to have a better final product. Setting up an internal publication/review process avoids recurrent errors in the document and allows wider participation in the editorial work, making it possible to develop the specification faster.</p>

<p>Make it fun to do quality control on the specification by providing tools and templates. For instance, at the start of work on the specification, create guidelines to help Working Group participants submit proposed text for the specification.</p>

<div class="example">
<h4 id="check-ex">Examples</h4>
<div class="indiv-example"><p><cite>QA Specification Guidelines</cite>: For the Good Practices and Requirements of <cite>QA Specification Guidelines</cite>, a <a href="http://lists.w3.org/Archives/Public/www-qa-wg/2004Jun/0023.html">template and a method</a> were developed to make the editing of each part easy for the QA Working Group to discuss and easy for the editor to incorporate in the final document.</p></div>
</div>
</div>

<div id="review">
<h3 id="review-gp">3.2 Do a systematic and thorough review.</h3>

<p>Not only should the Working Group review each part of the technology before publication, it should also review it during the editing phase. That helps the Working Group identify missing pieces, spelling mistakes, ambiguities and dependencies. When a well-defined review process is established inside the Working Group, reviews during the editing phase are easy to accomplish.</p>

<p>A Working Draft  published with incomplete or very raw sections will probably cause the Working Group to receive many comments. At best, the Working Group will spend much time answering them. At worst, the incomplete text will go unnoticed and appear in the final Recommendation. So when publishing a version with incomplete sections, make clear:</p>
<ul>
	<li>That those sections are incomplete.</li>
	<li>The group's expectations. Does the group want comments and contributions, or should reviewers ignore these sections?</li>
</ul>

<div class="related">
<p><span class="related-label">Related</span></p>
<ul>
	<li><cite><a href="http://www.w3.org/2003/Editors/">W3C Editor's Home Page</a></cite> [<a href="#EDITOR">EDITOR</a>]</li>
	<li><a href="http://www.w3.org/2001/06/manual/">Manual of Style</a> [<a href="#MANUAL-STYLE">MANUAL-STYLE</a>]</li>
</ul>
</div>
<ol>
	<li>Create a simple and light review process. For instance, establish a team, where each person focuses on a different aspect of the specification's correctness.</li>
	<li>Organize at least one review cycle before publication (more if possible).</li>
	<li>Organize the review by topic and expertise. For example, each participant can check a different part of the specification. Or organize the review process by expertise - the grammarian checks for consistency, grammar, spelling and readability; the test builder checks requirements for precision and implementability; the conformance expert checks that conformance criteria exist.</li>
</ol>
<div class="example">
<h6 id="review-ex">Examples</h6>


<div class="indiv-example"><p>Multiple editors produced the <cite>QA Specification Guidelines</cite>. A <cite><a href="http://lists.w3.org/Archives/Public/www-qa-wg/2004Jun/0023.html">template</a></cite> ([<a href="#QA-SPEC-TEMPLATE">QA-SPEC-TEMPLATE</a>], archived mail) was produced to guide the editors, ensuring that each Requirement and Good Practice was written consistently and addressed the same set of information.  Upon completion of a Requirement or Good Practice, its text was circulated to the entire Working Group for comments. At the same time, the Chair assigned review of that text to a specific Working Group participant.  This practice ensured that at least one person in the Working Group had responsibility for that text, and that it would not fall through the cracks.</p></div>
</div>

<div id="other-topics">
<h3 id="address-other-topics">3.3 Accessibility, Internationalization, and Device Independence Considerations</h3>

<p>First and foremost, W3C specifications need to frame and define
technologies that meet the requirements of the particular
deliverable, fulfill the charter of the Working Group, and advance
W3C's mission to extend the exchange of
information through the Web to everyone. Thus, accessibility, internationalization and device independence are
general requirements that must be considered in the specification of
all Web technologies. (Specification developers should consult the <a href="http://www.w3.org/TR/">technical reports index</a> for an up-to-date profile of W3C publications in all areas.)</p>

<p>The <a href="http://www.w3.org/WAI/">W3C Web Accessibility Initiative</a> (<acronym title="Web Accessibility Initiative">WAI</acronym>) pursues Web accessibility for people with disabilities through technology, guidelines, tools, education and outreach, and research and development. <cite><a href="http://www.w3.org/WAI/intro/components">Essential Components of Web Accessibility</a></cite> and the <a href="http://www.w3.org/WAI/">WAI home page</a> are helpful starting points. Some suggestions on user interface formats are in the Working
Draft <a href="http://www.w3.org/TR/xag">XML Accessibility Guidelines</a> [<a href="#XAG">XAG</a>] (work in progress).</p>

<p>Similarly, Working Groups should make sure the technologies they define are
compatible with internationalization (i.e., not specific to a
particular language or culture). The <a href="http://www.w3.org/International/">W3C internationalization (<acronym title="Internationalization">I18N</acronym>) home page</a> is a good place to start. Addressing
internationalization in a specification ensures that the
defined formats and protocols do not create barriers for languages,
writing systems, character codes, and other local conventions employed
by end users of the technology. For information on interoperable text manipulation, refer to the <a href="http://www.w3.org/TR/charmod/">Character Model for the World Wide Web</a> [<a href="#CHARMOD">CHARMOD</a>].</p>

<p>Finally, a W3C specification should support device
independence to the maximum extent possible and appropriate, to allow people of the greatest
diversity to interact with it. The benefit of
addressing device independence is the increased
likelihood that a specification and its implementations can be accessed from any device, in any
context, by anyone. A good place to start is the
<a href="http://www.w3.org/2001/di/">W3C device independence home page</a>.</p>

<p>A Working Group should designate participants to monitor the application of accessibility, internationalization and device independence to their
specifications at the earliest point possible. These participants can be the points of
contact with the relevant W3C Activities and can seek feedback on their group's
adopted solutions.</p>

</div>

</div>

<h2 id="conformance">4. Conformance to This Document</h2>

<p>The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are used as defined in RFC 2119 [<a href="#RFC2119">RFC2119</a>] in this conformance clause. Occurrences of these words in bold lowercase have normative implications. A specific markup has been added to the text.</p>

<h3 id="conformance-criteria">4.1 Conformance Criteria</h3>

<p>The conformance model of the QA Framework: Specification Guidelines is very simple. </p>

<ul>
	<li>It applies to one class of products – W3C technical reports, with a strong focus on normative specifications. Non-W3C specifications <strong class="rfc2119">may</strong> also utilize it.</li>
	<li>It is monolithic – no modules, levels or profiles are defined.</li>
	<li>It has only one conformance label, called <dfn>Specification Guidelines conformant specification</dfn>.</li>
	<li>It has <strong class="rfc2119">optional</strong> features, but the <strong class="rfc2119">optional</strong> features do not affect conformance.</li>
	<li>It allows extensions, but the extensions do not affect conformance.</li>
</ul>

<p>The conformance requirements of this document are found in the Requirements and in the Good Practices.  The Requirements are written in the imperative voice and denote mandatory conformance requirements.  They are equivalent to the familiar MUST statements in the RFC2119 style.  In addition to Requirements, this document contains Good Practices.  Good Practices use the same imperative voice, but are <strong class="rfc2119">optional</strong>.  They are equivalent to SHOULD or RECOMMENDED statements in the RFC2119 style.   Their implementation or non-implementation does not affect conformance to this Specification Guidelines document, but implementation of as many as possible is recommended, because the quality of the specification will benefit.</p>

<p>For a specification to be Specification Guidelines conformant, all Requirements <strong class="rfc2119">must</strong> be implemented.</p>

<p>One way to satisfy the Requirements and Good Practices is to implement one or more of the suggested techniques given for each Requirement and Good Practice.  Note that this is not the only way to satisfy the Requirement or Good Practice.  An implementation conformance statement (ICS)  helps track implemented Requirements and Good Practices.  It takes the <a href="specgl-ics.html">form of a checklist</a> [<a href="#QA-SPEC-ICS">QA-SPEC-ICS</a>].  If all the Requirements are checked on the ICS as being satisfied, then conformance can be <a href="#specgl-claim">claimed as detailed below</a>. </p>

<h3 id="normative-parts">4.2 Normative Parts</h3>

<p>The Conformance section, the Normative References section, the Requirements, and the Good Practices are the normative parts of this specification. All the other parts are informative.  The following list indicates the normativity of the guidelines subsections.</p>

<table class="conformance-table">
	<caption>
Normative and informative status of the different parts
	</caption>
	<tr>
		<th rowspan="1" colspan="1">Part</th>
		<th rowspan="1" colspan="1">Status</th>
	</tr>
	<tr>
		<td rowspan="1" colspan="1">Requirement</td>
		<td class="norm" rowspan="1" colspan="1">Normative<br/><strong class="rfc2119">required</strong></td>
	</tr>
	<tr style="border-bottom: 2px solid black;">
		<td rowspan="1" colspan="1">Good Practice</td>
		<td class="norm" rowspan="1" colspan="1">Normative<br/><strong class="rfc2119">optional</strong></td>
	</tr>
	<tr>
		<td rowspan="1" colspan="1">What does this mean?</td>
		<td rowspan="1" colspan="1">Informative</td>
	</tr>
	<tr>
		<td rowspan="1" colspan="1">Why Care?</td>
		<td rowspan="1" colspan="1">Informative</td>
	</tr>
	<tr>
		<td rowspan="1" colspan="1">Techniques</td>
		<td rowspan="1" colspan="1">Informative</td>
	</tr>
	<tr>
		<td rowspan="1" colspan="1">Examples</td>
		<td rowspan="1" colspan="1">Informative</td>
	</tr>
</table>


<h3 id="specgl-extensibility">4.3 Specification Guidelines Extensibility</h3>

<p>This specification is extensible.  That is, adding conformance-related information and structure to the document in ways beyond what is presented as Requirements in this specification, is allowed and encouraged.  Extensions to this specification <strong class="rfc2119">must not</strong> contradict or negate the requirements in this specification.</p>

<h3 id="specgl-claim">4.4 Conformance Claims</h3>

<p>To claim conformance to the <cite>QA Framework: Specification Guidelines</cite>, Working Groups <strong class="rfc2119">must</strong> specify:</p>

<ul>
	<li>Guidelines title and dated URI: QA Framework: Specification Guidelines, URI</li>
	<li>URI of a dated version of the specification for which conformance is being claimed,</li>
	<li>Date of the claim.</li>
        <li>URI of the <a href="specgl-ics">completed Specification Guidelines Implementation Conformance Statement</a></li>
</ul>

<p>You can claim conformance to this document by using this conformance claim  and replacing the content holders delimited by square brackets by the appropriate values:</p>

<p id="specgl-claim-wording" class="conformance-claim">On <var>[date of the publication]</var>, this specification <var>[name of the specification]</var> published at <var>[URI of the specification]</var>,  edited by <var>[name of the publishing entity]</var>, is a <strong>Specification Guidelines conformant specification</strong>, 28 April 2005, published at http://www.w3.org/TR/2005/WD-qaframe-spec-20050428/, as detailed in the Implementation Conformance Statement published at <var>[URI of the completed ICS]</var>.</p>


<h2 id="acknowledgments">5. Acknowledgments</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>Jeremy Caroll (HP)</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>Björn Höhrmann</li>
  <li>Richard T. Kennedy (Boeing)</li>
  <li>Susan Lesch (W3C)</li>
  <li>David Marston (IBM Research)</li>
  <li>Lynne Rosenthal (NIST)</li>
  <li>Mark Skall (NIST)</li>
  <li>Andrew Thackrah (Open Group)</li>
  <li>Olivier Théreaux (W3C).</li>
</ul>


<h2 id="references">6. References</h2>


<h3 id="normative">Normative References</h3>


<dl>
	<dt><a name="RFC2119" id="RFC2119">RFC2119</a></dt>
		<dd>IETF <cite><a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></cite>, S. Bradner, March 1997. Available at
http://www.ietf.org/rfc/rfc2119.txt .</dd>
</dl>

<h3 id="informative">Informative References</h3>

<dl>
<dt>
<a name="CCPP-EXCHANGE" id="CCPP-EXCHANGE">CCPP-EXCHANGE</a>
</dt>
<dd><cite><a href="http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624">CC/PP exchange protocol based on HTTP Extension Framework</a></cite>,  Hidetaka Ohto, Johan Hjelm, Editors, W3C Note, 24 June 1999, http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624  . <a href="http://www.w3.org/TR/NOTE-CCPPexchange" title="Latest version of CC/PP exchange protocol based on HTTP Extension Framework">Latest version</a> available at  http://www.w3.org/TR/NOTE-CCPPexchange .</dd>
<dt>
<a name="CCPP-VOCAB" id="CCPP-VOCAB">CCPP-VOCAB</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/">Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0</a></cite>, L. Tran, F. Reynolds, M. H. Butler, C. Woodrow, J. Hjelm, H. Ohto, G. Klyne,  Editors, W3C Recommendation, 15 January 2004, http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/ . <a href="http://www.w3.org/TR/CCPP-struct-vocab/" title="Latest version of CC/PP Structure and Vocabularies">Latest version</a> available at http://www.w3.org/TR/CCPP-struct-vocab/ .</dd>


	<dt id="CHARMOD">CHARMOD</dt>
  		<dd><cite>
<a href="http://www.w3.org/TR/2005/REC-charmod-20050215/">Character Model for the World Wide Web 1.0: Fundamentals</a></cite>, F. Yergeau, R. Ishida, M. Wolf, M. J. Dürst, T. Texin,  Editors, W3C Recommendation, 15 February 2005, http://www.w3.org/TR/2005/REC-charmod-20050215/ . <a href="http://www.w3.org/TR/charmod/" title="Latest version of Character Model for the World Wide Web Fundamentals">Latest version</a> available at http://www.w3.org/TR/charmod/ .</dd>


	<dt id="CONF-TEMPLATE">CONF-TEMPLATE</dt>
  		<dd><cite><a href="http://www.w3.org/QA/2004/08/SpecGL-template-root.html">Specification Guidelines Conformance Clause Template</a></cite>, Lofton Henderson, Lynne Rosenthal, 30 August 2004, available at http://www.w3.org/QA/2004/08/SpecGL-template-root.html .</dd>
<dt>
<a name="CSS20" id="CSS20">CSS20</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/">Cascading Style Sheets, level 2 (CSS2) Specification</a></cite>, H. Lie, I. Jacobs, C. Lilley, B. Bos,  Editors, W3C Recommendation, 12 May 1998, http://www.w3.org/TR/1998/REC-CSS2-19980512/ . <a href="http://www.w3.org/TR/REC-CSS2/" title="Latest version of CSS2">Latest version</a> available at http://www.w3.org/TR/REC-CSS2/ .</dd>

<dt>
<a name="CSS21" id="CSS21">CSS21</a>
</dt>

<dd><cite><a href="http://www.w3.org/TR/2004/CR-CSS21-20040225">Cascading Style Sheets, level 2 revision 1</a></cite>, T. Çelik, I. Hickson, H. Lie, B. Bos,  Editors, W3C Candidate Recommendation (work in progress), 25 February 2004, http://www.w3.org/TR/2004/CR-CSS21-20040225 . <a href="http://www.w3.org/TR/CSS21" title="Latest version of Cascading Style Sheets, level 2 revision 1">Latest version</a> available at http://www.w3.org/TR/CSS21 .</dd>


<dt>
<a name="CSS3-SYNTAX" id="CSS3-SYNTAX">CSS3-SYNTAX</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2003/WD-css3-syntax-20030813/">CSS3 module: Syntax</a></cite>, L. Baron,  Editor, W3C Working Draft (work in progress), 13 August 2003, http://www.w3.org/TR/2003/WD-css3-syntax-20030813/ . <a href="http://www.w3.org/TR/css3-syntax/" title="Latest version of CSS3 Syntax">Latest version</a> available at http://www.w3.org/TR/css3-syntax .</dd>

<dt>
<a name="CSS-TEST-DOC" id="CSS-TEST-DOC">CSS-TEST-DOC</a>
</dt>
<dd><cite><a href="http://www.w3.org/Style/CSS/Test/testsuitedocumentation-20030129.html">CSS Test Suite Documentation</a></cite>, Tantek Çelı̇k, Ian Hickson, 29 January 2003, http://www.w3.org/Style/CSS/Test/testsuitedocumentation-20030129.html .
<a href="http://www.w3.org/Style/CSS/Test/testsuitedocumentation.html" title="Latest version of CSS Test Suite Documentation">Latest version</a> available at http://www.w3.org/Style/CSS/Test/testsuitedocumentation.html .</dd>

<dt>
<a name="DOM-CORE-3" id="DOM-CORE-3">DOM-CORE-3</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>, P. Le Hégaret, G. Nicol, L. Wood, M. Champion, J. Robie, S. Byrne, A. Le Hors,  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 DOM Level 3">Latest version</a> available at http://www.w3.org/TR/DOM-Level-3-Core/ .</dd>

<dt><a name="EARL" id="EARL">EARL</a></dt>
<dd><cite><a href="http://www.w3.org/TR/2002/WD-EARL10-20021206/">Evaluation and Report Language (EARL) 1.0</a></cite>, W. Chisholm, S. B. Palmer,  Editors, W3C Working Draft (work in progress), 6 December 2002, http://www.w3.org/TR/2002/WD-EARL10-20021206/ . <a href="http://www.w3.org/TR/EARL10/" title="Latest version of EARL 1.0">Latest version</a> available at http://www.w3.org/TR/EARL10/ .</dd>
<dt>
<a name="EDITOR" id="EDITOR">EDITOR</a>
</dt>
<dd><cite><a href="http://www.w3.org/2003/Editors/">W3C Editors' Home Page</a></cite>, W3C Communications Team, Available at http://www.w3.org/2003/Editors/ .</dd>
<dt>
<a name="EXT-SPECGL" id="EXT-SPECGL">EXT-SPECGL</a>
</dt>
<dd>
QA WIKI <cite>
<a href="http://esw.w3.org/topic/ExtensionSpeclite">Extension Speclite</a></cite>,  Available at  http://esw.w3.org/topic/ExtensionSpeclite .</dd>
<dt>
<a name="HTML401" id="HTML401">HTML401</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224/">HTML 4.01 Specification</a></cite>, A. Le Hors, D. Raggett, I. Jacobs,  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">Latest version</a> available at http://www.w3.org/TR/html401/ .</dd>

<dt>
<a name="HTML401-TEST" id="HTML401-TEST">HTML401-TEST</a>
</dt>
<dd><cite><a href="http://www.w3.org/MarkUp/Test/HTML401/">HTML 4.01 Test Suite</a></cite>, Available at http://www.w3.org/MarkUp/Test/HTML401/ .</dd>

<dt>
<a name="HTTP-EXTENSION" id="HTTP-EXTENSION">HTTP-EXTENSION</a>
</dt>
<dd>IETF <cite><a href="http://www.ietf.org/rfc/rfc2774.txt">An HTTP Extension Framework</a></cite>,  H. Nielsen, P. Leach, S. Lawrence, February 2000. Available at   http://www.ietf.org/rfc/rfc2774.txt .</dd>


<dt><a name="HTTP11" id="HTTP11">HTTP11</a>
</dt><dd>IETF <cite><a href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616:
      Hypertext Transfer Protocol — HTTP/1.1</a></cite>, J. Gettys, J. Mogul, H.
      Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999. Available at
      http://www.ietf.org/rfc/rfc2616.txt .</dd>

<dt><a name="IETF-FORMAL" id="IETF-FORMAL">IETF-FORMAL</a></dt>
<dd><cite>Guidelines for the use of formal languages in IETF specifications</cite>, IESG Statement (work in progress), October 2001. Available at http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt .</dd>

<dt><a name="isoguide24" id="isoguide24">ISO-GUIDE</a></dt>
		<dd><cite><a href="http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39976">ISO/IEC Guide 2:2004 Standardization and related activities - General vocabulary</a></cite>. (See http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39976 for the latest version.)</dd>

<dt>
<a id="MANUAL-STYLE">MANUAL-STYLE</a>
</dt>
<dd><cite><a href="http://www.w3.org/2001/06/manual/">W3C Manual of Style</a></cite> Susan Lesch et al., Available at http://www.w3.org/2001/06/manual/ .</dd>

<dt>
<a name="MATHML20" id="MATHML20">MATHML20</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>, P. Ion, R. Miner, D. Carlisle, N. Poppelier,  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 MathML2">Latest version</a> available at http://www.w3.org/TR/MathML2/ .</dd>
<dt>
<a name="NAMESPACES11" id="NAMESPACES11">NAMESPACES11</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-xml-names11-20040204/">Namespaces in XML 1.1</a></cite>, R. Tobin, T. Bray, A. Layman, D. Hollander,  Editors, W3C Recommendation, 4 February 2004, http://www.w3.org/TR/2004/REC-xml-names11-20040204/ . <a href="http://www.w3.org/TR/xml-names11/" title="Latest version of Namespaces in XML 1.1">Latest version</a> available at http://www.w3.org/TR/xml-names11/ .</dd>


<dt>
<a name="OWL-REF" id="OWL-REF">OWL-REF</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-owl-ref-20040210/">OWL Web Ontology Language Reference</a></cite>, M. Dean, G. Schreiber,  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 Reference">Latest version</a> available at http://www.w3.org/TR/owl-ref/ .</dd>

<dt>
<a name="OWL-TEST" id="OWL-TEST">OWL-TEST</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-owl-test-20040210/">OWL Web Ontology Language Test Cases</a></cite>, J. De Roo, J. J. Carroll,  Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-test-20040210/ . <a href="http://www.w3.org/TR/owl-test/" title="Latest version of OWL Test Cases">Latest version</a> available at http://www.w3.org/TR/owl-test/ .</dd>

	<dt id="PROCESS-DOC">PROCESS-DOC</dt>
  		<dd><cite><a href="http://www.w3.org/2004/02/Process-20040205/">World Wide Web Consortium Process Document</a></cite>, Ian Jacobs, 5 February 2004, http://www.w3.org/2004/02/Process-20040205/  <a href="http://www.w3.org/Consortium/Process/" title="Latest version of W3C Process Document">Latest version</a> available at http://www.w3.org/Consortium/Process/ .</dd>

	<dt id="PUBRULES">PUBRULES</dt>
  		<dd><cite><a href="http://www.w3.org/2004/02/02-pubrules">World Wide Web Consortium Publication Rules</a></cite>, 2 February 2004, http://www.w3.org/2004/02/02-pubrules  <a href="http://www.w3.org/Guide/pubrules" title="Latest version of W3C Publication Rules">Latest version</a> available at http://www.w3.org/Guide/pubrules .</dd>


	<dt id="QA-GLOSSARY">QA-GLOSSARY</dt>
  		<dd>Comprehensive <a href="http://www.w3.org/QA/glossary">glossary of QA terminology</a>.
      (Under construction, at http://www.w3.org/QA/glossary.)</dd>

<dt><a name="QA-HANDBOOK" id="QA-HANDBOOK">QA-HANDBOOK</a></dt>
<dd>
	<cite><a href="http://www.w3.org/TR/2004/NOTE-qa-handbook-20041122/">The QA Handbook</a></cite>, L. Henderson,  Editor, W3C Working Group Note (work in progress), 22 November 2004, http://www.w3.org/TR/2004/NOTE-qa-handbook-20041122/ . <a href="http://www.w3.org/TR/qa-handbook/" title="Latest version fo QA Handbook">Latest version</a> available at http://www.w3.org/TR/qa-handbook/ .</dd>

<dt><a id="QA-SPEC-ICS">QA-SPEC-ICS</a></dt>
<dd>
	<cite><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/specgl-ics.html">QA Specification Guidelines ICS</a></cite>,  K. Dubost, L. Rosenthal, D. Haza&euml;l-Massieux, L. Henderson, 17 August 2005, http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/specgl-ics.html </dd>

<dt><a name="QA-SPEC-TEMPLATE" id="QA-SPEC-TEMPLATE">QA-SPEC-TEMPLATE</a></dt>
<dd>
	<cite><a href="http://lists.w3.org/Archives/Public/www-qa-wg/2004Jun/0023.html">QA Specification Guidelines Template</a></cite>,  Karl Dubost, 10 June 2004, http://lists.w3.org/Archives/Public/www-qa-wg/2004Jun/0023.html </dd>

<dt>
<a name="RDF-MT" id="RDF-MT">RDF-MT</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210/">RDF Semantics</a></cite>, P. Hayes,  Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . <a href="http://www.w3.org/TR/rdf-mt/" title="Latest version of RDF Semantics">Latest version</a> available at http://www.w3.org/TR/rdf-mt/ .</dd>


<dt>
<a name="RUBY" id="RUBY">RUBY</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2001/REC-ruby-20010531/">Ruby Annotation</a></cite>, T. Texin, M. Suignard, M. Ishikawa, M. Sawicki, M. J. Dürst,  Editors, W3C Recommendation, 31 May 2001, http://www.w3.org/TR/2001/REC-ruby-20010531/ . <a href="http://www.w3.org/TR/ruby/" title="Latest version of Ruby Annotation">Latest version</a> available at http://www.w3.org/TR/ruby/ .</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>, E. Hodge, P. Hoschka, K. Kubota, J. van Ossenbruggen, E. Hyche, M. Jourdan, L. Rutledge, B. Saccocio, W. ten Kate, P. Schmitz, R. Lanphier, N. Layaïda, J. Ayars, T. Michel, D. Bulterman, D. Newman, A. Cohen, K. Day,  Editors, W3C Recommendation, 7 August 2001, second edition published on 7 January 2005, http://www.w3.org/TR/2005/REC-SMIL2-20050107/ . <a href="http://www.w3.org/TR/SMIL/" title="Latest version of SMIL">Latest version</a> available at http://www.w3.org/TR/SMIL/ .</dd>

<dt>
<a name="SOAP12-TA" id="SOAP12-TA">SOAP12-TA</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/">SOAP
version 1.2 Test Assertions</a></cite>,  Available at http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/ .</dd>


<dt>
<a name="SVG-MOBILE" id="SVG-MOBILE">SVG-MOBILE</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/">Mobile SVG Profile: SVG Tiny, Version 1.2</a></cite>, O. Andersson, J. Ferraiolo, V. Hardy, D. Jackson, A. Quint,  Editors, W3C Working Draft (work in progress), 13 April 2005, http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/ . <a href="http://www.w3.org/TR/SVGMobile12/" title="Latest version of SVG Tiny 1.2">Latest version</a> available at http://www.w3.org/TR/SVGMobile12/ .</dd>
<dt>
<a name="SVG-TINY" id="SVG-TINY">SVG-TINY</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 SVG Tiny">Latest version</a> available at http://www.w3.org/TR/SVGMobile/ .</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>, 藤沢 (Fujisawa Jun), J. Ferraiolo, D. Jackson,  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 SVG 1.1">Latest version</a> available at http://www.w3.org/TR/SVG11/ .</dd>
<dt>
<a name="VIS" id="VIS">VIS</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2005/WD-spec-variability-20050629/">Variability in Specification</a></cite>,  D., L. Rosenthal, W3C Working Draft, 29 June 2005,  http://www.w3.org/TR/2005/WD-spec-variability-20050629/ . <a href="http://www.w3.org/TR/spec-variability/" title="Latest version of Variability in Specification">Latest version</a> available at http://www.w3.org/TR/spec-variability/ .</dd>
<dt>
<a name="W3C-GLOSSARY" id="W3C-GLOSSARY">W3C-GLOSSARY</a>
</dt>
<dd><cite><a href="http://www.w3.org/2003/glossary/">W3C Glossary and Dictionary</a></cite>,  http://www.w3.org/2003/glossary/  </dd>
<dt>
<a name="WCAG10" id="WCAG10">WCAG10</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/">Web Content Accessibility Guidelines 1.0</a></cite>, G. Vanderheiden, W. Chisholm, 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 WCAG 1.0">Latest version</a> available at http://www.w3.org/TR/WAI-WEBCONTENT/ .</dd>


<dt>
<a name="WEB-ARCH" id="WEB-ARCH">WEB-ARCH</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-webarch-20041215/">Architecture of the World Wide Web, Volume One</a></cite>, N. Walsh, I. Jacobs,  Editors, W3C Recommendation, 15 December 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/ . <a href="http://www.w3.org/TR/webarch/" title="Latest version of Architecture of the Web">Latest version</a> available at http://www.w3.org/TR/webarch/ .</dd>

<dt>
<a name="WEBCGM10" id="WEBCGM10">WEBCGM10</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2001/REC-WebCGM-20011217/">WebCGM 1.0 Second Release</a></cite>, R. Platon, J. Gebhardt, L. Henderson, D. Weidenbrueck, D. Cruikshank,  Editors, W3C Recommendation, 17 December 2001, http://www.w3.org/TR/2001/REC-WebCGM-20011217/ . <a href="http://www.w3.org/TR/REC-WebCGM/" title="Latest version of WebCGM 1.0">Latest version</a> available at http://www.w3.org/TR/REC-WebCGM/ .</dd>

<dt>
<a name="WIKI-FORMAL-LANGUAGE" id="WIKI-FORMAL-LANGUAGE">WIKI-FORMAL-LANGUAGE</a>
</dt>
<dd>QA WIKI <cite><a href="http://esw.w3.org/topic/FormalLanguageVsProse">Formal Language vs Prose</a></cite>,  Available at http://esw.w3.org/topic/FormalLanguageVsProse .</dd>


<dt>
<a name="WIKI-GOOD-BAD" id="WIKI-GOOD-BAD">WIKI-GOOD-BAD</a>
</dt>
<dd>QA WIKI <cite><a href="http://esw.w3.org/topic/ExtensibilityGoodOrBad">Extensibility Good Or Bad</a></cite>, Available at http://esw.w3.org/topic/ExtensibilityGoodOrBad .</dd>


<dt>

<a name="WIKI-NORMATIVE-REF" id="WIKI-NORMATIVE-REF">WIKI-NORMATIVE-REF</a>

</dt>
<dd>QA WIKI <cite><a href="http://esw.w3.org/topic/NormativeReferences">Normative References</a></cite>,  Available at esw.w3.org/topic/NormativeReferences .
</dd>


<dt>
<a name="WIKI-MEANING-BEHAVIOR" id="WIKI-MEANING-BEHAVIOR">WIKI-MEANING-BEHAVIOR</a>
</dt>
<dd>QA WIKI <cite><a href="http://esw.w3.org/topic/MeaningVsBehavior">Meaning versus Behavior</a></cite>,  Available at http://esw.w3.org/topic/MeaningVsBehavior .</dd>

<dt>
<a name="WIKI-RFC-KEYWORDS" id="WIKI-RFC-KEYWORDS">WIKI-RFC-KEYWORDS</a>
</dt>
<dd>QA WIKI <cite><a href="http://esw.w3.org/topic/RfcKeywords">RFC Keywords</a></cite>,  Available at http://esw.w3.org/topic/RfcKeywords .</dd>

<dt>
<a name="WIKI-TESTABLE-NOT" id="WIKI-TESTABLE-NOT">WIKI-TESTABLE-NOT</a>
</dt>
<dd>QA WIKI <cite><a href="http://esw.w3.org/topic/TestableOrNot">Testable Or Not</a></cite>,  Available at http://esw.w3.org/topic/TestableOrNot .</dd>


<dt>
<a name="WSDL20" id="WSDL20">WSDL20</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2004/WD-wsdl20-20040803/">Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language</a></cite>, J. C. Schlimmer, R. Chinnici, M. Gudgin, S. Weerawarana, J. Moreau,  Editors, W3C Working Draft (work in progress), 3 August 2004, http://www.w3.org/TR/2004/WD-wsdl20-20040803/ . <a href="http://www.w3.org/TR/wsdl20/" title="Latest version of WSDL 2.0">Latest version</a> available at http://www.w3.org/TR/wsdl20/ .</dd>

<dt id="XAG">XAG</dt>
  		<dd><cite><a href="http://www.w3.org/TR/2002/WD-xag-20021003">XML Accessibility Guidelines</a></cite>, C. McCathieNevile, S. B. Palmer, D. Dardailler,  Editors, W3C Working Draft (work in progress), 3 October 2002, http://www.w3.org/TR/2002/WD-xag-20021003 . <a href="http://www.w3.org/TR/xag" title="Latest version fo XML Accessibility Guidelines">Latest version</a> available at http://www.w3.org/TR/xag .</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™</a></cite>, M. Altheim, F. Boumphrey, S. McCarron, S. Schnitzenbaumer, T. Wugofski, S. Dooley,  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 XHTML Modularization">Latest version</a> available at http://www.w3.org/TR/xhtml-modularization/ .</dd>
<dt>
<a name="XHTML10" id="XHTML10">XHTML10</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2002/REC-xhtml1-20020801/">XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)</a></cite>, S. Pemberton,  Editor, W3C Recommendation, 1 August 2002, http://www.w3.org/TR/2002/REC-xhtml1-20020801/ . <a href="http://www.w3.org/TR/xhtml1/" title="Latest version of XHTML 1.0">Latest version</a> available at http://www.w3.org/TR/xhtml1/ .</dd>
<dt>
<a name="XML-SCHEMA-1" id="XML-SCHEMA-1">XML-SCHEMA-1</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema Part 1: Structures Second Edition</a></cite>, D. Beech, M. Maloney, H. S. Thompson, N. Mendelsohn,  Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ . <a href="http://www.w3.org/TR/xmlschema-1/" title="Latest version of XML Schema Part 1">Latest version</a> available at http://www.w3.org/TR/xmlschema-1/ .</dd>
<dt>
<a name="XML-SCHEMA-2" id="XML-SCHEMA-2">XML-SCHEMA-2</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">Latest version</a> available at http://www.w3.org/TR/xmlschema-2/ .</dd>


<dt>
<a name="XML-TEST" id="XML-TEST">XML-TEST</a>
</dt>
<dd><cite><a href="http://www.w3.org/XML/Test/">Extensible Markup Language (XML) Conformance Test Suites</a></cite>,  Available at http://www.w3.org/XML/Test/ .</dd>
<dt>
<a name="XML10" id="XML10">XML10</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2004/REC-xml-20040204/">Extensible Markup Language (XML) 1.0 (Third Edition)</a></cite>, E. Maler, J. Paoli, F. Yergeau, T. Bray, C. M. Sperberg-McQueen,  Editors, W3C Recommendation, 4 February 2004, http://www.w3.org/TR/2004/REC-xml-20040204/ . <a href="http://www.w3.org/TR/REC-xml/" title="Latest version of XML 1.0">Latest version</a> available at http://www.w3.org/TR/REC-xml/ .</dd>
<dt>
<a name="XMLSPEC" id="XMLSPEC">XMLSPEC</a>
</dt>
<dd><cite><a href="http://www.w3.org/2002/xmlspec/">The XML Spec Schema and Stylesheets</a></cite>,  Available at http://www.w3.org/2002/xmlspec/ .</dd>
<dt>
<a name="XPATH20" id="XPATH20">XPATH20</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2005/WD-xpath20-20050404/">XML Path Language (XPath) 2.0</a>
</cite>, A. Berglund, S. Boag, D. Chamberlin, M. F. Fernández, M. Kay, J. Robie, J. Siméon, Editors, W3C Working Draft (work in progress), 4 April 2005, http://www.w3.org/TR/2005/WD-xpath20-20050404/ . <a href="http://www.w3.org/TR/xpath20/" title="Latest version of XPath 2.0">Latest version</a> available at http://www.w3.org/TR/xpath20/ .</dd>
<dt>
<a name="XQUERY-SEMANTICS" id="XQUERY-SEMANTICS">XQUERY-SEMANTICS</a>
</dt>
<dd><cite><a href="http://www.w3.org/TR/2005/WD-xquery-semantics-20050404/">XQuery 1.0 and XPath 2.0 Formal Semantics</a></cite>, M. F. Fernández, K. Rose, D. Draper, M. Rys, J. Siméon, P. Wadler, P. Fankhauser, A. Malhotra,  Editors, W3C Working Draft (work in progress), 4 April 2005, http://www.w3.org/TR/2005/WD-xquery-semantics-20050404/ . <a href="http://www.w3.org/TR/xquery-semantics/" title="Latest version of XQuery and XPath Formal Semantics">Latest version</a> available at http://www.w3.org/TR/xquery-semantics/ .</dd>
<dt>
<a name="XSLT10" id="XSLT10">XSLT10</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 XSLT 1.0">Latest version</a> available at http://www.w3.org/TR/xslt .</dd>
</dl>

<div>
<h3 id="further_reading">Further Reading</h3>

<p>The following references have been inspirational to the ideas captured in this document.</p>

<ul>
<li><cite><a href="http://portal.etsi.org/mbs/">Making Better Standards</a></cite>, ETSI Protocol and Testing Competence Centre, http://portal.etsi.org/mbs/ .</li>
<li><cite><a href="http://www.w3.org/People/Bos/DesignGuide/introduction">What is a good standard?</a></cite>, B. Bos, 6 March 2003, http://www.w3.org/People/Bos/DesignGuide/introduction .</li>
<li><cite><a href="http://www.w3.org/1999/09/specification">The essentials of a specification</a></cite>, T. Berners-Lee, 24 May 1999, http://www.w3.org/1999/09/specification .</li>
<li>IETF <cite><a href="http://www.ietf.org/rfc/rfc2360.txt">RFC 2360: Guide for Internet Standards Writers</a></cite>, G. Scott, Editor, June 1998, http://www.ietf.org/rfc/rfc2360.txt .</li>
</ul>
</div>


<h2 id="glossary">7. Glossary</h2>
<dl class="glossary">

  <dt id="cop-def">class of products</dt>
    <dd>The generic name for the group of products or services that would
      implement, for the same purpose, the specification, (i.e., target of
      the specification). A specification may identify several classes of
      products.</dd>

  <dt id="conformance-def">conformance</dt>
    <dd>Fulfillment by a product, process, systems, or service of a specified
      set of requirements.</dd>

  <dt id="conformance-clause-def">conformance clause</dt>
    <dd>A section of the specification that defines the requirements,
      criteria, or conditions to be satisfied by an implementation in order to
      claim conformance.</dd>

   <dt id="deprecated-def">deprecated feature</dt>
   <dd>	An existing feature that has become outdated
	and is in the process of being phased out,
	usually in favor of a specified replacement.
	Deprecated features are no longer recommended
	for use and may cease to exist in future
	versions of the specification.
</dd>

  <dt id="dov-def">dimensions of variability (DoV)</dt>
    <dd>The ways in which different products that are conformant to a
      specification may vary among themselves.</dd>

  <dt id="discretionary-items-def">discretionary item</dt>
    <dd>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.</dd>

  <dt id="extensible-def">extensible</dt>
    <dd>The ability of a specification to accept extensions in a defined way.
      A specification is extensible if it provides a mechanism for any party
      to create extensions.</dd>

  <dt id="extension-def">extension</dt>
    <dd>The ability to incorporate additional functionality beyond what is
      defined in the specification. It broadens the possibility of the
      technology.</dd>


<dt id="implementation-def">implementation</dt>
    <dd>An implementation is a realization of a technology in accordance to the principles defined in the technical specifications for this technology. This implementation can be a document, product, application, process, service, system, or other entity.</dd>

<dt id="ics-def">implementation conformance statement  (ICS)</dt>
<dd>A questionnaire or checklist for providing information about an implementation to a specification, by presenting in a uniform manner the implemented capabilities (e.g., functions, features) and options as well as limitations of the implementation. </dd>

	<dt id="informative-def">informative</dt>
	<dd>Text in a specification whose purpose is informational or assistive  in the understanding or use of the specification, and which contains no  conformance requirements or test assertions.</dd>


   <dt id="level-def">level</dt>
   <dd>A technology subset that is one of a hierarchy of nested subsets, ranging from minimal or core functionality to full or complete functionally.</dd>

   <dt id="module-def">module</dt>
   <dd>A collection of semantically related features that represents a unit of functionality.</dd>

	<dt id="normative-def">normative</dt>
	<dd>Text in a specification which is prescriptive or contains conformance  requirements.</dd>

   <dt id="obsolete-def">obsolete feature</dt>
   <dd>An existing or deprecated feature that has ceased to
	exist and that is listed for historical purpose.</dd>

   <dt id="profile-def">profile</dt>
   <dd>A subset of a technology that is tailored to meet specific functional requirements of a particular application community.</dd>

  <dt id="specification">specification</dt>
  <dd>Document that prescribes requirements to be fulfilled by a product, process, or service.</dd>

  <dt id="strict-conformance-def">strict conformance</dt>
    <dd>Conformance of an implementation that employs only the requirements
      and/or functionality defined in the specification and no more (i.e., no
      extensions to the specification are implemented).</dd>

  <dt id="test-assertion-def">test assertion</dt>
    <dd>A measurable or testable statement of behavior, action, or condition. It is derived from the specification's requirements.</dd>


  <dt id="testability-def">testability</dt>
    <dd>A proposition is testable if there is such a procedure that assesses the truth-value of a proposition with a high confidence level.</dd>

</dl>


</body>
</html>