--- a/ttml2/spec/ttml2.html Thu Sep 05 17:02:48 2013 -0600
+++ b/ttml2/spec/ttml2.html Thu Sep 05 17:03:04 2013 -0600
@@ -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/09/05 05:56:27 $<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/09/05 23:02:48 $<div id="revisions"></div><div class="head">
<h1><a id="title"></a>Timed Text Markup Language 2 (TTML2)</h1>
-<h2><a id="w3c-doctype"></a>Editors' copy $Date: 2013/09/05 05:56:27 $ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
+<h2><a id="w3c-doctype"></a>Editors' copy $Date: 2013/09/05 23:02:48 $ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
<a href="ttml2.html">ttml2.html</a>
</dd><dt>Latest version:</dt><dd><a href="http://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html?content-type=text/html;charset=utf-8">http://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.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>
@@ -417,11 +417,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="#d3e21644">Element Derivation</a><br>
- J.2 <a href="#d3e22161">Attribute Derivation</a><br>
+ J.1 <a href="#d3e21750">Element Derivation</a><br>
+ J.2 <a href="#d3e22267">Attribute Derivation</a><br>
K <a href="#qa">QA Framework Compliance</a> (Non-Normative)<br>
- K.1 <a href="#d3e23154">Requirements</a><br>
- K.2 <a href="#d3e23318">Guidelines</a><br>
+ K.1 <a href="#d3e23260">Requirements</a><br>
+ K.2 <a href="#d3e23424">Guidelines</a><br>
L <a href="#streaming">Streaming TTML Content</a> (Non-Normative)<br>
M <a href="#concrete-encoding">Concrete Encoding</a><br>
N <a href="#time-expression-semantics">Time Expression Semantics</a><br>
@@ -1241,13 +1241,35 @@
<div class="exampleInner"><pre>
<ttp:profile
combine = (replace|union|intersection) : replace
+ designator = string
use = string
<a href="#content-attribute-id">xml:id</a> = ID
{<em>any attribute not in default or any TT namespace</em>}>
<em>Content:</em> <a href="#element-vocab-group-table">Metadata.class</a>*, <a href="#parameter-vocabulary-features">ttp:features</a>*, <a href="#parameter-vocabulary-extensions">ttp:extensions</a>*
</ttp:profile>
</pre></div>
-</td></tr></tbody></table><p>If specified, the <code>use</code> attribute must adhere to the
+</td></tr></tbody></table><p>The <code>combine</code> attribute may be used to specify how
+feature or extension specifications are combined in the case that
+multiple specifications apply to the same feature or extension, respectively.
+If the value of the <code>combine</code> attribute is <code>replace</code>, then a
+feature or extension specification contained in the <code>ttp:profile</code> element
+replaces the specification defined by the baseline profile or a lexically subsequent
+specification replaces a lexically prior specification in the case that both
+specifications appear in the same <code>ttp:profile</code> element; if the value is
+<code>union</code>, then the semantic union applies; if the value is <code>intersection</code>,
+then the semantic intersection applies. If the <code>combine</code> attribute is not
+specified, then replacement semantics apply.</p><table border="1" class="ednote" summary="Editorial note: Combine Semantics"><tr class="ednote-r1"><td align="left" valign="top"><b>Editorial note: Combine Semantics</b></td><td align="right" valign="top">2013-07-10</td></tr><tr class="ednote-r2"><td colspan="2" align="left" valign="top">Need to elaborate semantics of union and intersection combination methods.</td></tr></table><p>If specified, the <code>designator</code> attribute must (1) adhere to the
+<code>xsd:anyURI</code> data type defined by <a href="#xsd-2">[XML Schema Part 2]</a>,
+§3.2.17 and (2) express an absolute URI that denotes a profile designator in
+accordance with <a href="#vocabulary-profiles"><b>5.2 Profiles</b></a>.</p><p>A <code>designator</code> attribute may
+be specified on a <code>ttp:profile</code> element that appears in a TTML
+<a href="#terms-document-instance">document instance</a>, and, if not specified,
+the defined profile is considered to be an anonymous (undesignated) profile.
+A <code>designator</code> attribute should
+be specified on a <code>ttp:profile</code> element that appears in a TTML
+<a href="#terms-profile-definition-document">profile definition document</a> instance,
+and, if not specified, the defining context (e.g., an external specification) must specify
+a designator in its accompanying definition text.</p><p>If specified, the <code>use</code> attribute must adhere to the
<code>xsd:anyURI</code> data type defined by <a href="#xsd-2">[XML Schema Part 2]</a>,
§3.2.17, and, furthermore, must denote a profile designator in
accordance with <a href="#vocabulary-profiles"><b>5.2 Profiles</b></a>. In this case,
@@ -1258,17 +1280,7 @@
baseline profile of the specifying <code>ttp:profile</code> element.</p><p>If the <code>use</code> attribute is not specified, then the baseline
profile of the <code>ttp:profile</code> element must be considered to be
the empty (null) profile, i.e., a profile definition containing no
-feature or extension specifications.</p><p>The <code>combine</code> attribute may be used to specify how
-feature or extension specifications are combined in the case that
-multiple specifications apply to the same feature or extension, respectively.
-If the value of the <code>combine</code> attribute is <code>replace</code>, then a
-feature or extension specification contained in the <code>ttp:profile</code> element
-replaces the specification defined by the baseline profile or a lexically subsequent
-specification replaces a lexically prior specification in the case that both
-specifications appear in the same <code>ttp:profile</code> element; if the value is
-<code>union</code>, then the semantic union applies; if the value is <code>intersection</code>,
-then the semantic intersection applies. If the <code>combine</code> attribute is not
-specified, then replacement semantics apply.</p><table border="1" class="ednote" summary="Editorial note: Combine Semantics"><tr class="ednote-r1"><td align="left" valign="top"><b>Editorial note: Combine Semantics</b></td><td align="right" valign="top">2013-07-10</td></tr><tr class="ednote-r2"><td colspan="2" align="left" valign="top">Need to elaborate semantics of union and intersection combination methods.</td></tr></table><p>The collection of features and extensions of a profile are determined according
+feature or extension specifications.</p><p>The collection of features and extensions of a profile are determined according
to the following ordered rules:</p><ol class="enumar"><li><p>initialize the features and extensions of the profile to the empty
set;</p></li><li><p>if a <code>use</code> attribute is present, then augment the profile
with the set of features and extensions specified by the referenced
@@ -1694,7 +1706,8 @@
second. Other frame rate multipliers apply to different regions of
usage and video format standards.</p></div><div class="note"><p class="prefix"><b>Note:</b></p><p>Except in the case of PAL/M, the frame rate multiplier used for synchronizing with PAL
formatted video objects at 25 frames per second is nominally 1:1.</p></div></div><div class="div3">
-<h4><a id="parameter-attribute-markerMode"></a>6.2.6 ttp:markerMode</h4><p>The <code>ttp:markerMode</code> attribute is used to specify
+<h4><a id="parameter-attribute-markerMode"></a>6.2.6 ttp:markerMode</h4><table border="1" class="ednote" summary="Editorial note: Obsolete ttp:markerMode"><tr class="ednote-r1"><td align="left" valign="top"><b>Editorial note: Obsolete ttp:markerMode</b></td><td align="right" valign="top">2013-09-05</td></tr><tr class="ednote-r2"><td colspan="2" align="left" valign="top">Designate ttp:markerMode as obsolete. If specified, and if feature #markerMode or #markerMode-continuous is not
+required, then the specified value is to be ignored and the default value 'discontinuous' applies.</td></tr></table><p>The <code>ttp:markerMode</code> attribute is used to specify
constraints on the interpretation and use of time expressions
that correspond with <a href="#smpte12m">[SMPTE 12M]</a> time coordinates when operating
with time base of <code>smpte</code> as defined by
@@ -1887,7 +1900,8 @@
ttp:version
: <a href="#style-value-digit"><digit></a>+ // <em>value</em> > 0
</pre></div>
-</td></tr></tbody></table><p>A <code>ttp:version</code> attribute must be specified on the root <code>tt</code>
+</td></tr></tbody></table><p></p><table border="1" class="ednote" summary="Editorial note: Possibly change ttp:version to ttm:version"><tr class="ednote-r1"><td align="left" valign="top"><b>Editorial note: Possibly change ttp:version to ttm:version</b></td><td align="right" valign="top">2013-09-05</td></tr><tr class="ednote-r2"><td colspan="2" align="left" valign="top">Unless normative processing or conformance language makes use of <code>ttp:version</code> then it
+should be changed to live in the TT Metadata Namespace, i.e., as <code>ttm:version</code>.</td></tr></table><p>A <code>ttp:version</code> attribute must be specified on the root <code>tt</code>
element of a <a href="#terms-document-instance">document instance</a> if it
requires support for a <a href="#terms-feature">feature</a> not defined by <a href="#ttml1">[TTML1]</a>.</p><p>If not specified, the version must be considered to be
equal to one (1). If specified, then the version must be greater than zero (0). The version associated
@@ -2185,7 +2199,9 @@
in the core vocabulary catalog:</p><ul><li><p><a href="#content-attribute-id"><b>7.2.1 xml:id</b></a></p></li><li><p><a href="#content-attribute-lang"><b>7.2.2 xml:lang</b></a></p></li><li><p><a href="#content-attribute-space"><b>7.2.3 xml:space</b></a></p></li></ul><div class="div3">
<h4><a id="content-attribute-id"></a>7.2.1 xml:id</h4><p>The <code>xml:id</code> attribute is used as defined by
<a href="#xmlid">[XML ID]</a>.</p><p>The <code>xml:id</code> attribute may be used with any element in the
-core vocabulary catalog.</p></div><div class="div3">
+core vocabulary catalog.</p><table border="1" class="ednote" summary="Editorial note: Deprecating xml:id in favor of unqualified id"><tr class="ednote-r1"><td align="left" valign="top"><b>Editorial note: Deprecating xml:id in favor of unqualified id</b></td><td align="right" valign="top">2013-09-05</td></tr><tr class="ednote-r2"><td colspan="2" align="left" valign="top">Consider deprecating <code>xml:id</code>, using unqualified <code>id</code> instead. If deprecated, then require
+a document to only use <code>xml:id</code> or <code>id</code>, i.e., mixed use to be prohibited. See
+<a href="https://www.w3.org/AudioVideo/TT/tracker/issues/205">Issue 205</a>.</td></tr></table></div><div class="div3">
<h4><a id="content-attribute-lang"></a>7.2.2 xml:lang</h4><p>The <code>xml:lang</code> attribute is used as defined by
<a href="#xml10">[XML 1.0]</a>, §2.12, <em>Language Identification</em>.</p><p>The <code>xml:lang</code> attribute must be specified on the <code>tt</code>
element and may be specified by an instance of any other element type
@@ -3852,7 +3868,9 @@
specified style set of each content and
layout element.</p><p>Styles are further propagated to content matter
using:
-</p><ul><li><p><a href="#semantics-style-inheritance-content">content style inheritance</a></p></li><li><p><a href="#semantics-style-inheritance-content">region style inheritance</a></p></li></ul><p>For the purpose of determining inherited styles, the element hierarchy of
+</p><ul><li><p><a href="#semantics-style-inheritance-content">content style inheritance</a></p></li><li><p><a href="#semantics-style-inheritance-content">region style inheritance</a></p></li></ul><table border="1" class="ednote" summary="Editorial note: Layout Style Inheritance"><tr class="ednote-r1"><td align="left" valign="top"><b>Editorial note: Layout Style Inheritance</b></td><td align="right" valign="top">2013-09-05</td></tr><tr class="ednote-r2"><td colspan="2" align="left" valign="top">Regions should be able to inherit styles from a common ancestor in order to prevent
+having to full populate region styles. <a href="https://www.w3.org/AudioVideo/TT/tracker/issues/277">Issue 277</a> proposes
+inheritance from the layout element.</td></tr></table><p>For the purpose of determining inherited styles, the element hierarchy of
an intermediate synchronic document form of a <a href="#terms-document-instance">document instance</a> must be used, where
such intermediate forms are defined by <a href="#semantics-region-layout-step-1"><b>9.3.3 Intermediate Synchronic Document Construction</b></a>.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>The intermediate synchronic document form is utilized rather than
the original form in order to facilitate region inheritance
@@ -4866,7 +4884,8 @@
<em>Content:</em> <a href="#element-vocab-group-table">Metadata.class</a>*
</animate>
</pre></div>
-</td></tr></tbody></table><p></p><p>Except for the constraints or variations enumerated below, the semantics of the <code>animate</code> element and its attributes
+</td></tr></tbody></table><p></p><table border="1" class="ednote" summary="Editorial note: Change xlink:href to href"><tr class="ednote-r1"><td align="left" valign="top"><b>Editorial note: Change xlink:href to href</b></td><td align="right" valign="top">2013-09-05</td></tr><tr class="ednote-r2"><td colspan="2" align="left" valign="top">The SVG WG is deprecating xlink:href, in favor of using an unqualified href attribute. See
+<a href="http://www.w3.org/Graphics/SVG/WG/wiki/Href">SVG Wiki: Href</a>. We should probably just specify the use of unqualified href.</td></tr></table><p>Except for the constraints or variations enumerated below, the semantics of the <code>animate</code> element and its attributes
enumerated above are defined to be those specified by <a href="#svg11">[SVG 1.1]</a>, §19.2.12:</p><ol class="enumar"><li><p>For the purpose of interpreting an <code>attributeName</code> attribute, an <code>attributeType</code>
with a value of <code>XML</code> applies, about which see <a href="#svg11">[SVG 1.1]</a>, §19.2.5.</p></li><li><p>If no <code>accumulate</code> attribute is specified, then an <em>accumlate</em> value of <code>none</code> applies.</p></li><li><p>If no <code>additive</code> attribute is specified, then an <em>additive</em> value of <code>replace</code> applies.</p></li><li><p>If no <code>calcMode</code> attribute is specified, then a <em>calcMode</em> value of <code>linear</code> applies.</p></li><li><p>If no <code>fill</code> attribute is specified, then a <em>fill</em> value of <code>remove</code> applies.</p></li><li><p>If an <code>xlink:href</code> attribute is specified, then the <code>animate</code> element must be a child of an
<a href="#animation-vocabulary-animation">animation</a> element; conversely, if an <code>animate</code> element is a child of
@@ -4933,7 +4952,8 @@
<em>Content:</em> <a href="#element-vocab-group-table">Metadata.class</a>*
</set>
</pre></div>
-</td></tr></tbody></table><p></p><p>Except for the constraints or variations enumerated below, the semantics of the <code>set</code> element and its attributes
+</td></tr></tbody></table><p></p><table border="1" class="ednote" summary="Editorial note: Change xlink:href to href"><tr class="ednote-r1"><td align="left" valign="top"><b>Editorial note: Change xlink:href to href</b></td><td align="right" valign="top">2013-09-05</td></tr><tr class="ednote-r2"><td colspan="2" align="left" valign="top">The SVG WG is deprecating xlink:href, in favor of using an unqualified href attribute. See
+<a href="http://www.w3.org/Graphics/SVG/WG/wiki/Href">SVG Wiki: Href</a>. We should probably just specify the use of unqualified href.</td></tr></table><p>Except for the constraints or variations enumerated below, the semantics of the <code>set</code> element and its attributes
enumerated above are defined to be those specified by <a href="#svg11">[SVG 1.1]</a>, §19.2.13:</p><ol class="enumar"><li><p>The attributes targetted by a <code>set</code> element and the discrete values to be applied to these attributes are
specified by direct use of attributes in the TT Style namespace (as opposed to using
<code>attributeName</code> and <code>to</code> attributes). For example, specifying <code>tts:color="red"</code> is to be
@@ -7055,7 +7075,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="d3e21644"></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="d3e21750"></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
@@ -7112,7 +7132,7 @@
and <code>@version</code> on the <code>svg:svg</code> element.</p></li><li><p>Conceptually derived from existing <code>tt:layout</code> element,
which is a generic container for layout specifications, but for use
in defining animation specifications that apply to targetted elements.</p></li></ol></div></div><div class="div2">
-<h3><a id="d3e22161"></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="d3e22267"></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
@@ -7204,9 +7224,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="d3e23154"></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="d3e23260"></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="d3e23318"></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="d3e23424"></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">