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

See inline.

On Mon, Jun 29, 2009 at 5: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.
>

[GA] While DFXP does subset the attribute syntax for begin, end, dur, it
does not subset or modify the semantics of these attributes. Therefore, the
SMIL semantics apply in full regarding the interpretation (and conflict
resolution) of these attributes.


> 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.
>

[GA] And because this is permitted by SMIL, it is also permitted by DFXP and
have the same semantic resolution.


> 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).


[GA] I agree it may be argued that they are redundant because DFXP does not
have the same complex features that come into play in SMIL where having both
dur (to express simple duration) and end (to express end of active duration)
is sometimes necessary. However, from an authoring perspective, it is
sometimes useful to use end and sometimes useful to use dur. For example, it
is often preferred to use end when using par time containers, but use dur
when using ser time containers. There was no apriori reason to eliminate one
of these, and since what is there is well defined (semantically), there is
no technical reason to do so either.


> 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 ?
>

[GA] We entertained this idea at a particular stage, but there were no
volunteers. Furthermore, we do not have the time to do so now, nor is it
technically necessary. Finally, if we did so, then I would imagine there
would be complaints from SYMM WG that we are trying to rewrite SMIL
semantics. This would require a very lengthy review process by SYMM WG to
make certain we didn't break something (semantically speaking). I'm afraid
it is completely impractical at this point in time.


> 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
>
>
>
>