DFXP LC Comments - Issues 3, 4, 8 Responses; John Birch

Dear John,

Thank you for your comments, [1] through [3], on the DFXP Last Call Working Draft. The TT WG has concluded its review of your comments and has agreed upon the following responses.

If you require any further follow-up, then please do so no later than September 1, and please forward your follow-up to <public-tt@w3.org>.

Regards,
Glenn Adams
Chair, Timed Text Working Group

************************************************************************

Citations:

[1] http://lists.w3.org/Archives/Public/public-tt/2005Mar/0004.html
[2] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0015.html
[3] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0012.html

************************************************************************

Comment - Issue #3 [1]; 16 Mar 2005 17:50:49 +0100

I have some problems with the current support for background colour in
DXFP.  The attached files indicate three common modes of using
background colours.

Given the current attributes tts:displayAlign and tts:showBackground I
cannot see a way to trivially implement these effects in DXFP without
creating a large number of regions.

Can consideration be given to enhancing the tts:showBackground
attribute to support the following attribute values?

content - The background attributes are only applied to the part of
the region that has content. I.e. there is only a background behind
characters of displayed text but not behind white-space characters
(e.g. line 21 boxed captions with transparent space).

content-space - The background attributes are only applied to the part
of the region that has content and also to white-space within the
content. I.e.  there is background behind characters of displayed text
and behind white-space characters. If no white-space character exists
at the end of each line, the background is extended to cover the area
of a single space character at the end of each line. (UK boxed style)

active-line - The background attributes are applied to the lines of
the region that have content. The background extends the full width of
the **region** for any line that has content within the region.

active-stripe - The background attributes are applied to the lines of
the region that have content. The background extends the full width of
the display.

active-bounds - The background attributes are applied to the bounding
box of all content within the region, providing the region has some
content. 

active-region - The background attributes are applied to the entire
region providing the region has some content. 

stripe - The background attributes are applied to the entire region
regardless of if the region has some content.. The background extends
the full display width.

region - The background attributes are applied to the entire region
regardless of if the region has some content. (E.g. this might be used
for censorship).

Response:

A combination of use of explicit <span>s around whitespace as
well as the use of non-standard style property attributes in a non-TT
namespace are sufficient to satisfy this proposal. 

Further consideration may be given to developing these concepts as a
TT Style Extension property, possibly defined in an additional REC
track document or a Working Group Note. 

Note that the functionality described in the comment is probably a new
requirement. 

Note also that some of the proposed uses appear to be covered by
existing DFXP mechanisms, e.g., the examples in Doctor_Box_Mode.doc
appear to be supportable by means of using <span
tts:backgroundColor="black"/> with a transparent background on region,
body, div, and p. 

We also note that Doctor_Strip_Mode.doc appears to be identical to
Doctor_Box_Mode.doc (we don't see any difference).

************************************************************************

Comment - Issue #4 [2]; 4 Apr 2005 12:34:54 +0100

OK, I'll try and frame what I see as the style problem....

The DFXP style model is quite suitable for the carriage of styled
text, BUT, in the contexts of accessibilty and transcoding, the DFXP
style mechanism IMO lacks an essential ingredient, that being the
reason for (or context of) the applied style.

As an example - an author may choose yellow text on a red background
for a warning message.

The carriage of that text as simply text characters and colour codes
loses one piece of information - the fact that it was intended as a
warning.

This missing information becomes important when interchanging content
between formats that have different support for style (for example
between a colour and monochromatic presentation), or in transcoding /
translating content between cultural groups.

Another example - Green is 'lucky' in Ireland, but Red is 'lucky' in
China.  Go n'éirí an t-ádh leat could translate to ??? (Note: Internet
machine translation!).  You have stated that it is possible (likely)
that this style tagging (context) will be a feature of AFXP and that
DFXP is a format intended as "a solution that addressed the more
pressing and less complex need of interchange among a small number of
legacy distribbution formats,specifically SAMI, QuickText, RealText,
3GPP TT, CEA-608/708, and WST." 

