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

Dear John,
If you require any further follow-up please do so, and if you are 
satisfied with the TTWG response, please acknowledge it by replying to 
this mail and copying the TTWG public mailing list:
public-tt@w3.org
Regards,
Thierry Michel

Glenn A. Adams a écrit :

>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 22:32:12 UTC