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

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

>
> * What are the thoughts behind introducing the parameters
> pixelAspectRatio, frameRate, subFrameRate, frameRateMultiplier,
> tickRate - I personally think they should not be inside the timed text
> format, but be taken care of by the software that aligns the timed
> text with the media.
>
> * What are the reasons behind assuming an anonymous span element
> inside p? Is that really necessary? It is very confusing and I would
> assume it could be resolved by just adding p the features wher span
> has capabilities. That would be more explicit and logical IMHO.
>
> * It is not clear where the origin of container placement is until
> section 8.2.15 . In fact it is not even there spelled out that the
> origin is at the top left of the root container and containing
> containers are placed from there. It should probably be something that
> is specified in 7.1.1 together with tt.
>
> * Why is the backgroundColor called "transparent", when the region
> attribute is called "opacity" - why not choose the same word?
>
> * Finally, I'd like to suggest that the set of metadata elements is
> rather restrictive and arbitrary, in particular the "actor" element
> which is more than a simple unstructured meta data element. The given
> scheme is too much focused on Movie and TV show meta data, but DFXP
> should be more widely applicable than that. I would suggest doing what
> HTML does, namely provide a mechanism to give name-value pairs rather
> than a fixed set of metadata elements. This is more flexible and will
> enable e.g. Dublin Core or any other scheme to be used.
>
> I hope this is useful feedback and appreciate your replies.
>
> Best Regards,
> Silvia.
>
>
>
> On Sat, Jun 6, 2009 at 4:43 AM, Philippe Le Hegaret<plh@w3.org> wrote:
>> The document is at:
>>  http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090602/
>>
>> We'll move the draft to Proposed Recommendation after that, so make  
>> sure
>> to comment on this draft before June 30.
>>
>> --
>> Philippe
>>
>>
>>
>

Received on Sunday, 28 June 2009 21:21:41 UTC