Repository navigation
Clarify validation of undefined items in TT namespaces - #321
Conversation
|
Built version available at https://rawgit.com/w3c/ttml1/issue-251-ttml-ns-attribute-extension-build/index.html |
nigelmegitt
left a comment
There was a problem hiding this comment.
The explanatory paragraph needs some editing.
| restrictive definition of validity.</p> | ||
| </note> | ||
| <note> | ||
| <p>As illustrated in the following example, an <emph>Abstract Document Instance</emph> can be a <emph>Valid Abstract Document Instance</emph> even if it includes elements and attributes whose namespace names are listed in <specref ref="namespace-vocab-table"/> but are not defined in this version of the specification. Specifically, the element <code>foo</code> and the attribute <att>tts:foo</att> are pruned by above steps (1) and (3), respectively, because they are not members of the associated <emph>Abstract Document Type</emph>, even though their namespace names are listed in <specref ref="namespace-vocab-table"/>. |
There was a problem hiding this comment.
How can an element or attribute have a namespace name that is both listed in the table and not defined in the specification? Is that supposed to say that its namespace is listed in the table but its name is not defined within that namespace by this specification?
There was a problem hiding this comment.
Edited comment: Removed comments on the use of the term "namespace name" after checking the namespace spec.
There was a problem hiding this comment.
Is that supposed to say that its namespace is listed in the table but its name is not defined within that namespace by this specification?
Yes.
| </td> | ||
| </tr> | ||
| </tbody> | ||
| </table> |
There was a problem hiding this comment.
It seems to be more common in the spec to explain the example in following text rather than preceding text. Suggest moving the explanation to here.
| of <emph>Document Instance</emph> validity.</p> | ||
| </note> | ||
| <note role="clarification"> | ||
| <p>The schemas referenced by this specification are designed for use after the pruning steps (1)-(3) specified by <specref ref="doctypes"/> have been applied.</p> |
There was a problem hiding this comment.
I think I'd prefer "intended" rather than "designed" here but that's a minor point.
andreastai
left a comment
There was a problem hiding this comment.
From my side this PR can be merged once the ambiguous use of "namespace name" is removed.
I will also not object to the PR as the validation strategy has been in TTML 1 for a long time.
nigelmegitt
left a comment
There was a problem hiding this comment.
I'd still prefer the explanation to come beneath the fragment example but it's not a serious enough problem to block approval.
|
This change may need modification to match what gets written into TTML2 on this subject. |
Closes #251