W3C home > Mailing lists > Public > public-tt@w3.org > December 2008

RE: new issue? dfxp and language selection

From: John Birch <john.birch@screen.subtitling.com>
Date: Thu, 4 Dec 2008 15:07:25 -0000
Message-ID: <4476B296B92A4741A49B0BD017590700AA75BD@sss-uk-ex-02.screen.subtitling.local>
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 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

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 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
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.


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

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:03 UTC