Re: Alternate syntax for required features.

As a non SMPTE member and xml neophyte I don't wish to take a view :-)

However as an interested party from the point of view of generating (and perhaps parsing) dfxp, what 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 ??

I know that a larger degree of rigidity on the structure of minimal dfxp files would be welcomed by the tv subtitling community from discussions I have had with other parties who lurk... The current dfxp specification allows a wide degree of variation in the structure of dfxp files, all valid and creating similar or identical end results from a rendered perspective, but the variations that are possible is off-putting to those seeking to use dfxp as an interchange standard (for example to replace EBU TR 3264).

With respect,
John

Sent by Blackberry

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 Church Lane, Claydon,Ipswich,IP6 0EQ,United Kingdom


See us at NAB 2009, Las Vegas, 20th - 23rd April, Hall S4 Stand SU 10009


Before Printing, think about the environment

----- Original Message -----
From: public-tt-request@w3.org <public-tt-request@w3.org>
To: Sean Hayes <Sean.Hayes@microsoft.com>; Public TTWG List <public-tt@w3.org>
Sent: Thu Apr 16 04:36:19 2009
Subject: Re: Alternate syntax for required features.


While some aspects of the proposal are worth considering, I have to oppose the element based proposal as it is outlined in the example in [1] at the current time. The main problem with the proposed formulation is that it necessitates formally defining a global attribute (in ttf: namespace) for every feature. This means we will have to add definitions, with prose text, xml syntax, and schema entries, for 123 attributes plus the 3 new proposed element types (profile, features, extensions). This will also require tests for each of these attributes. This would require a LOT of effort on the part of the editor to accomplish this work, as well as on the group to develop tests and verify these normative additions to the
DFXP language.

The current approach (based on requiredFeatures and requiredExtensions attributes) is already well founded in existing SMIL and SVG practices, etc., and supports conditional inclusion at a finer grained, which we could easily add in the future by permitting these attributes to be used on arbitrary DFXP elements.

Glenn

[1] http://lists.w3.org/Archives/Public/public-tt/2009Mar/0008.html


On 4/15/09 5:08 AM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:



 I expect the meeting to be short (unless we see the new WD today or tomorrow). 
  
 The main decision point on the agenda is the features syntax. If you don’t intend to join the meeting please indicate on the list your preference with respect to:
 a)     The attribute value proposal
 
 b)      My element based proposal
 
 c)      Something else.
 
 d)     Don’t care.
 



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