Re: Alternate syntax for required features.

The TTWG now operates as a public WG, so all of our discourse and editorial
work is public. However, the editor¹s draft is not publicly published as a
W3C document yet. Nevertheless, it is there for you to review.

I trust you will review the links I provided below before coming to any
conclusion about the complexity of DFXP. If you still think it is overly
complex, particularly in the minimum required support, then be so kind as to
point out the specific features and aspects of those features that make it
so.

Regards, Glenn

On 4/18/09 12:27 AM, "John Birch" <john.birch@screen.subtitling.com> wrote:

> Thanks Glen,
>  
> I wasn't aware that the editors draft was 'public' yet, (in the past I have
> been unable to access the draft copies because I / Screen are not W3C members
> :-(
> I'll take a look at this after NAB...
>  
> In general my main concern is that DFXP is very complex... I feel that it
> currently will be seen as a big step up to move from EBU TR3264 to DFXP...
> My concern is that the apparent complexity will inhibit the adoption of DFXP
> by TV broadcasters (for traditional TV broadcasting).
> That would be a tremendous shame considering the efforts that have been put
> into it so far...
>  
> It's a difficult road to tread, since clearly creating an easy transition path
> will preclude the opportunity for commercial organisations to profit from
> assisting in any migration.
> However, my personal view is that there is and will never be a clear demand
> for a migration (merely a need / opportunity? that is unrecognised by most
> broadcasters!), so the commercial driver will not actually exist anyway.
>  
> That's the drive behind my desire for a clear definition / example set for
> lightweight DFXP.
>  
> best regards,
>  
> John
>  
> 
> From: Glenn A. Adams [mailto:gadams@xfsi.com]
> Sent: 16 April 2009 08:06
> To: John Birch; Sean.Hayes@microsoft.com; Public TTWG List
> Subject: Re: Alternate syntax for required features.
> 
> here are the relevant links:
> 
> http://dev.w3.org/2008/tt/spec/ttaf1-dfxp.html#features
> http://dev.w3.org/2008/tt/spec/ttaf1-dfxp.html#feature-transformation-mandator
> y-table
> http://dev.w3.org/2008/tt/spec/ttaf1-dfxp.html#feature-presentation-mandatory-
> table
> 
> On 4/16/09 2:46 PM, "Glenn Adams" <gadams@xfsi.com> wrote:
> 
>> 
>> have  you read appendix E in the current  editor¹s draft? especially tables
>> E-2 and E-3? this material has been  available for review since Jan 30... but
>> you may be behind in your  reading...
>> 
>> On 4/16/09 2:07 PM, "John Birch" <john.birch@screen.subtitling.com>  wrote:
>> 
>>  
>>> I personally would like to see is some example use  of the profile mechanism
>>> **within** the current specification. Is it  possible to create a minimal
>>> set of dfxp features (perhaps that closely  match the ccforflash
>>> implementation for example) that could be 'termed'  dfxp-lite and to declare
>>> that within the spec ??
>>> 
>>> With  respect,
>>> John
>> 
> 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
> <http://www.screen.subtitling.com>
> The Old Rectory, Claydon Church Lane, Claydon,Ipswich,Suffolk,IP6 0EQ,United
> Kingdom
> 
> See us at NAB 2009, Las Vegas, 20th - 23rd April, Hall S4 Stand SU 10009
> 
> P Before printing, think about the environment
> 
> 
> 
> 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
>