W3C home > Mailing lists > Public > public-tt@w3.org > June 2009

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 29 Jun 2009 10:35:50 +1000
Message-ID: <2c0e02830906281735n8656b1ds1b5b86d8dc308b74@mail.gmail.com>
To: Glenn Adams <gadams@xfsi.com>
Cc: Philippe Le Hegaret <plh@w3.org>, public-tt@w3.org
On Mon, Jun 29, 2009 at 8:42 AM, Glenn Adams<gadams@xfsi.com> wrote:
> 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...

I agree it's not always possible. However, I have found that it makes
sense in technical specifications as in every other specification to
have "facts" that are referred to in a section be defined beforehand,
unless this would result in a circular dependency, which in the case
of the attribute definitions is not the case. I'm actually making
concrete and fairly simple to implement suggestions above on how to
improve readability.

I have a fairly simple approach to structuring specifications and it
doesn't need a full guide: just keep the specification dependency tree
simple and as linear as possible. Do not use things that have not been
specified beforehand, or if you absolutely have to, include a forward
reference. However, the structure should be made such that the need
for forward references is minimal.

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

In this case I would indeed not suggest to re-order the sections, but
to include a forward reference.

>> * 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 understand the motivation and agree with your 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.
> [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.

Perhaps I misunderstood the profile element, but section 5.2 seems to
indicate to me that in a profile element I can include all the
features that are available from DFXP and further extension and define
which should be allowed or not in the same file later on. This for me
means I can define the format of my data file without adhering to
defined profiles and cause the creation of files that a standard DFXP
parser will not be able to understand. It is therefore not a mechanism
to improve interoperability, but rather a mechanism to allow people to
define their own formats that they can only use within their closed
systems and that nobody else understands. Such a mechanism is fine to
have, but I would prefer it would be done not within the data file,
but rather by reference to an external specification file.

I just checked on SVG and the root element indeed has an attribute
called "baseProfile" which is essentially a link to an externally
specified profile. This makes sense and is indeed the way in which it
should be specified.

As for SMIL, the situation is indeed similar and SMIL profiles are
specified in external DTDs or XML schemas, see

So both of the examples that you cite do not allow in-line
specification of a profile, but rely on an external specification. It
is this in-line specification possibility that I criticized. And while
I understand that DFXP wants to have all the data inside the file and
not make use of e.g. external style document, the document definition
(i.e. the profile) is a different case and should be separated out
from the data document.

Please correct me if I mis-understood the profile element and let me
know how it is supposed to be used.

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

Requirements for elements and attributes in DFXP should not be
explained through their requirement in other standards, since their
aims are different. So,  In fact, in SMIL, the "dur" element provides
a time limit for a element where the duration is not specified,
because the element is dynamic, e.g. in a repetition loop. Such
dynamic is (fortunately) not possible for DFXP. Therefore, I think the
"dur" attribute is a left-over from old times of excessive flexibility
and can be removed in the current spec.

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

OK, so IIUC these attributes are necessary for rendering, at the exact
moment where the media file that the DFXP file is associated with, is
displayed together with the DFXP timed text. Further, it is my
understanding that DFXP is supposed to describe a on-screen
presentation that is independent of the actual format of the video
file. Thus, the video-file specific information (frameRate, tickRate,
pixelAspectRatio etc) is information that will be extracted from the
video file. In DFXP we specify layout in square pixels and seconds.
Thus, the mapping from DFXP to display on top of the video will happen
in the processor for rendering based on this information coming out of
the video file. I therefore do not understand the need to have this
information inside the DFXP file, which would also explain why there
are no test cases in the test suite for these attributes. Would you
mind clarifying where my logic has gone wrong?

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

This is a misunderstanding. I have no issue with the span element's
existence - I completely agree it is necessary.

What I do not understand and ask clarification on is the definition of
an anonymous, implied span element shadowing every p element. I simply
don't understand the need for such an element, when the font style,
font size, font family, background color, foreground color, text
decoration, text outline for everything inside p can easily be defined
through the p element. Is this a construct that has just been invented
to make it easier for DFXP parsers to deal with p and span? Pardon my
ignorance, but I just don't seem to be able to put the pieces together
on this one.

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

Sorry, but I have read the requirements document at
http://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/ and cannot see
mention of the particular metadata items chosen. In fact,
http://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/#metadata says that
"R601 The TT AF shall be capable of expressing the following
constituents of individual metadata items: name, value type, value".
This is exactly what I am proposing with name-value pairs and would
extend http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090602/#requirements
to make it fully satisfy R601.

> We also firmly decided to adopt a specific set of metadata items in
> the DFXP vocabulary domain
> itselfratherthandelegatingittocompletearbitrariness,whichiswhatyoupropose.

I can see a certain sense in this, since the HTML <meta> element has
indeed had problems with it's complete free-form capabilities. I agree
with most of the elements that were chosen as specific elements. But
"actor" in particular is taking it a bit far IMHO. I would prefer to
remove that and introduce an extra element that allows free-form
metadata, thus satisfying R601.


I guess that's one way to make Dublin Core work with DFXP. Could this
be added as an example to the draft? This would probably satisfy R690
 Dublin Core Preference out of
http://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/#metadata and
further extend the coverage of
http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090602/#requirements to
cover R690.

Thanks very much for taking the time to give me feedback!

Best Regards,
Received on Monday, 29 June 2009 00:36:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:04 UTC