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

Inline below.

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

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

[GA] I will add a forward reference as a hyperlink or note.

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


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



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


[GA] You have to be careful with what you mean by "standard DFXP parser".
First one has to distinguish between parsing, and semantic processing. All
compliant DFXP processors must be able to parse a syntactically valid DFXP
document containing all or any defined syntactic element. This is a logical
consequence of 3.2.1 (1). However, beyond parsing the document, a DFXP
processor that claims compliance must indicate (somewhere) which TTAF
profiles it supports. There are three specific profiles defined in DFXP:

   - dfxp-transformation
   - dfxp-presentation
   - dfxp-full

In the case of the first two of these profiles, about which see Appendix G
for definition, semantic support is not required for many (most) features.
For example, the definition of the dfxp-presentation profile does not
mandate support for tts:fontStyle (or indeed, for any style property).
Therefore, if, as an author, you find that you are satisfied with the basic
semantic support of the dfxp-presentation profile, but you also insist it
supports tts:fontStyle='italic', then you may include a profile element
specifying this as follows:

<ttp:profile use="dfxp-presentation">
<ttp:features xml:base="http://www.w3.org/2006/10/ttaf1/feature">
<ttp:feature>#fontStyle-italic</ttp:feature>
</ttp:features>
</ttp:profile>

this information is a statement from the author to the processor saying that

(1) the processor must support the dfxp-presentation profile; and
(2) the processor must support the #fontStyle-italic feature.

Note well, however, that this information *does not* say whether the
document actually uses tts:fontStyle='italic'. It may or it may not, as that
has no consequence on the semantics of the use of ttp:profile.



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

[GA] Again, I disagree that this constitutes defining different document
formats. It does not. It does, rather, allow an author to be specific about
what must be supported in a conforming processor, rather than take an *unknown
risk* that the processor does not support some non-mandatory feature.
Furthermore, it is essential that this information be embedded in the
document to have the intended use. In fact, this information must be
processed before attempting to support semantic processing on the rest of
the document.


> 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
>
> http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-scalabilityFramework.html#smilScalabilityNS-BasicDoc
> .
>

[GA] The equivalent feature in SVG [1] is the requiredFeatures and
requiredExtensions attributes, which indeed allows inline specification of
mandatory features and extensions that must be supported. We document the
derivation of the similar DFXP vocabulary from the SVG vocabulary in DFXP in
Table K-1 [2].

[1]
http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#ConditionalProcessing
[2]
http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090602/#element-vocab-derivation-table


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

[GA] See the above correction.


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

[GA] Think about what you just said. There is no W3C specification that does
not normatively include other, external normative specifications.
Furthermore, I respectively disagree that dur should be removed, or that it
should only be thought of in terms of its use in SMIL. The TTWG believes the
syntax and semantics of begin, end, and dur are syntactically and
semantically consistent with SMIL, albeit a subset thereof. That subset is a
natural consequence of subsetting the value space of these attributes and
not supporting other SMIL attributes, such as endSync, repeat, etc., whose
default values apply when interpreting SMIL semantics.

If you can make a convincing statement that dur is not well defined, then
our response would be to improve it to ensure it is well defined, and not
remove it. But I think you cannot make such a statement, since the same
statement would naturally apply to SMIL as well.


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



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



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


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


[GA] Free form metadata is already supported. The ttm:actor element is a
very simple mechanism to associate ostensibly fictional agents with
ostensibly non-fictional
agents. If you are not satisfied with it, then you are free to augment
it in anyway you see fit as long as you use a foreign namespace.


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


[GA] The last example in 12.1.1 shows use of a foreign namespace
attribute. I suppose we could also add to this example the use of a
foreign namespace element as well.