W3C home > Mailing lists > Public > public-tt@w3.org > June 2009

Re: *Last Call* Timed Text document (Review by June 30)

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 29 Jun 2009 08:31:39 +1000
Message-ID: <2c0e02830906281531y4c054608p22d0802251bd1a69@mail.gmail.com>
To: Weck Daniel <daniel.weck@gmail.com>
Cc: "public-tt@w3.org List TTWG" <public-tt@w3.org>, Philippe Le Hegaret <plh@w3.org>
On Mon, Jun 29, 2009 at 7:20 AM, Weck Daniel<daniel.weck@gmail.com> wrote:
> On 28 Jun 2009, at 17:25, Silvia Pfeiffer wrote:
>> * What are the thoughts behind having start, end, and dur attributes
>> for timed elements? Why all three and not just two of them? There is
>> no specification in the draft of what happens when all three are given
>> and they contradict each other. This is a real problem in practice.
> I agree about the "end" and "dur" ambiguity. The problem stems from the fact
> that TimedText is making an explicit reference to the timing semantics of
> SMIL 2.1, but overrides the attribute grammar with a format that is very
> limited (i.e. no synchronization arcs, events, or access keys), without
> detailing the concrete semantic implications.
> In SMIL, an author can use "end" and "dur" at the *same time* for an actual
> purpose (i.e. this is a "feature"): this mechanism offers some interesting
> timing effects due to  precedence order of "end" over "dur" resolved values.
> In other words, "end" and "dur" are redundant in TimedText, in the sense
> that they are bound by simple arithmetic (end = begin + dur), which is not
> the case in SMIL because of more complex timing semantics and the way time
> values are resolved (e.g. non-deterministic events, animation sandwich
> model).
> Here's a suggestion: it's perfectly reasonable for TimedText's timing model
> to be much less rich than SMIL. It makes DFXP a lot easier to implement,
> whilst meeting the design requirements of captioning. In this case, why
> refer to the SMIL timing specification, which is inevitably going to be very
> confusing for captioning implementors ? Instead, why not explicitly describe
> the semantics of TimedText's simple timing model, in the DFXP specification
> itself ?
> References:
> http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090602/#timing-value-timeExpression
> vs:
> http://www.w3.org/TR/SMIL2/smil-timing.html#Timing-ResolvingTimes
> http://www.w3.org/TR/SMIL2/smil-timing.html#Timing-TimingAttributeGrammars

Thank god DFXP doesn't have the temporal dynamics of SMIL and can be
easily linearised. IIUC, "dur" in SMIL implies a duration limit on
elements whose duration may be unlimited e.g. because of repeats.
Since such things are not possible in DFXP, I would suggest removing
the "dur" attribute. It is indeed surplus and can lead to

Best Regards,
Received on Sunday, 28 June 2009 22:32:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:04 UTC