DFXP 1.0 Last Call issues

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

Section 7.1.1 tt, first sentence
-> remove surplus comma

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

Section 6.2.8 ttp:smpteMode
-> no example of use

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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

From Silvia Pfeiffer.

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.

From Silvia Pfeiffer.

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.

From Silvia Pfeiffer.

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.

From Silvia Pfeiffer.

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.

From Silvia Pfeiffer.

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.

From Silvia Pfeiffer.

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.

From Silvia Pfeiffer.

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.

From Silvia Pfeiffer.

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.

From Silvia Pfeiffer.

Why is the backgroundColor called "transparent", when the region attribute is called "opacity" - why not choose the same word?

From Silvia Pfeiffer.

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.

From Werner Bailer (Media Annotation Working Group)

You might want to consider renaming "desc" to "description", as (i) it is the only abbreviated name and (ii) then all elements that map nicely to ma elements would have the same names in both vocabularies.

From Gur Shlapobersky

Should the TT Full profile assume support for ruby annotation?