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

But they (end and dur) *can* be used together, and such use is well defined
by SMIL semantics, and has a well defined resolution. See [1] under
"Defining the simple duration" and "Active duration algorithm". We most
vehemently do not wish to attempt to re-express or paraphrase this
(admittedly) complex portion of the SMIL specification.
[1]
http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html#Timing-SemanticsOfTimingModel

On Mon, Jun 29, 2009 at 8:46 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

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