It should be noted that CEA-608/708, and WST (and in fact TV
subtitling formats in general) are typically not stored in these wire
formats by broadcasters, rather these wire distribution formats are
created in real-time by insertion equipment working from proprietary
file formats. A single common file format already exists as a ratified
interchange standard, EBU 3264. DFXP could replace the use of EBU 3264
- it offers a few of advantages, a) it is Unicode, b) it is XML and c)
it has a more comprehensive language tagging mechanism. However, DFXP
does not offer any significant new features over EBU 3264, and indeed
there are features in EBU3264 that are not present in DFXP (e.g.
cumulative mode and boxing).  A combination of extension elements and
attributes and constrained document structuring (via a sub-profile)
can probably be used with DFXP to fully represent EBU 3264 document
contents - and other general TV broadcast related subtitling issues.
Indeed, it is anticipated that the use of DFXP as an interchange
mechanism for TV broadcast subtitling will require the development of
guidelines for the interpretation of DFXP documents by transcoders. In
addition it will probably require the development of a profile to add
elements and attributes to DFXP to carry information and features
currently supported by existing formats, (e.g. conditional content,
cumulative modes, background styles, embedded glyphs, subtitles as
images (DVD, DVB, Imitext)).

The pressing need is not IMO for another interchange format per se,
rather it is for a format that preserves more of the authorial intent
(inc.  understanding / meaning) such that implementing transcoding,
translation and accessibility are made easier tasks than they are
currently. My main concerns are that using DFXP will encourage the
continuation of the existing practice of 'cooked text content' - that
is text that has lost contextual meaning - and that AFXP will be too
complex and too late for most implementations.

Is there a middle path for DFXP that would encourage a more context
sensitive (and accessible) role for text style? DFXP already includes
a referenced style mechanism - could that mechanism be strengthened to
provide greater support for contextual styling of text?

Response:

An author may use a combination of ttm:role, ttm:agent, as well as
user-defined metadata attributes or elements, e.g., placing them in a
child of the content, in order to express "the reason for (or context
of) the applied style." 

For example, see example in
http://lists.w3.org/Archives/Public/public-tt/2005Apr/0021.html.

************************************************************************

Comment - Issue #8 [3]; 3 Apr 2005 11:36:56 +0100

If we allow for extrinsic timing where such a time may not
be resolved yet, then there are use cases where it is
necessary to express both dur and end.  For instance:
"Display this text for 20 seconds unless the extrinsic-
event-based end time resolves before that time, in which
case end when it resolves".

Is this mix of extrinsic and intrinsic timing actually supported
within DFXP. I thought that the discontinuous attribute applied to the
entire document (I see discontinuous as synonymous with media marker
modality)?

Further, I find it a strange balance of features in that DFXP allows
such a sophisticated timing model when it only supports a relatively
simplistic styling model. 

Note: I do not have any real issue with the inclusion of the ttp
parameters for timing model, except that they increase the complexity
of a **fully conformant** (non SMIL based) user agent fairly
dramatically. I am currently assuming that since DFXP deliberately
avoids talking about UAs, that an implementation must clarify what
aspects of DFXP timing model it supports. I feel this puts DFXP in an
awkward position as a universal distribution format - since
originators of content may use features of the timing model that are
not supported by transcoders or UAs. So my position is that a simpler
timimng model would be more likely to be universally adopted, further
sophistication of the type in your example could IMO be handled by any
'container' format e.g. SMIL, and is unneccesary within a 'media
track' format (which is how I view DFXP).

Response:

The TT WG is considering the possibility of rewriting 10.4 to directly
specify semantics of time interval computation, which would include
definitions of use of begin, dur, and end, including semantics for
usage in the context of discontinuous marker mode with smpte time
base. We expect to permit dur attribute to be expressed as a nominal
media time while interpreting begin and end as marker (event) based
times.

************************************************************************

Received on Friday, 12 August 2005 19:39:15 UTC