Re: TT telecon - agenda for 12 Dec

Hi Glen,

So would the use of foreign namespaces match that defined in section 23 of the svg document? I particularly like the descriptive text in section 23.1? And the example... The comment about the reasons for allowing this feature are particularly relevant to me (private data). Can we include similar text and examples in the dfxp spec?

I'm quite happy with the example you posted (below) using requiredFeatures and requiredExtensions... From reading the svg spec I didn't get the impression this was possible (to me it seemed that requiredExtensions was only used with the switch element.)

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 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: Glenn A. Adams <gadams@xfsi.com>
To: John Birch; Sean Hayes <Sean.Hayes@microsoft.com>; David Kirby <david.kirby@rd.bbc.co.uk>; Public TTWG List <public-tt@w3.org>
Sent: Sat Dec 13 02:27:24 2008
Subject: Re: TT telecon - agenda for 12 Dec


First of all, foreign namespaces and private data are already permitted in DFXP. DFXP content compliance is defined in terms of a reduced infoset that represents an abstract document instance from which all foreign elements have been removed. See Section 4.

Second, it would be a bad idea to introduce a new attribute, requiredTransformation, which is specific only to a particular type of processing (extension), when the more general, already defined requiredExtensions attribute will do just fine. The value of this attribute is an IRI (URI), which names/identifies the extension.

In your first example below, you appear to be suggesting that transformation processing should occur and should transform from dfxp to teletext. This could be expressed as follows: 

<?xml version="1.0" encoding="utf-8"?>
<tt xml:lang="en"
    xmlns="http://www.w3.org/2006/10/ttaf1"
   requiredFeatures="http://www.w3.org/2006/10/ttaf1#feature-transform"
    requiredExtensions="http://acme.org/ttaf1#extension-dfxp-to-teletext">
...
</tt>

The first attribute, requiredFeatures, would be used to express that the author requires the receiver to possess those features which DFXP will label as appropriate for a transformation processor.

The second attribute, requiredExtensions, would be used to identify a (non-standard) extension that performs the specific type of transformation, which, in this case, would be defined by acme.org. If some organization, including the W3C, wished to standardize a specific extension, then its meaning could be shared more widely. However, anyone could publish a description of the semantics of an extension and post that in a public forum for use by authors and DFXP processor implementers.

If we, the TTWG, wish to identify a specific type of extension, say a “filter by language” extension, then we could define it in an annex and specify a standard IRI to identify it.

G.

On 12/13/08 12:25 AM, "John Birch" <john.birch@screen.subtitling.com> wrote:

> 
> I've just been looking at the SVG specification and the section on
> extensibility... (Section 23)
> I do like the fact that SVG allows extensions, but I'm not personally
> convinced it gives what I need. 
> 
> [I would support inclusion of Foreign namespaces and private data in
> DFXP. (23.1)]
> [I don't think that supporting foreignObjects ( or Adding private
> elements and attributes to the DTD is necessary. (23.2 - 23.5)]
> 
> Certainly the requiresExtension attribute does not match what I had in
> mind :-)
> 
> With apologies to those that read (and write) fluent xml... 
> What I'm thinking about is something along the lines of a
> requiredTransformation attribute on the tt element...
> 
> <?xml version="1.0" encoding="utf-8"?>
> <tt xml:lang="en"
>     xmlns="http://www.w3.org/2006/10/ttaf1"
>     xmlns:tts="http://www.w3.org/2006/10/ttaf1#style"
>     xmlns:ttm="http://www.w3.org/2006/10/ttaf1#metadata"
>     requiredTransformation = "x-SSS_DFXPtoTeletext>
> 
>   <head....
>   </head>
> 
>   <body ....
>   </body>
> </tt>
> 
> 
> For CCforFlash - all that I can see that would be necessary to be
> conformant and allow the current CCforFlash behaviour would be ...
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <tt xml:lang="en" xmlns="http://www.w3.org/2006/04/ttaf1"
> xmlns:tts="http://www.w3.org/2006/04/ttaf1#styling"
>     requiredTransformation = "x-DFXPCCForFlash>
>   <head>
>         <styling>
>             <style id="b1" tts:color="#cccc00"/>
>        </styling>
>   </head>
>  
>   <body>
>     <div xml:lang="en" style="b1">
>             <p begin="00:01.7" end="00:05.0">Narrator:  Someone watching
> a car<br/>accelerate toward light speed</p>
> ...
>    </div>
>     <div xml:lang="es" style="b1">
>             <p begin="00:01.7" end="00:05.0">Narrador:  Si se observara
> a un auto<br/>acelerando a la velocidad de la luz</p>
> ...
>     </div>
>     <div xml:lang="de" style="b1">
>             <p begin="00:01.7" end="00:03.4">Sprecher:<br/>Wer ein Auto
> beobachtet</p>
> ...
>     </div>
>   </body>
> </tt>
> 
> Absence of a requiredTransformation attribute would of course imply the
> behaviour defined by the specification, 
> 
> Regards,
> 
> 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: 12 December 2008 13:42
> To: David Kirby; public-tt@w3.org
> Subject: TT telecon - agenda for 12 Dec
> 
> 
> Here is an agenda for today. Basically this is finishing the agenda from
> last week.
> We need to make a decision on dynamicFlow, so that is the first topic
> 
> I've also included a section to record the other issues that have arisen
> this week, but don't expect we shall get to all of them.
> 
> This is the last WG meeting till the new year, but that doesn't mean no
> TT work, we will be compiling a survey of all the outstanding issues,
> which will be open until Jan 5. I'll then collate the results and we
> will discuss them on our next scheduled meeting on Jan 9.
> 
> Agenda
> 
> 1) dynamicFlow
> 
> 2) timeContainer and default value for <body>
> 
> 3) extent to move (back) to tt element?
> 
> 4) qualify 9.3.2 (7) to map anonymous spans to fo:inline only when their
> parent is p or span
> 
> 5) dealing with inherit for anonymous spans:
> "For the purpose of determining applicability of this style property,
> each character child of a p element is considered to be enclosed in an
> anonymous span where the value of this style property is set to
> 'inherit'".
> 
> 6) Adopting a smaller set of the real number line for opacity.
> <simpleType name='alpha'>
>   <restriction base='decimal'>
>     <totalDigits value='4'/>
>     <fractionDigits value='3'/>
>     <minInclusive value='0'/>
>     <maxInclusive value='1'/>
>   </restriction>
> </simpleType>
> 
> 7) Enhancing presentation of computed style set for content elements
> 
> 8) Marking additional processing requirements with a requiredExtensions
> attribute.
> 
> 9) supporting tts:display on region
> 
> 10) modifying lineHeight to accommodate nested spans
> 
> 11) tts:padding
> 
> 12) Content Hierarchy Region Mapping example code typo
> 
> 13) region attribute not specified and default region
> 
> 14) disallowing style as a child of region
> 
> xx) AOB
> 
> 
> 
> 
> 
> 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