Re: new issue? dfxp and language selection

Hi Glenn,

On Sun, Dec 7, 2008 at 11:32 AM, Glenn A. Adams <gadams@xfsi.com> wrote:
>
>
> There are a few problems with the following example which make it
> non-conformant to DFXP.
>
> 1) <style/> must be an immediate descendant of either <styling/> or
> <region/>, and not <head/>;

Good to note, but I don't think this has an effect on the main point
of the example, or does it?


> 2) there is no ttm:title attribute defined in DFXP  (as used below on the
> <div/> elements);

Again, I don't think this has an effect  on the main point of the example.


> 3) tts:display is not inheritable, therefore, region style inheritance does
> not apply (note that tts:display applies only to body, div, p, and span, and
> does not apply to region); instead of tts:display, tts:visibility would be
> used, which does apply to region;

Is tts:visibility then inheritable? I.e. as the region is turned
invisible, does the text that is meant to appear in that region also
disappear?


Silvia.

>
> [N.B. I see there is a typo in the table in DFXP CR1 8.2.23, where two
> 'Animatable' entries are present and no 'Inheried' entry is present; please
> record this as an issue]
>
> G.
>
> On 12/5/08 8:05 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
>
>> If we wish to target content at different audiences, in my mind the best
>> vehicle DFXP has for that is the region element, regions can be switched on
>> and off by tts:display. The application of a user stylesheet to do such
>> switching seems in keeping with accepted HTML usage. On the subject of HTML,
>> very rarely do I see a multilingual site attempt to combine the languages in
>> one page, that would be a nightmare to maintain. If we are thinking of
>> embedding DFXP in HTML, I see no reason why separate files would not be
>> appropriate.
>>
>> Note that John's example below is incorrect in a number of ways; a more
>> correct example is given below which uses no new features beyond DFXP, uses
>> xml:lang solely to indicate natural language and achieves what I believe he is
>> attempting. Moreover this approach would be more readily able to capture the
>> typical typographical approaches used in the various territories.
>>
>> I don't have ccPlayer to hand, but based on the description I have heard, my
>> expectation is that this example should actually work in that player too, as
>> they ignore regions, and display depending on xml:lang however I would not
>> wish to encourage such non standard behaviour.
>>
>> <tt
>>     xml:lang =""
>>     ttp:profile="http://www.w3.org/2006/10/ttaf1#profile-dfxp"
>>     xmlns="http://www.w3.org/2006/10/ttaf1"
>>     xmlns:ttm="http://www.w3.org/2006/10/ttaf1#metadata"
>>     xmlns:ttp="http://www.w3.org/2006/10/ttaf1#parameter"
>>     xmlns:tts="http://www.w3.org/2006/10/ttaf1#style" >
>>     <head>
>>         <ttm:title>Multi lingual example</ttm:title>
>>         <metadata>
>>             <ttm:desc>
>>             This file contains four complete language examples.
>>             users would  filter appropriately by switching on the relevant
>> region.
>>             Sound effects can be switched independantly of language.
>>             </ttm:desc>
>>         </metadata>
>>         <style id="s1">...</style>
>>         <style id="s2">...</style>
>>         <layout>
>>             <region xml:id="soundEffect"
>>               tts:display="none"
>>                style="s2"
>>             />
>>             <region xml:id="frenchLanguageSubtitles"
>>              tts:display="none"
>>               style="s1"
>>             />
>>             <region xml:id="englishLanguageSubtitles"
>>              tts:display="none"
>>                style="s1"
>>              />
>>             <region xml:id="americanLanguageSubtitles"
>>             tts:display="none"
>>               style="s1"
>>              />
>>             <region xml:id="québécquoisLanguageSubtitles"
>>              tts:display="none"
>>                style="s1"
>>              />
>>         </layout>
>>     </head>
>>     <body timeContainer ="par" >
>>         <div timeContainer="seq" xml:lang ="fr-fr"
>> region="frenchLanguageSubtitles" ttm:title="Titre en français">
>>                 <p ttm:role="sound"  region="soundEffect"
>> dur="1s">FANFARE!</p>
>>                 <p dur="1s">Ce texte est en français.</p>
>>         </div>
>>         <div timeContainer="seq" xml:lang ="fr-ca"
>> region="québécquoisLanguageSubtitles"  ttm:title="Titre en québécquois">
>>                 <p ttm:role="sound"  region="soundEffect"
>> dur="1s">FANFARE!</p>
>>                 <p dur="1s">Ce texte est en québécquois.</p>
>>          </div>
>>         <div timeContainer ="seq" xml:lang ="en-uk"
>> region="englishLanguageSubtitles"  ttm:title="Title in English">
>>                 <p ttm:role="sound" region="soundEffect" dur="1s">TYRE
>> SCREECH!</p>
>>                 <p dur="1s">Quick! Put the body in the boot!</p>
>>         </div>
>>         <div timeContainer ="seq" xml:lang ="en-us"
>> region="americanLanguageSubtitles"  ttm:title="Title in English">
>>                 <p ttm:role="sound" region="soundEffect" dur="1s">TYRE
>> SCREECH!</p>
>>                 <p dur="1s">Quick! Put the body in the trunk!</p>
>>         </div>
>>     </body>
>> </tt>
>>
>> Sean Hayes
>> Media Accessibility Strategist
>> Accessibility Business Unit
>> Microsoft
>>
>> Office:  +44 118 909 5867,
>> Mobile: +44 7875 091385
>>
>>
>> -----Original Message-----
>> From: John Birch [mailto:john.birch@screen.subtitling.com]
>> Sent: 04 December 2008 16:46
>> To: Daniel Weck
>> Cc: Sean Hayes; Glenn A. Adams; Public TTWG List
>> Subject: RE: new issue? dfxp and language selection
>>
>> It's a good explanation, but I fear I'm not quite getting my point across.
>>
>> Two selection scenarios are common in subtitling.
>>
>> A) target audience language selection. Probably at a level immediately below
>> body level between multiple 'functionally equivalent' yet language
>> differentiated divs.
>> B) Removal of inline content because of user preference. For example, in a
>> movie with hard-of-hearing subtitles, a user may wish to turn off the
>> subtitles pertaining to sound effects, but retain those relating to speech.
>> Note: this can be done with current spec using ttm:role attribute.
>>
>> I agree that DFXP should include a marker that makes an explicit statement
>> about intent.
>> E.g. This content is intended for french speakers.
>> Or perhaps go further... E.g. This content is intended for french speakers who
>> are also deaf (although this can be finessed using the role attribute).
>>
>> I agree with Sean that I think that the same type of selection that might be
>> achieved by language matching and switch constructs can be achieved by
>> processing - PROVIDED that sufficient markup exists in the document to
>> identify content with sufficient granularity.
>>
>> So my suggestion would be
>>
>>    <sequence ttm:lang="fr" title="Titre en français">
>>      <p ttm:role="sound">FANFARE!</p>
>>      <p>Ce texte est en français.</p>
>>      <p ttm:lang="fr-CA">Ce texte est en québécquois.</p>
>>    </sequence>
>>
>>    <sequence ttm:lang="en" title="Title in English">
>>      <p ttm:role="sound">TYRE SCREECH!</p>
>>      <p>Quick! Put the body in the boot!</p>
>>      <p ttm:lang="en-US">Quick! Put the body in the trunk!</p>
>>    </sequence>
>>
>> BUT what is interesting here is that the two text strings (excluding the sound
>> effect representation) ARE equivalents.
>> What is certain is that BOTH should NOT be displayed. Perhaps some form of
>> alt. markup is required :-)
>>
>> BTW Of course I'm assuming fr = fr-fr and en = en-en :-)
>>
>> Best regards,
>>
>> John
>>
>>
>> John Birch | Screen Subtitling Systems Ltd | Strategic Partnerships Manager
>> Main Line : +44 (0)1473 831700 | Ext : 270 | Office :
>> Mobile: +44 (0)7919 558380 | Fax: +44 (0)1473 830078
>> john.birch@screen.subtitling.com | www.screen.subtitling.com
>> The Old Rectory, Claydon Curch Lane, Claydon,Ipswich,IP6 0EQ,United Kingdom
>>
>>
>> See us at Broadcast Video Expo - February 17th - 19th 2009, Earls Court 2,
>> London, Stand number K56
>>
>>
>> Before Printing, think about the environment
>>
>> -----Original Message-----
>> From: Daniel Weck [mailto:daniel.weck@gmail.com]
>> Sent: 04 December 2008 16:09
>> To: John Birch
>> Cc: Hayes Sean; Glenn A. Adams; Public TTWG List
>> Subject: Re: new issue? dfxp and language selection
>>
>>
>> On 4 Dec 2008, at 15:07, John Birch wrote:
>>> JB>> Generic XML can be processed using internal content and external
>>> criteria. I personally view switches as being a way of pre-coding
>>> common processing operations - but I view it as ~dangerous~ to only
>>> allow those pre-coded choices to be made in order to remain
>>> 'conformant'.
>>
>> I see what you mean: you see it as some kind of "anti-pattern", in reference
>> to software development :)
>>
>> Now, let's consider this fictitious, yet relevant sample:
>>
>> <text xml:lang="en">
>>    <sequence xml:lang="fr" title="Titre en français">
>>      <p>Texte en français.</p>
>>      <p xml:lang="fr-CA">Texte en québécquois.</p>
>>      <p xml:lang="en-GB">Text in British English.</p>
>>    </sequence>
>>    <p>Text in (unspecified) English.</p> </text>
>>
>> If "xml:lang" was to be processed by user-agents as a content selection
>> criteria, there would be a number of issues:
>>
>> 1) Clearly, content selection wasn't the original intent of the author. It is
>> obvious that here, the "xml:lang" attributes decorate the elements to merely
>> indicate the locale of the content. With the above XML snippet, XPath and the
>> lang() function can be used, for example, pre-process (e.g. XSLT transform) or
>> to dynamically alter the content (e.g. "highlight any English text in bright
>> yellow"). This kind of processing made by the user-agent seems perfectly
>> reasonable.
>> On the other hand, my instinctive subjective assumption is that content
>> pruning is not the desired goal. To remove this ambiguity, the TT/DFXP
>> distribution format for captions should provide more than just a hint, it
>> should clearly specify the intent (IMHO). This would promote re-using content
>> across multiple processors.
>>
>> 2) The "xml:lang" attribute applies to an entire XML fragment, until it is
>> overridden. In a content selection scenario, this nesting ability prompts a
>> number of questions. For example, what happens if the user-agent locale is set
>> to "fr": should the top-level "text"
>> element be totally ignored/pruned, or should the "sequence" be processed and
>> the following "p" ignored ? My personal systematic / scientific mind is in
>> favor of the former, but I know authors who would "feel" that the latter is
>> right.
>>
>> 3) What about more complex selection criteria ? Let's say that I want to mark
>> a piece of text as "suitable for all flavors of French expect
>> Canadian": using a (fictitious) 'matchLanguage' attribute, I could write
>> matchLanguage="fr AND NOT fr-CA". Note: the coma-separated values in the SMIL
>> systemLanguage attribute represent a OR boolean logic, so there are
>> limitations in the selection model.
>>
>> 4) What about a fallback logic, so that if no suitable language is matched,
>> then a specific XML fragment is enabled ? In SMIL, the 'switch' offers this
>> mechanism, which enriches the default selection model based on the combinatory
>> attribute value.
>>
>> I feel that a proper "content control" mechanism would address these concerns.
>> Otherwise, I am not convinced that TT/DFXP will sufficiently eliminate
>> ambiguities that user-agent implementors and content authors (or developers of
>> production tools) will face, and I would recommend to clearly state that
>> xml:lang is not designed for content selection, and that to be reflected in
>> user-agent conformance guidelines.
>>
>>> JB>> If we did not have existent implementations then I would be
>>> proposing two language attributes. One to allow a language specific
>>> instance of a DFXP document (i.e. the true xml:lang sense) and another
>>> - perhaps ttm:lang, to define the language used in sections of the
>>> document.
>>
>> The "xml:lang" attribute from XML 1.0 and 1.1 can do both scenarios you
>> mention. "xml:lang" is not meant to be limited to the document instance as far
>> as I know. The "lang" versus "xml:lang" mess has been fixed in XHTML 1.1 IIRC,
>> isn't that a good trend to follow ?
>>
>> Regards, Dan
>>
>>
>> This message may contain confidential and/or privileged information. If you
>> are not the intended recipient you must not use, copy, disclose or take any
>> action based on this message or any information herein. If you have received
>> this message in error, please advise the sender immediately by reply e-mail
>> and delete this message. Thank you for your cooperation. Screen Subtitling
>> Systems Ltd. Registered in England No. 2596832. Registered Office: The Old
>> Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
>>
>
>
>

Received on Sunday, 7 December 2008 08:51:19 UTC