Re: new issue? dfxp and language selection

John said:
> The fact that it doesn't comply with the intention of DFXP perhaps
> illustrates a divergence between the requirements of the 'real world'
> and our spec?

and Sean said earlier:

> In earlier discussions I believe we came to the conclusion that for
> multi lingual scenarios, it would be better to have separate files for
> each language.


What John says fairly sums up why we implemented xml:lang the way we  
did:  we thought it would be more effective, from an authoring and  
file-tracking or maintenance standpoint, to keep all the languages in  
a single file.  Essentially ccPlayer looks at the file and, if it sees  
xml:lang, takes the language identifier and plugs it into a menu in  
the player.  Everything is in one place.

Note that I am not against the use of separate files for each  
language.  However, this isn't something we'll be able to support in  
ccPlayer in the near future.


> But I don't see it as an issue for xml:lang... Surely it's an issue  
> for
> 'our' definition of the meaning of div.
> The question as I see it is... Is it meaningful to select on the basis
> of div elements (as in CCForFLASH) or conversely....
> Is it 'meaningful' / useful to use multiple div elements in a DFXP
> document with the presumption that they all display simultaneously.

The latter statement also applies to ccPlayer, since we don't support  
multiple regions.  We therefore found it useful to use multiple divs  
for multiple *languages.*

g.


On Dec 3, 2008, at 12:32 PM, John Birch wrote:

>
> I personally find the cc player implementation to be quite
> appropriate... It's lightweight and effective.
> The fact that it doesn't comply with the intention of DFXP perhaps
> illustrates a divergence between the requirements of the 'real world'
> and our spec?
>
> It is a fact (clearly demonstrated by the CCforFlash implementation  
> and
> indeed by real world multimedia e.g. Digital TV broadcasts in Europe),
> that multiple languages are required to be supported by the media. Two
> points appear valid here... A) DFXP was originally targetted at
> authoring...And in that context a predominant single language is by  
> far
> the most common and B) I recall discussion that for multi-language
> support it was suggested that the external container would index
> multiple DFXP documents as necessary. I don't recall such guidance in
> our spec however (admittedly I haven't checked)...and clearly the
> implementors of CCForFLASH took a different view :-)
>
> However, given that this and other? implementations appear to be using
> DFXP for both authoring and transmission, I suggest that it would be
> valid to examine how easily the spec could be adjusted to accommodate
> both the authoring and transmission scenarios...
>
> But I don't see it as an issue for xml:lang... Surely it's an issue  
> for
> 'our' definition of the meaning of div.
> The question as I see it is... Is it meaningful to select on the basis
> of div elements (as in CCForFLASH) or conversely....
> Is it 'meaningful' / useful to use multiple div elements in a DFXP
> document with the presumption that they all display simultaneously.
>
>
> 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: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On
> Behalf Of Sean Hayes
> Sent: 03 December 2008 16:58
> To: Philippe Le Hegaret; public-tt@w3.org
> Subject: RE: new issue? dfxp and language selection
>
>
> In earlier discussions I believe we came to the conclusion that for
> multi lingual scenarios, it would be better to have separate files for
> each language. The xml:lang usage on elements was to clarify the use
> where one was momentarily switching languages, e.g. in a quotation,  
> but
> where it was part of the same discourse.
>
> I think in fact the ccPlayer behaviour fails to adhere to the  
> processing
> specified by section 9.3, which does not specify tree pruning based on
> language, and thus is not acting in accordance with the spec which  
> would
> require simultaneous presentation of all three languages.
>
> We can certainly clarify this in the definition of the xml:lang
> attribute, but I believe we should track this as an implementation  
> error
> by ccPlayer.
>
> Sean Hayes
> Media Accessibility Strategist
> Accessibility Business Unit
> Microsoft
>
> Office:  +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On
> Behalf Of Philippe Le Hegaret
> Sent: 03 December 2008 15:54
> To: public-tt@w3.org
> Subject: new issue? dfxp and language selection
>
>
> I noticed that the ccPlayer is able to handle multiple languages in  
> the
> same document:
>
> <body>
>  <div xml:lang='en'>..</div>
>  <div xml:lang='ja'>..</div>
>  <div xml:lang='fr'>..</div>
>  ...
> </body>
>
> You can then select which language to display using the interface.
>
> It's allowed by the specification but nothing there says that you can
> display only one language.
>
> Do we need to say to say anything in the spec about such usage?
>
> Philippe
>
>
>
>
>
>
>
> 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 Wednesday, 3 December 2008 18:15:10 UTC