--- a/ttml10/spec/ttaf1-dfxp.html Thu Jun 20 12:35:40 2013 +0800
+++ b/ttml10/spec/ttaf1-dfxp.html Thu Jun 20 12:37:14 2013 +0800
@@ -80,9 +80,9 @@
.strong { font-weight: bold }
.reqattr { font-weight: bold }
.optattr { font-style: italic }
-</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-ED.css"></head><body>Last Modified: $Date: 2013/06/19 09:20:25 $<div id="revisions"></div><div class="head">
+</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-ED.css"></head><body>Last Modified: $Date: 2013/06/20 04:35:40 $<div id="revisions"></div><div class="head">
<h1><a id="title"></a>Timed Text Markup Language (TTML) 1.0 (Second Edition)</h1>
-<h2><a id="w3c-doctype"></a>Editors' copy $Date: 2013/06/19 09:20:25 $ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
+<h2><a id="w3c-doctype"></a>Editors' copy $Date: 2013/06/20 04:35:40 $ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
<a href="ttaf1-dfxp.html">ttaf1-dfxp.html</a>
</dd><dt>Latest version:</dt><dd><a href="http://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10/spec/ttaf1-dfxp.html?content-type=text/html;charset=utf-8">http://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10/spec/ttaf1-dfxp.html?content-type=text/html;charset=utf-8</a></dd><dt>Previous version:</dt><dd>
<a href="http://www.w3.org/TR/2010/REC-ttaf1-dfxp-20101118/">http://www.w3.org/TR/2010/REC-ttaf1-dfxp-20101118/</a>
@@ -392,11 +392,11 @@
H <a href="#other-references">Other References</a> (Non-Normative)<br>
I <a href="#requirements">Requirements</a> (Non-Normative)<br>
J <a href="#derivation">Vocabulary Derivation</a> (Non-Normative)<br>
- J.1 <a href="#d3e18544">Element Derivation</a><br>
- J.2 <a href="#d3e19023">Attribute Derivation</a><br>
+ J.1 <a href="#d3e18552">Element Derivation</a><br>
+ J.2 <a href="#d3e19031">Attribute Derivation</a><br>
K <a href="#qa">QA Framework Compliance</a> (Non-Normative)<br>
- K.1 <a href="#d3e19909">Requirements</a><br>
- K.2 <a href="#d3e20073">Guidelines</a><br>
+ K.1 <a href="#d3e19917">Requirements</a><br>
+ K.2 <a href="#d3e20081">Guidelines</a><br>
L <a href="#streaming">Streaming TTML Content</a> (Non-Normative)<br>
M <a href="#concrete-encoding">Concrete Encoding</a> (Non-Normative)<br>
N <a href="#time-expression-semantics">Time Expression Semantics</a> (Non-Normative)<br>
@@ -2474,9 +2474,11 @@
units of the <a href="#style-value-length"><length></a> values must be the same.</p><p>The <a href="#style-value-length"><length></a> value(s) used to express font size must be non-negative.</p><p>For the purpose of determining applicability of this style property,
each character child of a <code>p</code> element is considered to be enclosed in an anonymous
span.</p><p>If a specified value of this attribute is not supported,
-then a presentation processor must interpret the attribute as if the
-value <code>1c</code> were specified.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>The expression <code>1c</code> means one cell, where <code>'c'</code> expresses
-the <em>cell</em> length unit as defined by <a href="#style-value-length"><b>8.3.9 <length></b></a>.</p></div><div class="note"><p class="prefix"><b>Note:</b></p><p>As specified above, the use of percentage units to express font size are interpreted as
+then a presentation processor must interpret the attribute as if the closest supported value were
+specified.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>The expression <code>1c</code> means one cell, where <code>'c'</code> expresses
+the <em>cell</em> length unit as defined by <a href="#style-value-length"><b>8.3.9 <length></b></a>.
+When a single <length> is expressed using cell units, then it refers to the height of
+the <em>Computed Cell Size</em>.</p></div><div class="note"><p class="prefix"><b>Note:</b></p><p>As specified above, the use of percentage units to express font size are interpreted as
relative to <em>Computed Cell Size</em> when there is no parent element. For example, if cell resolution
is 32 by 15, and the extent of the <em>Root Container Region</em> is 640 by 480, then the
<em>Computed Cell Size</em> is [20px, 32px], i.e., 640px/32 (width) and 480px/15 (height). Consequently, if
@@ -2627,7 +2629,10 @@
</pre></div>
</td></tr></tbody></table><p></p><a id="style-attribute-lineHeight-example-1-images"></a><table class="example-images"><caption>Example Rendition – Line Height</caption><tbody><tr><td><img src="images/lineHeight.png" alt="TTML lineHeight style property"></td></tr></tbody></table><p></p><div class="note"><p class="prefix"><b>Note:</b></p><p>The semantics of the style property
represented by this attribute are based upon that defined by <a href="#xsl11">[XSL 1.1]</a>,
-§ 7.16.4.</p></div></div><div class="div3">
+§ 7.16.4. Furthermore, it is the intention of this specification that the
+allocation rectangle of a line be consistent with the <span class="strong">per-inline-height-rectangle</span>
+as defined by <a href="#xsl11">[XSL 1.1]</a>, § 4.5, i.e., that a CSS-style line box stacking strategy be used.
+</p></div></div><div class="div3">
<h4><a id="style-attribute-opacity"></a>8.2.13 tts:opacity</h4><p>The <code>tts:opacity</code> attribute is used to specify a style property that
defines the opacity (or conversely, the transparency)
of marks associated with a region.</p><p>When presented onto a visual medium, the opacity of the region is applied uniformly and on a linear scale
@@ -4041,9 +4046,9 @@
child <code>fo:flow</code> element that reference the page master and page region
defined by the simple page master produced above;</p></li><li><p>map each non-empty <code>region</code> element to an <code>fo:block-container</code>
element with an <code>absolute-position</code> attribute with value
-<code>absolute</code>, and where the region's position and extent are mapped to equivalent
-<code>top</code>, <code>left</code>, <code>width</code>, and <code>height</code>
-attributes;</p></li><li><p>for each <code>body</code>, <code>div</code>, and <code>p</code> element that is not
+<code>absolute</code>, with <code>top</code>, <code>left</code>, <code>bottom</code>, and <code>right</code>
+attributes that express a rectangle equivalent to the region's origin and
+extent, and with a <code>line-stacking-strategy</code> attribute with value <code>line-height</code>;</p></li><li><p>for each <code>body</code>, <code>div</code>, and <code>p</code> element that is not
associated with a <code>tts:display</code> style property with the value
<code>none</code>, map the element to a distinct <code>fo:block</code> element,
populating the style properties of <code>fo:block</code> by using the computed
@@ -4610,13 +4615,12 @@
used in a <em>Document Instances</em>:
</p><ul><li><p><a href="#metadata-vocabulary-title"><b>12.1.2 ttm:title</b></a></p></li><li><p><a href="#metadata-vocabulary-desc"><b>12.1.3 ttm:desc</b></a></p></li><li><p><a href="#metadata-vocabulary-copyright"><b>12.1.4 ttm:copyright</b></a></p></li><li><p><a href="#metadata-vocabulary-agent"><b>12.1.5 ttm:agent</b></a></p></li><li><p><a href="#metadata-vocabulary-name"><b>12.1.6 ttm:name</b></a></p></li><li><p><a href="#metadata-vocabulary-actor"><b>12.1.7 ttm:actor</b></a></p></li></ul><div class="div3">
<h4><a id="metadata-vocabulary-metadata"></a>12.1.1 metadata</h4><p>The <code>metadata</code> element functions as a generic container for metadata
-information.</p><p>A <code>metadata</code> element must not express <em>metadata information</em>
-by both (1) specifying this information in the form of one or more attributes and (2)
-specifying this information in the form of one or more child elements. Both types
-of <em>metadata information</em> are referred to in this document as metadata
-items.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>In other words, a given <code>metadata</code> element may specify metadata information
-either (1) as attributes, or (2) as child elements, but it may not specify both forms
-of metadata information together.</p></div><a id="elt-syntax-metadata"></a><table class="syntax"><caption>XML Representation – Element Information Item: metadata</caption><tbody><tr><td>
+information.</p><p>Metadata information may be expressed with a <code>metadata</code> element by specifying
+(1) one or more metadata attributes on the <code>metadata</code> element,
+(2) one or more metadata child elements in the <code>metadata</code> element, or
+(3) a combination of metadata attributes and metadata child elements. Both types
+of metadata information are referred to in this document as <em>metadata
+items</em>.</p><a id="elt-syntax-metadata"></a><table class="syntax"><caption>XML Representation – Element Information Item: metadata</caption><tbody><tr><td>
<div class="exampleInner"><pre>
<metadata
<a href="#content-attribute-id">xml:id</a> = ID
@@ -4628,8 +4632,8 @@
</metadata>
</pre></div>
</td></tr></tbody></table><div class="note"><p class="prefix"><b>Note:</b></p><p>The meaning of a specific metadata item must be evaluated in the
-context of where it appears. The core vocabulary catalog permits an
-arbitrary number of <code>metadata</code> element children of any
+context where it appears. The core vocabulary catalog permits an
+arbitrary number of <code>metadata</code> element children on any
content element type except for the <code>tt</code> element. See specific element
vocabulary definitions for any constraints that apply to such
usage.</p></div><p>The use of document metadata is illustrated by the following example.</p><a id="metadata-vocabulary-metadata-example-1"></a><table class="example"><caption>Example Fragment – Document Metadata</caption><tbody><tr><td>
@@ -6469,7 +6473,7 @@
<h2><a id="derivation"></a>J Vocabulary Derivation (Non-Normative)</h2><p>This appendix provides information about the derivation of TTML
vocabulary, separately describing derivation of elements and
attributes.</p><div class="div2">
-<h3><a id="d3e18544"></a>J.1 Element Derivation</h3><p>The first column of <a href="#element-vocab-derivation-table"><b>Table J-1 – Elements</b></a>
+<h3><a id="d3e18552"></a>J.1 Element Derivation</h3><p>The first column of <a href="#element-vocab-derivation-table"><b>Table J-1 – Elements</b></a>
specifies a TTML element vocabulary item; the second column specifies the
syntactic and/or semantic model on which the vocabulary item is based;
the third column specifies the reference that defines
@@ -6524,7 +6528,7 @@
and <code>@requiredFeatures</code> on the <code>svg:svg</code> element,
but extended to support distinct specification of optionality.</p></li><li><p>Derived from the use of <code>@baseProfile</code>
and <code>@version</code> on the <code>svg:svg</code> element.</p></li></ol></div></div><div class="div2">
-<h3><a id="d3e19023"></a>J.2 Attribute Derivation</h3><p>The first column of <a href="#attribute-vocab-derivation-table"><b>Table J-2 – Attributes</b></a>
+<h3><a id="d3e19031"></a>J.2 Attribute Derivation</h3><p>The first column of <a href="#attribute-vocab-derivation-table"><b>Table J-2 – Attributes</b></a>
specifies a TTML attribute vocabulary item; the second column specifies the
syntactic and/or semantic model on which the vocabulary item is based;
the third column specifies the reference that defines
@@ -6596,9 +6600,9 @@
<h2><a id="qa"></a>K QA Framework Compliance (Non-Normative)</h2><p>This appendix specifies the compliance of this specification with the
requirements and guidelines defined by <a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/">QA
Framework Specifications Guidelines</a> <a href="#qaf-sg">[QAF SG]</a>.</p><div class="div2">
-<h3><a id="d3e19909"></a>K.1 Requirements</h3><a id="qa-framework-requirements-table"></a><table class="common"><caption>Table K-1 – QA Framework Requirements Checklist</caption><col width="76%" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><tbody><tr><td><span class="strong">Requirement</span></td><td><span class="strong">YES</span></td><td><span class="strong">NO</span></td><td><span class="strong">N/A</span></td><td><span class="strong">Notes</span></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#include-conformance-clause-principle">Requirement 01: Include a conformance
+<h3><a id="d3e19917"></a>K.1 Requirements</h3><a id="qa-framework-requirements-table"></a><table class="common"><caption>Table K-1 – QA Framework Requirements Checklist</caption><col width="76%" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><tbody><tr><td><span class="strong">Requirement</span></td><td><span class="strong">YES</span></td><td><span class="strong">NO</span></td><td><span class="strong">N/A</span></td><td><span class="strong">Notes</span></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#include-conformance-clause-principle">Requirement 01: Include a conformance
clause</a></td><td><a href="#conformance">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#define-scope-principle">Requirement 02: Define the scope.</a></td><td><a href="#intro">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#implement-principle">Requirement 03: Identify who or what will implement the specification.</a></td><td><a href="#conformance">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ref-norm-principle">Requirement 04: Make a list of normative references.</a></td><td><a href="#references">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#define-terms-principle">Requirement 05: Define the terms used in the normative parts of the specification.</a></td><td><a href="#definitions">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#conf-label-principle">Requirement 06: Create conformance labels for each part of the conformance model.</a></td><td><a href="#conformance">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#consistent-style-principle">Requirement 07: Use a consistent style for conformance requirements and explain how to distinguish them.</a></td><td><a href="#conventions">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#req-opt-conf-principle">Requirement 08: Indicate which conformance requirements are mandatory, which are recommended, and which are optional.</a></td><td><a href="#conventions">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#subdivide-mandatory-principle">Requirement 09: If the technology is subdivided, then indicate which subdivisions are mandatory for conformance.</a></td><td><a href="#conformance">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#subdiv-constraints-principle">Requirement 10: If the technology is subdivided, then address subdivision constraints.</a></td><td><a href="#conformance">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#likehood-extension-principle">Requirement 11: Address Extensibility.</a></td><td><a href="#doctypes">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#deprecated-feature-principle">Requirement 12: Identify deprecated features.</a></td><td></td><td></td><td>N/A</td><td>1</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#degree-support-principle">Requirement 13: Define how each class of product handles each deprecated feature.</a></td><td></td><td></td><td>N/A</td><td>1</td></tr></tbody></table><div class="note"><p class="prefix"><b>Note:</b></p><ol class="enumar"><li><p>No feature is deprecated by this version of this specification.</p></li></ol></div></div><div class="div2">
-<h3><a id="d3e20073"></a>K.2 Guidelines</h3><a id="qa-framework-guidelines-table"></a><table class="common"><caption>Table K-2 – QA Framework Guidelines Checklist</caption><col width="76%" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><tbody><tr><td><span class="strong">Guideline</span></td><td><span class="strong">YES</span></td><td><span class="strong">NO</span></td><td><span class="strong">N/A</span></td><td><span class="strong">Notes</span></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#conformance-model-gp">Good Practice 01: Define the specification's conformance model in the conformance clause.</a></td><td><a href="#conformance">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#norm-informative-gp">Good Practice 02: Specify in the conformance clause how to distinguish normative from informative content.</a></td><td><a href="#conventions">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#conformance-claim-gp">Good Practice 03: Provide the wording for conformance claims.</a></td><td><a href="#claims">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ics-gp">Good Practice 04: Provide an Implementation Conformance Statement Pro Forma.</a></td><td></td><td>NO</td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ics-claim-gp">Good Practice 05: Require an Implementation Conformance Statement as part of valid conformance claims.</a></td><td><a href="#claims">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#use-example-gp">Good Practice 06: Provide examples, use cases, and graphics.</a></td><td><a href="#example">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#write-sample-gp">Good Practice 07: Write sample code or tests.</a></td><td>YES</td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ref-define-practice">Good Practice 08: When imposing requirements by normative references, address conformance dependencies.</a></td><td><a href="#references">YES</a></td><td></td><td></td><td>1</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#define-terms-inline-gp">Good Practice 09: Define unfamiliar terms in-line and consolidate the definitions in a glossary section.</a></td><td><a href="#definitions">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#reuse-terms-gp">Good Practice 10: Use terms already defined without changing their definition.</a></td><td><a href="#definitions">YES</a></td><td></td><td></td><td>2</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#formal-language-gp">Good Practice 11: Use formal languages when possible.</a></td><td><a href="#schemas">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#write-assertion-gp">Good Practice 12: Write Test Assertions.</a></td><td></td><td>NO</td><td></td><td>3</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#subdivide-foster-gp">Good Practice 13: Create subdivisions of the technology when warranted.</a></td><td><a href="#conformance">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#rules-profiles-gp">Good Practice 14: If the technology is profiled, define rules for creating new profiles.</a></td><td><a href="#vocabulary-profiles">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#need-option-gp">Good Practice 15:Use optional features as warranted.</a></td><td>YES</td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#label-options-gp">Good Practice 16: Clearly identify optional features.</a></td><td>YES</td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#constraints-gp">Good Practice 17: Indicate any limitations or constraints on optional features.</a></td><td>YES</td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#extensions-prohibited-gp">Good Practice 18: If extensibility is allowed, define an extension mechanism.</a></td><td><a href="#extension-vocabulary-overview">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#breaking-conformance-gp">Good Practice 19: Warn extension creators to create extensions that do not interfere with conformance.</a></td><td><a href="#extension-vocabulary-overview">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#define-error-gp">Good Practice 20: Define error-handling for unknown extensions.</a></td><td><a href="#conformance-processor">YES</a></td><td></td><td></td><td>4</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#workaround-gp">Good Practice 21: Explain how to avoid using a deprecated feature.</a></td><td></td><td></td><td>N/A</td><td>5</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#obsolete-gp">Good Practice 22: Identify obsolete features.</a></td><td></td><td></td><td>N/A</td><td>5</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#error-handling-gp">Good Practice 23: Define an error handling mechanism.</a></td><td><a href="#reduced-infoset">YES</a></td><td></td><td></td><td></td></tr></tbody></table><div class="note"><p class="prefix"><b>Note:</b></p><ol class="enumar"><li><p>When making normative references to external specifications,
+<h3><a id="d3e20081"></a>K.2 Guidelines</h3><a id="qa-framework-guidelines-table"></a><table class="common"><caption>Table K-2 – QA Framework Guidelines Checklist</caption><col width="76%" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><col width="6%" align="center" span="1"><tbody><tr><td><span class="strong">Guideline</span></td><td><span class="strong">YES</span></td><td><span class="strong">NO</span></td><td><span class="strong">N/A</span></td><td><span class="strong">Notes</span></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#conformance-model-gp">Good Practice 01: Define the specification's conformance model in the conformance clause.</a></td><td><a href="#conformance">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#norm-informative-gp">Good Practice 02: Specify in the conformance clause how to distinguish normative from informative content.</a></td><td><a href="#conventions">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#conformance-claim-gp">Good Practice 03: Provide the wording for conformance claims.</a></td><td><a href="#claims">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ics-gp">Good Practice 04: Provide an Implementation Conformance Statement Pro Forma.</a></td><td></td><td>NO</td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ics-claim-gp">Good Practice 05: Require an Implementation Conformance Statement as part of valid conformance claims.</a></td><td><a href="#claims">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#use-example-gp">Good Practice 06: Provide examples, use cases, and graphics.</a></td><td><a href="#example">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#write-sample-gp">Good Practice 07: Write sample code or tests.</a></td><td>YES</td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#ref-define-practice">Good Practice 08: When imposing requirements by normative references, address conformance dependencies.</a></td><td><a href="#references">YES</a></td><td></td><td></td><td>1</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#define-terms-inline-gp">Good Practice 09: Define unfamiliar terms in-line and consolidate the definitions in a glossary section.</a></td><td><a href="#definitions">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#reuse-terms-gp">Good Practice 10: Use terms already defined without changing their definition.</a></td><td><a href="#definitions">YES</a></td><td></td><td></td><td>2</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#formal-language-gp">Good Practice 11: Use formal languages when possible.</a></td><td><a href="#schemas">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#write-assertion-gp">Good Practice 12: Write Test Assertions.</a></td><td></td><td>NO</td><td></td><td>3</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#subdivide-foster-gp">Good Practice 13: Create subdivisions of the technology when warranted.</a></td><td><a href="#conformance">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#rules-profiles-gp">Good Practice 14: If the technology is profiled, define rules for creating new profiles.</a></td><td><a href="#vocabulary-profiles">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#need-option-gp">Good Practice 15:Use optional features as warranted.</a></td><td>YES</td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#label-options-gp">Good Practice 16: Clearly identify optional features.</a></td><td>YES</td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#constraints-gp">Good Practice 17: Indicate any limitations or constraints on optional features.</a></td><td>YES</td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#extensions-prohibited-gp">Good Practice 18: If extensibility is allowed, define an extension mechanism.</a></td><td><a href="#extension-vocabulary-overview">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#breaking-conformance-gp">Good Practice 19: Warn extension creators to create extensions that do not interfere with conformance.</a></td><td><a href="#extension-vocabulary-overview">YES</a></td><td></td><td></td><td></td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#define-error-gp">Good Practice 20: Define error-handling for unknown extensions.</a></td><td><a href="#conformance-processor">YES</a></td><td></td><td></td><td>4</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#workaround-gp">Good Practice 21: Explain how to avoid using a deprecated feature.</a></td><td></td><td></td><td>N/A</td><td>5</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#obsolete-gp">Good Practice 22: Identify obsolete features.</a></td><td></td><td></td><td>N/A</td><td>5</td></tr><tr><td><a href="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#error-handling-gp">Good Practice 23: Define an error handling mechanism.</a></td><td><a href="#reduced-infoset">YES</a></td><td></td><td></td><td></td></tr></tbody></table><div class="note"><p class="prefix"><b>Note:</b></p><ol class="enumar"><li><p>When making normative references to external specifications,
specific clauses or sections are cited.</p></li><li><p>See also <a href="#derivation"><b>J Vocabulary Derivation</b></a>.</p></li><li><p>Test assertions and test suites will be provided prior to entering
Proposed Recommendation (PR) phase.</p></li><li><p>See criterion #3 in <a href="#conformance-processor"><b>3.2 Processor Conformance</b></a> and definition of
TTML <a href="#doctypes">Abstract Document Instance</a>.</p></li><li><p>No feature is deprecated or obsoleted by this version of this specification.</p></li></ol></div></div></div><div class="div1">