- From: geoff freed <geoff_freed@wgbh.org>
- Date: Wed, 3 Dec 2008 15:43:09 -0500
- To: John Birch <john.birch@screen.subtitling.com>, public-tt@w3.org
- Cc: Sean Hayes <Sean.Hayes@microsoft.com>, Philippe Le Hegaret <plh@w3.org>
- Message-Id: <588EE1DA-29D4-4FB2-9293-D5C0DA9ECD50@wgbh.org>
i agree with john, especially that the xml:lang behavior of ccplayer can't be changed right now. i also agree that changing xml:lang in dfxp wanders from our charter, but if other disagree i won't fight this point. g. ec 3, 2008, at 2:24 PM, John Birch wrote: > Hmmm! > Arguably in the CCforFlash interpretation the switch is on the div > based on the value of the xml:lang attribute... I don't think it > would be easy to get the cc4flash usage changed so perhaps we should > bend? Some informative text in the spec might be sufficient? > > Agree about multiple divs... Seems both interpretations of div use > might be valid... > > John > > Sent by Blackberry > > ----- Original Message ----- > From: Sean Hayes <Sean.Hayes@microsoft.com> > To: John Birch; Philippe Le Hegaret <plh@w3.org>; public-tt@w3.org <public-tt@w3.org > > > Sent: Wed Dec 03 17:44:35 2008 > Subject: RE: new issue? dfxp and language selection > > It's an interesting point. I believe the spec as currently written > does not allow for the ccplayer interpretation. We could certainly > adjust it so that it did, but I'd rather not do it based on xml:lang > at this point for a couple of reasons: > > 1) it takes us a bit far from our current charter. > 2) it would be a very specific fix, and I'd rather handle this in a > more generic way using conditional styling when and if we get round > to addressing applicative style. > > It is certainly meaningful and useful to have multiple divs in a > single document for different purposes, and one could possibly even > construct a mechanism which would allow different languages to flow > into different regions, and have the user select which was visible > based on some kind of user stylesheet processing; but it would have > to be done as some form of extension, and not violate the normative > parts of the specification. > > Sean Hayes > Media Accessibility Strategist > Accessibility Business Unit > Microsoft > > Office: +44 118 909 5867, > Mobile: +44 7875 091385 > > John Birch | Screen Subtitling Systems Ltd | Strategic Partnerships > Manager > Main Line : +44 (0)1473 831700 | Ext : 270 | Direct Dial : +44 > (0)1473 834532 > 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,Suffolk,IP6 > 0EQ,United Kingdom > > See us at Broadcast Video Expo – February 17th – 19th 2009, Earls > Court 2, London, Stand number K56 > > P Before printing, think about the environment > > > > > -----Original Message----- > From: John Birch [mailto:john.birch@screen.subtitling.com] > Sent: 03 December 2008 17:32 > To: Sean Hayes; Philippe Le Hegaret; public-tt@w3.org > Subject: RE: new issue? dfxp and language selection > > 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 > > > 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 20:44:06 UTC