Merge
authorpal@sandflow.org
Thu, 17 Jul 2014 08:30:14 -0700
changeset 663 9779e4a63709
parent 662 f82b25ca25b7 (current diff)
parent 661 352ad3cfac32 (diff)
child 664 464e198074fc
Merge
--- a/ttml1/spec/ttml1-errata.html	Thu Jul 17 08:30:04 2014 -0700
+++ b/ttml1/spec/ttml1-errata.html	Thu Jul 17 08:30:14 2014 -0700
@@ -12,7 +12,7 @@
     .error{ background:  #dddddd;border-width: 1;margin-top:1cm;}
   </style>
     <title>TTML1 - Errata</title>
-    <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css" />
+    <link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/base.css" />
   </head>
   <body>
     <h1>Errata for Timed Text Markup Language 1 (TTML1)</h1>
@@ -38,7 +38,7 @@
     <hr title="Separator from Header" />
     <h2>About the TTML1 Recommendation</h2>
     <p>The <a href="http://www.w3.org/TR/2013/REC-ttml1-20130924/">TTML1
-        Recommendation</a> has been produced by the W3C <a href="http://www.w3.org/AudioVideo/TT/">Timed
+        Recommendation</a> was produced by the W3C <a href="http://www.w3.org/AudioVideo/TT/">Timed
         Text (TT) Working Group</a> as part of the W3C <a href="http://www.w3.org/2008/WebVideo/">Video
         in the Web Activity</a>.</p>
     <p>This document lists the known errata to the <a href="http://www.w3.org/TR/2013/REC-ttml1-20130924/">TTML1
@@ -54,12 +54,16 @@
     <h2>Conventions</h2>
     <p>Added text marked <span class="diff-add">thus</span>. Removed text
       marked <span class="diff-del">thus</span>. Changed text marked <span class="diff-chg">thus</span>.</p>
-    <h2 id="errors">Known errors as of 30 January 2014</h2>
+    <h2 id="errors">Known errata as of 17 July 2014</h2>
     <ul>
       <li><a href="#errata-5.2-1">Correction in TTML1 Section 5.2 Profiles</a>
           (published 2014-01-30)</li>
-      <li><a href="#errata-10.2.3-1">Correction in TTML1 Section 10.2.3 Duration (dur) Attribute</a>
-          (published 2014-04-24)</li>
+      <li><a href="#errata-8.2.7-1">Correction in TTML1 Section 8.2.7 tts:extent attribute</a>
+          (published 2014-07-17)</li>
+      <li><a href="#errata-8.2.16-1">Correction in TTML1 Section 8.2.16 tts:padding attribute</a>
+          (published 2014-07-17)</li>
+      <li><a href="#errata-10.2.3-1">Correction in TTML1 Section 10.2.3 Duration (dur) attribute</a>
+          (published 2014-07-17)</li>
       <li><a href="#errata-C-1">Correction in TTML1 Appendix C - Media Type
           Registration</a> (published 2014-01-30)</li>
       <li><a href="#errata-M-1">Correction in TTML1 Appendix M - Concrete
@@ -72,16 +76,40 @@
     <p class="description"><span class="title-description">Description</span>:</p>
     Minor typographical error, in the third paragraph under Table 2.
     <p class="description"><em><strong><span class="title-correction">Resolution</span></strong></em>:</p>
-    <p>change "... and must not <span class="diff-del">be </span>appear ..."</p>
+    <p>Change "... and must not <span class="diff-del">be </span>appear ..."</p>
     <p>to read "... and must not appear ...".</p>
     <hr />
+    <p id="errata-8.2.7-1">Correction
+        in <a href="http://www.w3.org/TR/2013/REC-ttml1-20130924/#style-attribute-extent">TTML1 Section 8.2.7 - tts:extent attribute</a> (published 2014-07-17) </p>
+    <p class="description"><span class="title-description">Description</span>:</p>
+    Provide rationale for use of greater value when interpreting closest supported value..
+    <p class="description"><em><strong><span class="title-correction">Resolution</span></strong></em>:</p>
+    <p>Add a 2nd paragraph to <strong>Note</strong> as follows:</p>
+    <p><span class="diff-add">This rule for resolving <em>closest supported value</em> for the <code>tts:extent</code> attribute makes use of the nearest larger rather than nearest smaller supported distance.
+    The rationale for this difference in treatment is that use of a larger extent ensures that the affected content will be contained in the region area without
+    causing region overflow, while use of a smaller extent makes region overflow more likely.</span></p>
+    <hr />
+    <p id="errata-8.2.16-1">Correction
+        in <a href="http://www.w3.org/TR/2013/REC-ttml1-20130924/#style-attribute-padding">TTML1 Section 8.2.16 - tts:padding attribute</a> (published 2014-07-17) </p>
+    <p class="description"><span class="title-description">Description</span>:</p>
+    Interpret closest supported value as least (not greatest) padding on a per-edge basis in order to prevent content area overflow.
+    <p class="description"><em><strong><span class="title-correction">Resolution</span></strong></em>:</p>
+    <p>Change text of <strong>Note</strong> from:</p>
+    <p>"In this context, the phrase <em>closest supported value</em> means the value for which the Euclidean distance between the computed padding and the
+    supported padding is minimized. If there are multiple closest supported values equally distant from the computed value, then the value most
+    distant from 0, i.e., the greatest padding, is used."</p>
+    <p>to read:</p>
+    <p>"In this context, the phrase <em>closest supported value</em> means the value for which the <span class="diff-add">one-dimensional </span>Euclidean distance between the computed padding and the
+    supported padding is minimized<span class="diff-add"> on a per-edge basis</span>. If there are multiple closest supported values equally distant from the computed value<span class="diff-add"> for a given edge</span>, then the value <span class="diff-chg">least</span>
+    distant from 0, i.e., the <span class="diff-chg">least</span> padding, is used."</p>
+    <hr />
     <p id="errata-10.2.3-1">Correction
-        in <a href="http://www.w3.org/TR/2013/REC-ttml1-20130924/#timing-attribute-dur">TTML1 Section 10.2.3 - dur attribute</a> (published 2014-04-24) </p>
+        in <a href="http://www.w3.org/TR/2013/REC-ttml1-20130924/#timing-attribute-dur">TTML1 Section 10.2.3 - dur attribute</a> (published 2014-07-17) </p>
     <p class="description"><span class="title-description">Description</span>:</p>
     Add clarification about use of zero duration.
     <p class="description"><em><strong><span class="title-correction">Resolution</span></strong></em>:</p>
     <p>Add the following sentence to the last paragraph (that cites [SMIL 2.1] § 10.4.1):</p>
-    <p><span class="diff-add">In a willful violation of <a href="http://www.w3.org/TR/2013/REC-ttml1-20130924/#smil21">[SMIL 2.1]</a>, § 10.4.1,
+    <p><span class="diff-add">In a deliberate divergence from <a href="http://www.w3.org/TR/2013/REC-ttml1-20130924/#smil21">[SMIL 2.1]</a>, § 10.4.1,
     the value of the <code>dur</code> attribute is permitted to be zero (0).</span></p>
     <hr />
     <p id="errata-C-1">Correction
@@ -242,7 +270,7 @@
     <p class="description"><span class="title-description">Description</span>:</p>
     Add standard XML named character entities unintentionally omitted from note.
     <p class="description"><em><strong><span class="title-correction">Resolution</span></strong></em>:</p>
-    <p>change &quot;... only the following named character entities are defined:
+    <p>Change &quot;... only the following named character entities are defined:
     <code>&amp;amp;</code>,
     <code>&amp;lt;</code>,
     and <code>&amp;gt;</code>.&quot;
--- a/ttml2/spec/ttml2.html	Thu Jul 17 08:30:04 2014 -0700
+++ b/ttml2/spec/ttml2.html	Thu Jul 17 08:30:14 2014 -0700
@@ -82,9 +82,9 @@
 .obsoleted { background-color: #f26d7d }
 .reqattr { font-weight: bold }
 .optattr { font-style: italic }
-</style><link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/W3C-ED.css"></head><body>Last Modified: $Date: 2014/07/17 02:02:18 $<div id="revisions"></div><div class="head">
+</style><link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/W3C-ED.css"></head><body>Last Modified: $Date: 2014/07/17 04:38:37 $<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: 2014/07/17 02:02:18 $ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
+<h2><a id="w3c-doctype"></a>Editors' copy $Date: 2014/07/17 04:38:37 $ @@ @@@@ @@@@</h2><dl><dt>This version:</dt><dd>
 <a href="ttml2.html">ttml2.html</a>
 </dd><dt>Latest version:</dt><dd><a href="https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html?content-type=text/html;charset=utf-8">https://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>
@@ -437,11 +437,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>
-&nbsp;&nbsp;&nbsp;&nbsp;J.1 <a href="#d3e25237">Element Derivation</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;J.2 <a href="#d3e25754">Attribute Derivation</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;J.1 <a href="#d3e25234">Element Derivation</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;J.2 <a href="#d3e25751">Attribute Derivation</a><br>
 K <a href="#qa">QA Framework Compliance</a> (Non-Normative)<br>
-&nbsp;&nbsp;&nbsp;&nbsp;K.1 <a href="#d3e26747">Requirements</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;K.2 <a href="#d3e26911">Guidelines</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;K.1 <a href="#d3e26744">Requirements</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;K.2 <a href="#d3e26908">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>
@@ -2299,13 +2299,13 @@
 equal to one (1). If specified, then the version must be greater than zero (0). The version associated
 with this version of the <a href="#terms-timed-text-markup-language">Timed Text Markup Language</a>
 specification is two (2).</p><p>A <code>ttp:version</code> attribute is considered to be significant only
-when specified on the <code>tt</code> element.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>A <a href="#terms-content-processor">content processor</a> may use the
+when specified on the <code>tt</code> element.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>A <a href="#terms-content-processor">content processor</a> typically uses the
 declared version to perform a preliminary assessment of whether it is capable of
 processing a given <a href="#terms-document-instance">document instance</a>.
-However, it must not assume that the <a href="#terms-document-instance">document instance</a>
+However, it does not assume that the <a href="#terms-document-instance">document instance</a>
 actually uses or requires support for a <a href="#terms-feature">feature</a>
 not defined in prior versions. In other
-words, a <a href="#terms-content-processor">content processor</a> must not reject
+words, a <a href="#terms-content-processor">content processor</a> does not reject
 a <a href="#terms-document-instance">document instance</a> simply because it declares
 it was authored against a version of the <a href="#terms-timed-text-markup-language">Timed Text Markup Language</a>
 specification that was not yet published at the time the processor was implemented.</p></div></div></div></div><div class="div1">
@@ -2768,9 +2768,9 @@
 span.</p><p>If no border width is specified in the value of the <code>tts:border</code> property,
 then the border width must be interpreted as if a width of
 <code>medium</code> were specified.</p><p>If a computed value of the border width associated with this attribute is not supported,
-then a <a href="#terms-presentation-processor">presentation processor</a> must use the closest supported value.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>In this context, the phrase <em>closest supported value</em> means the value for which the Euclidean distance between
-the computed border width and the supported border width is minimized. If there are multiple closest supported values equally distant from
-the computed value, then the value most distant from 0, i.e., the greatest border width, is used.</p></div><p>If no border style is specified in the value of the <code>tts:border</code> property,
+then a <a href="#terms-presentation-processor">presentation processor</a> must use the closest supported value.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>In this context, the phrase <em>closest supported value</em> means the value for which the one-dimensional Euclidean distance between
+the computed border width and the supported border width is minimized on a per-edge basis. If there are multiple closest supported values equally distant from
+the computed value for a given edge, then the value least distant from 0, i.e., the least border width, is used.</p></div><p>If no border style is specified in the value of the <code>tts:border</code> property,
 then the border style must be interpreted as if a style of
 <code>none</code> were specified.</p><p>If a computed value of the border style associated with this attribute is not supported,
 then a <a href="#terms-presentation-processor">presentation processor</a> must use the value <code>solid</code>.</p><p>If no border color is specified in the value of the <code>tts:border</code> property,
@@ -3002,8 +3002,8 @@
 value of this attribute.</p><p>If a computed value of the property associated with this attribute is not supported,
 then a <a href="#terms-presentation-processor">presentation processor</a> must use the closest supported value.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>In this context, the phrase <em>closest supported value</em> means the value for which the Euclidean distance between
 the computed extent and the supported extent is minimized. If there are multiple closest supported values equally distant from
-the computed value, then the value most distant from [0,0], i.e., of greatest extent, is used.</p><p>Unlike other style attributes, the rule for resolving <em>closest supported value</em> for the <code>tts:extent</code> attribute
-makes use of the nearest larger rather than nearest smaller supported distance. The rationale for this difference in treatment is
+the computed value, then the value most distant from [0,0], i.e., of greatest extent, is used.</p><p>This rule for resolving <em>closest supported value</em> makes use of the nearest larger rather than nearest smaller supported distance.
+The rationale for this difference in treatment is
 that use of a larger extent ensures that the affected content will be contained in the region area without causing region overflow,
 while use of a smaller extent makes region overflow more likely.</p></div><p>The <code>tts:extent</code> style is illustrated by the following example.</p><a id="style-attribute-extent-example-1"></a><table class="example"><caption>Example Fragment – Extent</caption><tbody><tr><td>
 <div class="exampleInner"><pre>
@@ -3436,9 +3436,9 @@
 to the after edge.
 If four <a href="#style-value-length">&lt;length&gt;</a> specifications are provided, then they apply to before, end,
 after, and start edges, respectively.</p><p>The <a href="#style-value-length">&lt;length&gt;</a> value(s) used to express padding must be non-negative.</p><p>If a computed value of the property associated with this attribute is not supported,
-then a <a href="#terms-presentation-processor">presentation processor</a> must use the closest supported value.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>In this context, the phrase <em>closest supported value</em> means the value for which the Euclidean distance between
-the computed padding and the supported padding is minimized. If there are multiple closest supported values equally distant from
-the computed value, then the value most distant from 0, i.e., the greatest padding, is used.</p></div><p>The <code>tts:padding</code> style is illustrated by the following example.</p><table border="1" class="ednote" summary="Editorial note: Enhance Padding Example"><tr class="ednote-r1"><td align="left" valign="top"><b>Editorial note: Enhance Padding Example</b></td><td align="right" valign="top">2013-08-24</td></tr><tr class="ednote-r2"><td colspan="2" align="left" valign="top">Enhance padding example to demonstrate padding on content elements.</td></tr></table><p></p><a id="style-attribute-padding-example-1"></a><table class="example"><caption>Example Fragment – Padding</caption><tbody><tr><td>
+then a <a href="#terms-presentation-processor">presentation processor</a> must use the closest supported value.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>In this context, the phrase <em>closest supported value</em> means the value for which the one-dimensional Euclidean distance between
+the computed padding and the supported padding is minimized on a per-edge basis. If there are multiple closest supported values equally distant from
+the computed value for a given edge, then the value least distant from 0, i.e., the least padding, is used.</p></div><p>The <code>tts:padding</code> style is illustrated by the following example.</p><table border="1" class="ednote" summary="Editorial note: Enhance Padding Example"><tr class="ednote-r1"><td align="left" valign="top"><b>Editorial note: Enhance Padding Example</b></td><td align="right" valign="top">2013-08-24</td></tr><tr class="ednote-r2"><td colspan="2" align="left" valign="top">Enhance padding example to demonstrate padding on content elements.</td></tr></table><p></p><a id="style-attribute-padding-example-1"></a><table class="example"><caption>Example Fragment – Padding</caption><tbody><tr><td>
 <div class="exampleInner"><pre>
 &lt;region xml:id="r1"&gt;
   &lt;style tts:extent="446px 104px"/&gt;
@@ -7653,7 +7653,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="d3e25237"></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="d3e25234"></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
@@ -7710,7 +7710,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="d3e25754"></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="d3e25751"></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
@@ -7802,9 +7802,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>&nbsp;<a href="#qaf-sg">[QAF SG]</a>.</p><div class="div2">
-<h3><a id="d3e26747"></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="d3e26744"></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="d3e26911"></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="d3e26908"></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">
--- a/ttml2/spec/ttml2.xml	Thu Jul 17 08:30:04 2014 -0700
+++ b/ttml2/spec/ttml2.xml	Thu Jul 17 08:30:14 2014 -0700
@@ -4244,13 +4244,13 @@
 <p>A <att>ttp:version</att> attribute is considered to be significant only
 when specified on the <el>tt</el> element.</p>
 <note role="elaboration">
-<p>A <loc href="#terms-content-processor">content processor</loc> may use the
+<p>A <loc href="#terms-content-processor">content processor</loc> typically uses the
 declared version to perform a preliminary assessment of whether it is capable of
 processing a given <loc href="#terms-document-instance">document instance</loc>.
-However, it must not assume that the <loc href="#terms-document-instance">document instance</loc>
+However, it does not assume that the <loc href="#terms-document-instance">document instance</loc>
 actually uses or requires support for a <loc href="#terms-feature">feature</loc>
 not defined in prior versions. In other
-words, a <loc href="#terms-content-processor">content processor</loc> must not reject
+words, a <loc href="#terms-content-processor">content processor</loc> does not reject
 a <loc href="#terms-document-instance">document instance</loc> simply because it declares
 it was authored against a version of the <loc href="#terms-timed-text-markup-language">Timed Text Markup Language</loc>
 specification that was not yet published at the time the processor was implemented.</p>
@@ -5169,9 +5169,9 @@
 <p>If a computed value of the border width associated with this attribute is not supported,
 then a <loc href="#terms-presentation-processor">presentation processor</loc> must use the closest supported value.</p>
 <note role="elaboration">
-<p>In this context, the phrase <emph>closest supported value</emph> means the value for which the Euclidean distance between
-the computed border width and the supported border width is minimized. If there are multiple closest supported values equally distant from
-the computed value, then the value most distant from 0, i.e., the greatest border width, is used.</p>
+<p>In this context, the phrase <emph>closest supported value</emph> means the value for which the one-dimensional Euclidean distance between
+the computed border width and the supported border width is minimized on a per-edge basis. If there are multiple closest supported values equally distant from
+the computed value for a given edge, then the value least distant from 0, i.e., the least border width, is used.</p>
 </note>
 <p>If no border style is specified in the value of the <att>tts:border</att> property,
 then the border style must be interpreted as if a style of
@@ -5720,8 +5720,8 @@
 <p>In this context, the phrase <emph>closest supported value</emph> means the value for which the Euclidean distance between
 the computed extent and the supported extent is minimized. If there are multiple closest supported values equally distant from
 the computed value, then the value most distant from [0,0], i.e., of greatest extent, is used.</p>
-<p>Unlike other style attributes, the rule for resolving <emph>closest supported value</emph> for the <att>tts:extent</att> attribute
-makes use of the nearest larger rather than nearest smaller supported distance. The rationale for this difference in treatment is
+<p>This rule for resolving <emph>closest supported value</emph> makes use of the nearest larger rather than nearest smaller supported distance.
+The rationale for this difference in treatment is
 that use of a larger extent ensures that the affected content will be contained in the region area without causing region overflow,
 while use of a smaller extent makes region overflow more likely.</p>
 </note>
@@ -6731,9 +6731,9 @@
 <p>If a computed value of the property associated with this attribute is not supported,
 then a <loc href="#terms-presentation-processor">presentation processor</loc> must use the closest supported value.</p>
 <note role="elaboration">
-<p>In this context, the phrase <emph>closest supported value</emph> means the value for which the Euclidean distance between
-the computed padding and the supported padding is minimized. If there are multiple closest supported values equally distant from
-the computed value, then the value most distant from 0, i.e., the greatest padding, is used.</p>
+<p>In this context, the phrase <emph>closest supported value</emph> means the value for which the one-dimensional Euclidean distance between
+the computed padding and the supported padding is minimized on a per-edge basis. If there are multiple closest supported values equally distant from
+the computed value for a given edge, then the value least distant from 0, i.e., the least padding, is used.</p>
 </note>
 <p>The <att>tts:padding</att> style is illustrated by the following example.</p>
 <ednote>