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

On Mon, Jun 29, 2009 at 8:57 AM, Glenn Adams<gadams@xfsi.com> wrote:
> 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.


If this is the case, then we should describe in the draft that "dur"
and "end" cannot be used together and that in the case where they are,
"dur" overrules "end". This would at least resolve the case of
conflict for a DFXP parser. We need to resolve this in the DFXP spec,
because it should not require the reading and understanding of the
much more complex SMIL timing model to implement a DFXP parser.

Note that I think that is what I have read out of the SMIL
specification, namely that "dur" is the maximum duration that an
element is allowed to last for, even if it is actually longer.


Regards,
Silvia.

Received on Monday, 29 June 2009 00:47:29 UTC