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

Hi Glenn, all,

On Mon, Jun 29, 2009 at 12:18 PM, Glenn Adams<gadams@xfsi.com> wrote:
> On Mon, Jun 29, 2009 at 8:35 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>
>> 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.
>
> [GA] No, this is not the intention, nor is that what is described in the
> prose. I think you are reading into the prose such a restriction on what may
> be allowed in the document, since the use of the profile mechanism does not
> place any restriction on what is in the document. Rather it places a
> restriction on the behavior of a conforming processor. In particular, a
> conforming process must abort processing the document if it does not support
> a required feature or extension. The first paragraph of 6.1.1 makes this
> clear. The only mandate on the author (and document) is found in 5.2 after
> the second note, in the paragraph starting with "If a TT AF document
> instance...".

OK, so these are just parsing hints to a processor? That of course
changes the situation. I apologize for the misunderstanding.

So, then the next question is where do you specify which profile your
document is using? In particular if you're using not one of the three
given profiles, but want to specify one of your own? SVG has the
"baseProfile" attribute for it and SMIL references external DTDs or
XML schemas. Do we have something similar for DFXP?


>> >> * 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?
>
> [GA] Indeed, it is as you say, because we want to ensure that authorial
> intentions hold in the absence of a potentially related media file (video,
> audio, etc.). It is precisely in the absence of the related media that these
> information are necessary. We do not require that DFXP content be specified
> in seconds. It may specify all times in frames or ticks, so we need this
> information when we want to render it independently of a related media file.

So, these are processing instructions for the text display, i.e. how
to interpret temporal and spatial coordinates given for the timed text
which are given in entities that can only be resolved by providing
such video-specific parameters. Complicated, but interesting, I guess.
I hope not many such files will ever exist, to be honest. :-)


>> >> * 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.
>
> [GA] I'm not sure what you mean by "an anonymous span shadowing every p
> element". In fact, anonymous spans are only used to wrap #PCDATA that is not
> in a span.
> <p>A<span>B</span>C</p>
> would effectively map to
> <p><span xml:id="anonymous1">A</span><span>B</span><span
> xml:id="anonymous2">C</span></p>
> This interpretation is effectively needed to correctly interpret style
> application to inline content as well as interpret the formatting semantics
> of DFXP as it relates to XSL FO semantics. See 9.3.3 (8) [3].
> [3] http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090602/#semantics-region-layout-step-2

Yes, it is this set of anonymous spans that is auto-created inside p
elements that I was referring to. I think my issue is that I am so
used to cascading style sheets that I find it difficult to think of a
situation where styles are not inherited down the DOM tree. I'm
finding it hard to follow the flow transformation process and I think
it's because of this process that you needed to come up with the
anonymous span.


>> >> * 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.
>
> [GA] I'm afraid I glossed over a bit of history as well as a lengthy
> discussion and comment resolution process regarding metadata that occurred
> during the earlier last calls of DFXP in 2005-2006. The following references
> apply, however, some of these are member only access:
> [4] http://www.w3.org/2005/03/21/DFXPLastCallResponses.html#Issue7
> [5] http://www.w3.org/2005/03/21/DFXPLastCallResponses.html#Issue9
> [6] http://www.w3.org/2005/03/21/DFXPLastCallResponses.html#Issue11 (see
> comments SYMM-12-1 and SYMM-12-2)
> As I have already stated, DFXP already allows you to express arbitrary
> metadata, so nothing is needed for that. At the same time, the TTWG has
> consistently  insisted on including certain metadata in the DFXP vocabulary,
> as currently expressed.
> If you have specific issues with the current metadata items, then I suggest
> you take up those issues.

I find it interesting that I have repeated arguments previously made
by so many other groups and people. I would honestly suggest to add
the example of how to reference the whole Dublin Core namespace and
provide a set of Dublin Core elements in metadata rather than the
given metadata elements. It will clarify the situation for many
people.


Thanks for your patience in addressing my list of issues.

Best Regards,
Silvia.

Received on Monday, 29 June 2009 06:29:56 UTC