- From: Sean Hayes <Sean.Hayes@microsoft.com>
- Date: Sun, 7 Dec 2008 12:22:20 +0000
- To: Public TTWG List <public-tt@w3.org>
Sorry, regarding 1) and 2) I didn't run the example through a validator before I sent it, so some of the errors were propagated. Apologies for that; they are however not germane to this discussion. Regarding 3), (which is not a validity error); On closer inspection I agree that the example would not work as written, however it should work with the insertion of display='inherit' on body, as display can be made an inheritable property (as in CSS) - even if this is not its normal behaviour; so the thrust of the argument remains. Having said that, I see no specific reason why display could not apply to region, as it would be semantically equivalent to a region which was not temporally active. I don't recall any discussion on why display should not apply to region and on reflection I find it a little odd that it does not. Sean Hayes Media Accessibility Strategist Accessibility Business Unit Microsoft Office: +44 118 909 5867, Mobile: +44 7875 091385 -----Original Message----- From: Glenn A. Adams [mailto:gadams@xfsi.com] Sent: 07 December 2008 00:32 To: Sean Hayes; John Birch; Daniel Weck Cc: Public TTWG List Subject: Re: new issue? dfxp and language selection 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/>; 2) there is no ttm:title attribute defined in DFXP (as used below on the <div/> elements); 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; [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 12:24:04 UTC