Consider improving identification of divs corresponding to script events #233
Comments
Also fix broken HTML formatting with `<ul>` inside `<p>` where it doesn't belong.
* wip commit * More wip changes * Fix broken reference to unrecognised attribute section * Mention design goal of future compatibility * Add section on computed attribute values * Add TODO for validation warnings and errors * Add example unexpected attributes * More TTML to DAPT model considerations * Make Data model diagram clearly informative * Add links * Put explanatory text around examples into a single example `<aside>` including the example XML * Add rule for non-rejection of Script Events if they contain unrecognised attributes * Add the results of applying the rules to the div and p example * Add example showing the effect of attribute computation * Add section about retaining unrecognised vocabulary * Add section about validation warnings and errors * Adjust processor requirement to ignore unrecognised attributes Clarify that attribute computation needs to happen before anything is ignored. * Move new section to after Constraints * WIP changes * Rework introduction to Mapping from TTML to DAPT section. * Make it normative. * Make most subsections informative, but make the normative ones use normative keywords, e.g. the one about div and p structural handling. * Add section for document conformance claims handling * Handle unrecognised vocabulary better As discussed in #216 (comment): * Define restriction on `ttp:contentProfiles` values within the section on contentProfiles * Define and use the term "foreign vocabulary" * Advise retention of unsupported foreign vocabulary in `<metadata>` elements * Require pruning of unsupported vocabulary outside `<metadata>` elements * Provide a documented path to allowing foreign vocabulary to be defined and supported * Note that structural changes could lead to loss of foreign vocabulary if the `<metadata>` element to which it is associated is removed. * Improve section heading for Proprietary Metadata Because it now also describes how to insert foreign vocabulary * Mark "Using computed attribute values" as informative It contains no normative keywords. * scriptEventMapping extension, address Respec changes Add extension feature `#scriptEventMapping` and make it optional Address recent changes to Respec to fix up tables that used to have `class="simple"` and to make the spec work in dark mode. * Address review feedback * minor editorial wording tweak * Add link to issue #233 Also fix broken HTML formatting with `<ul>` inside `<p>` where it doesn't belong. * Move note to §6.1 * Allow for DAPT documents with other content profiles * Warn not to put data in metadata if it depends on the document contents * Define Unrecognised vocabulary * Address review feedback Remove unnecessary sentence; define MUST before SHOULD. * Split SHOULD requirement for presentation processors to ignore elements and attributes. * Rewrite first section of Mapping from TTML to the DAPT Data Model Based on @cconcolato 's review comments, with small editorial adjustments. * Attempt to address feedback Rename "Document conformance claims on output", mark as informative; move the section about processor behaviour into a new normative section "Not supporting features excluded by the content profile". Some wording edits too. * Use xml:space as an example of non-DAPT data model attributes on div * Make processorProfiles generic like contentProfiles * Change pruning/preservation rules to ref unrecognised vocabulary * Address review feedback Restructure the Unrecognised Elements and Attributes section to split unrecognised vocabulary sections from foreign vocabulary sections. Rename Profile Designator section to be plural. Delete informative section that repeats normative requirements elsewhere, re avoiding unverified profile conformance signalling. * Address review feedback Define foreign vocabulary before referencing it. Put considerations for transformation and validation processors into a separate subsection of §6. * Presentation processors should ignore unrecognised vocabulary * Clarify sentence about namespace mutability. * Reword validation warnings section Remove "optional" category. * Improve sentence structure re TTML pruning * Positively identify TTML to DAPT model mappings * Explicitly state that nested divs are allowed Makes the data model section match the requirements of the TTML -> DAPT model parsing section. * Clarify that a DAPT Document is a "timed text content document instance" Closes #234. * Introduce the root `<tt>` element as a note Rather than assuming that the reader already knows exactly what a TTML2 timed text content document instance looks like. * Tidy the definitions of the TTML representation of DAPT Scripts * Be explicit about the need for `<head>`, `<metadata>` and `<body>` elements. * Specify the path of Script Events and Text objects, for convenience. * Be clear that the `daptm:langSrc` attribute on a `<p>` element represents the Text Language Source (weird that we didn't before). * State that no semantic is defined for `<div>` elements that are not Script Events. * Now that there is explicit permission to have nested `<div>`s, allow for that in the section about handling `<div>` and `<p>` elements, i.e. they are not just a theoretical construct allowed in TTML, but they are explicitly permitted in DAPT too. * Address review feedback
|
One option mentioned in yesterday's call was to require |
|
Thinking more about this, and the current state of #241, I don't think it's a good idea to overload the meaning of I'm not convinced that we need to do anything here at all, but if we do need an explicit signal, I would like it to be something else. Maybe a |
I don't see it as overloading. They mean the same thing to me. Represents is only meaningful on a script event. It's the inheritance model and the compactness/verbosity considerations that make the concept blurry. I don't like that we depend on xml:id or that xml:id is required. It may be a good practice in some workflows but not in others. It makes also the algorithm for generating script events from divs awkward in my view. I don't have an easy solution. I need to think a bit more. |
|
We're not really depending on xml:id, we're just dependent on the |
|
Discussed in TTWG meeting 2024-09-27, agreed to close with no action; can re-open if implementation experience shows this is needed. |
Based on discussion at #216 (comment), I think we should have an explicit signal to indicate when a div represents a Script Event.
The text was updated successfully, but these errors were encountered: