- From: John Birch <john.birch@screen.subtitling.com>
- Date: Thu, 4 Dec 2008 15:07:25 -0000
- To: "Daniel Weck" <daniel.weck@gmail.com>
- Cc: "Hayes Sean" <Sean.Hayes@microsoft.com>, "Glenn A. Adams" <gadams@xfsi.com>, "Public TTWG List" <public-tt@w3.org>
Some comments inline :-) 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 13:47 To: John Birch Cc: Hayes Sean; Glenn A. Adams; Public TTWG List Subject: Re: new issue? dfxp and language selection Hello TT group, On 4 Dec 2008, at 13:10, John Birch wrote: > For me the semantic of xml:lang in our specification is only ever > informative about the element content - not the document content. It > is an attribute value on which a processor might make a selection, in > the same way that an xml document representing a database of addresses > might be processed by a processor that uses an attribute value to > 'select' only addresses in a specific geographic region... > The choice of which specific attribute instances should be used for a > processing decision is up to the processing - not the document > structure designers. I disagree. The problem in the analogy you are making is that database of addresses does not exhibit any behavior: in this case XML is merely used as a storage mechanism using a well-defined encoding method (i.e. the database schema). JB>> - And DFXP will be used in exactly this manner too. The presentational aspects of DFXP are interesting, but non essential to many fundamental applications of DFXP. For me it's Timed Text. Not Timed Styled Text. TimedText DFXP, like SMIL, exposes presentational and behavioral semantics for which the processing conformance has to be clearly defined. In a distribution format, if the intent is to perform content selection (e.g. based on the xml:lang attribute), then this has to be clearly specified. In an authoring format (e.g. AFXP), I would be more inclined to allow various kinds of processing (i.e. application- specific behaviours). JB>> I need content selection in DFXP. I need content selection at the user agent. It is not, in many cases, possible to determine user preferences at authoring time and impractical to create multiple document instances for each of any variations that can be envisaged. Further, in many scenarios there is no back channel through which a user could make a preference choice to the author (or server). In SMIL, the ContentControl module provides the "switch" element to enable user-agents to perform content selection (pruning data either on-the-fly or during pre-processing stage), but the selection/test attributes can also be used inline, without the "switch" container. This selection behavior is specified for a well-defined set of test attributes, because the intent has to be extremely clear to user-agent implementors. 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'. http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-content.html#ContentCo ntrolNS-InlineTestAttributes I think that xml:lang in TT/DFXP should not be used for content selection, but merely to indicate the content language as per the XML 1.1 recommendation. Content selection introduces complex issues such as the logical combinations of the selection criteria (e.g. [en-US OR en-GB] versus [en-US]), for which SMIL has a limited solution based on coma-separated values: 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. But given that we have implementations, and given that I favour multi-language distribution formats (as opposed to the complexities of multiple files for each language and out-of-band selection), I disagree. http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-content.html#adef-syst emLanguage Food for thoughts. JB>> Indeed :-) Kind regards, Daniel. 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 Thursday, 4 December 2008 15:08:09 UTC