ISSUE-382: Require a computed non-indefinite begin time
require a computed begin time
Require a computed non-indefinite begin time
- State:
- CLOSED
- Product:
- TTML IMSC 1.0
- Raised by:
- Pierre-Anthony Lemieux
- Opened on:
- 2015-04-09
- Description:
- Avoid an unresolvable time scenario when documents are contained in formats that say 'start some defined period into the document' but the document has no definite computed begin value, by requiring that all documents have a definite computed begin time.
- Related Actions Items:
- No related actions
- Related emails:
- Re: London Face to face meeting minutes (from tmichel@w3.org on 2017-01-16)
- London Face to face meeting minutes (from nigel.megitt@bbc.co.uk on 2017-01-13)
- {minutes} TTWG Meeting 2015-05-07 (from nigel.megitt@bbc.co.uk on 2015-05-07)
- {agenda} TTWG Meeting 2015-05-07 (from nigel.megitt@bbc.co.uk on 2015-05-06)
- Re: Issue-382 review (from nigel.megitt@bbc.co.uk on 2015-05-05)
- Second CR for IMSC1 (from pal@sandflow.com on 2015-05-04)
- Re: Issue-382 review (from pal@sandflow.com on 2015-05-04)
- Re: Issue-382 review (from pal@sandflow.com on 2015-05-01)
- Issue-382 review (from nigel.megitt@bbc.co.uk on 2015-05-01)
- {minutes} TTWG Meeting 2015-04-30 (from nigel.megitt@bbc.co.uk on 2015-04-30)
- April F2F Meeting minutes (from nigel.megitt@bbc.co.uk on 2015-04-22)
- {minutes} TTWG Meeting 2015-04-16 (from nigel.megitt@bbc.co.uk on 2015-04-16)
- ISSUE-382 (require a computed begin time): Require a computed non-indefinite begin time [TTML IMSC 1.0] (from sysbot+tracker@w3.org on 2015-04-09)
Related notes:
[Meeting 2015-04-30] Consensus was to add a statement alongside #timing that begin and end SHOULD be present on at least one of div, p and span [at every point in the document hierarchy].
Nigel Megitt, 30 Apr 2015, 15:16:05Addressed at https://dvcs.w3.org/hg/ttml/rev/5062322f5360
Pierre-Anthony Lemieux, 30 Apr 2015, 15:50:56Review notes:
1. The changeset has highlighted some wording that I didn't previously notice:
"ttp:tickRate shall be present on the tt element if the #time-offset-with-ticks feature is used in the document."
This is problematic because it isn't clear if it means that the document expresses a profile requirement for the #time-offset-with-ticks feature or if it means that the document includes any time expressions that require the processor to have the feature. I suggest changing it to:
"ttp:tickRate shall be present on the tt element if the document contains any time expression that uses the t metric."
2. Looking at the wording for #frames:
"If the document includes any time expression that uses the frames term, the ttp:frameRate attribute shall be present on the tt element."
It doesn't say if the feature may be used or not, and omits the possibility of offset times with f metric. It may better be written as:
"MAY be used, with the following additional constraints: If the document includes any clock time expression that uses the frames term or any offset time expression that uses the f metric, the ttp:frameRate attribute SHALL be present on the tt element."
The #timing feature has two SHOULD constraints, but neither of them is totally clear.
3. The first is that the same time expression should be used throughout, and then it says 'either clock-time or offset-time' - but there are syntax choices within either clock-time or offset-time; so if different clock-time expression formats are mixed is that in the spirit of the recommendation or not? e.g. would <p begin="00:10:00.375" end="00:10:02:15"> be okay?
4. The second is that the new constraint doesn't take into account the hierarchy. I'd suggest amended wording such as: "begin and end attributes SHOULD be specified on at least one ancestor of every content element that contains br elements or text nodes, i.e. a span, a p, a div or a body."
See https://dvcs.w3.org/hg/ttml/rev/14e47051b5af
Pierre-Anthony Lemieux, 2 May 2015, 18:41:14Display change log