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

Hi Philippe, all,

I have taken the time to go through most of the document and
understand where things come from. I haven't been involved in
specifying DFXP from the start and not followed closely, so this
feedback is from a clean pair of eyes.

I have written a blog post with my general feedback at
http://blog.gingertech.net/, and here is my specific feedback with
typos, missing examples, and feature feedback. It's lengthy because
the standard is lengthy. Enjoy!

1. Typos

Section 2.2 Terminology, Profile Definition Document
-> has a double "by"

Section 2.3 Document Conventions, XML Representation - Element
Information Item: example, third paragraph
-> has a double "the"

Section 6.1.1 ttp:profile, first Note
-> "...it is defined *an* how it is labeled:..." -> should be *and*

Section 7.1.1 tt, first sentence
-> remove surplus comma

Section 8.2 Styling Attribute Vocabulary, second Note
-> has a double "property"

Section 9.1.2 Region, last Note, second paragraph
-> "additionaly" should be written with two *ll*s

Section 10.3.1 <timeExpression>, second-last and last paragraph
-> both have a double "the"

Section 12.1.1 ttm:title, last paragraph
-> should read "ttm:title" instead of "ttm:name"


2. Missing Examples

In some places, it would be nice to extend the given description with
an example, just as has been done in other places. Here are the places
that I was missing examples for:

Section 6.2.2 ttp:clockMode
-> there is no example, and I'm curious how the gps, utc and local
attribute values work

Section 6.2.3 ttp:frameRate
and in fact subframeRate, tickRate and timeBase, too
-> there is no example anywhere in the document how to use these

Section 6.2.5 ttp:markerMode
-> there is no example of use

Section 6.2.6 ttp:pixelAspectRatio
-> no example of use in the draft

Section 6.2.8 ttp:smpteMode
-> no example of use

Section 8.2.18 tts:showBackground
-> has an example, but no rendering
(btw: I found the rendering really really helpful)

Section 8.2.24 tts:wrapOption
-> there is no example of what "wrap" looks like, only one for "noWrap"

Section 8.4.1.3 Chained Referential Styling, as well as 8.4.1.4,
8.4.2.1., 8.4.2.2
-> could also do with a rendering of the example

Section 9.1.2 region
-> could do with an example on the different timeContainer uses

Section 9.3.4 Elaborated Example
-> definitely needs rendering for the three time sections [0s,1s),
[1s,2s), [2s,3s)

Section 11.1.1 set (animation)
-> Content & Region Style animation examples need rendering


3. Individual issues

* I actually find the order in which sections come in the document not
helpful in understanding DFXP. Some of the sections come far too late
and are preconditions for understanding other features. For example, I
would move section 7.2 Content Attributes ahead of section 7.1 Content
Elements, the same for the styling attributes, layout attributes,
timing attributes, animation attributes, and meta data attributes in
relation to their elements. I would even suggest that the layout
specifications should come before styling.

* The "1c" value in section 8.2 does not become clear until section
8.3.11 where "abbreviation of "cell"" is mentioned in a comment. It
should be clarified earlier.

* Generally, I'm unhappy that styles cannot be represented in external
files in the way that CSS provides for it. Also, I am confused by the
fact that styles don't cascade. But I can understand the motivation
for this approach.

* I really think the in-line profile definition that DFXP provides
should be changed. I firmly believe that an exchange format should
just contain the data it is meant to contain according to an
externally given specification of its format. If you include the
format definition into the data file, you create non-standard,
non-compatible data formats, in particular if extensions are also
allowed. I would strongly recommend to take the profile definition out
of DFXP and instead include just a reference to an externally given
profile definition - similar to how XML instance documents reference
their schema in an external XML schema file.

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

* 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 16:26:35 UTC