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

Hi Sylvia. Thanks for your efforts on helping improve DFXP, and I'm sure the
TTWG will take all your comments seriously. In the mean time, I have some
personal (not group authorized) responses to the individual issues you note
below.
Regards,
Glenn

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

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

[GA] Unfortunately, it is often the nature of technical specifications that
they cannot be effectively read in a linear fashion while avoiding all
future references. Over the years, I have become accustomed to the necessity
to read specifications multiple times in order to obtain a full
understanding. Keep in mind that it is expressly not the purpose of a
technical specification to be a user's guide or an author's guide. While
there is information present in the specification to help elucidate such
issues, it is not intended to be complete or ordered in a fashion to
function as an effective guide. Perhaps you might go on to write and publish
such a guide...


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

[GA] See my content above.


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

[GA] Support for external style sheets and external time sheets were
included in AFXP, an authoring profile we were developing in the early work
of the TT WG. We ruled out these features in DFXP which has a requirement to
not require resolution of any externally referenced resources. If the TT WG
continues its work in the future and an need exists, then perhaps we can go
on to write an AFXP specification, in which I would support your suggestion.


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

[GA] I think you may be mistaken about the purpose of the profile data. It
is not specifying "the format definition in[to] the data file", rather it is
giving the author a means to specify what the author requires to be
processed by a recipient processor. Since the core profiles and core
compliance of DFXP do not mandate support for all defined features (just
like CSS,  HTML, etc.), this mechanism provides the means for the author to
preclude processing on a processor that doesn't support certain features (or
extensions) felt by the author to be necessary. This type of mechanism is
not being introduced (into the W3C) here, but is already found in SVG and
SMIL language specifications. We think that this mechanism plays an
important and essential role in improving interoperability.


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

[GA] As you can see under the definitions of these attributes, their
semantics come from SMIL. So to find answers to your questions (about why
three and not two) and what happens in contradictions, you need to see the
referenced SMIL specifications. Again, a user or authors guide might
elaborate this more inline, but in a technical specification it is often
sufficient to normatively cite a reference.


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

[GA] Again these are there to permit the author to specify important (and
essential) semantic information needed to interpret the contents of a
document as the author intends. For example, frameRate, subFrameRate, and
frameRateMultiplier are necessary to interpret the 'f' (frame) time unit,
while tickRate is necessary to interpret the 't' (tick) time unit. Since
most of the style geometries are specified in pixels, it is also important
to know the pixelAspectRatio to properly convert between display formats.
Note that in the case of NTSC and PAL and some other raster formats that
this ratio is not 1:1, therefore, if one is presenting on a display format
that uses a different pixel aspect ratio than the author intended, the
processor can use this information to convert pixel units specified in the
document to pixels in the target display.


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

In the absence of span, how would you change the font style, font size, font
family, background color, foreground color, text decoration, text outline,
etc., of a specific word or phrase in a paragraph? I can assure you it is
absolutely necessary to have span. Furthermore, it corresponds directly with
the XSL FO fo:inline element which is important in making use of XSL FO
formatting semantics.


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

[GA]  In this case, I agree it would be better to move the text "The root
container origin..." of 8.2.15 up to 7.1.1 where the tts:extent attribute is
discussed.


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


[GA] "transparent" is a specific color value, rgb(0,0,0,0), defined in
8.3.112, while "opacity" is a designation of the alpha channel of a color
tuple; they denote different things.


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


[GA] I agree regarding its restricitivity, but not regarding arbitrariness.
These specific metadata items came out of a lengthy requirements and review
process. We also firmly decided to adopt a specific set of metadata items *in
the DFXP vocabulary domain itself*
 rather than delegating it to complete arbitrariness, which is what
you propose. If you wish to define your own metadata, then you are
free to do that already, e.g., by wrapping it in the <tt:metadata/>
element, or by including metadata from a foreign (but declared)
namespace (either as attributes or elements).