TTWG minutes October 10, 2008

[geoff freed]

Timed-text working group minutes October 10, 2008

ATTENDING:
Sean Hayes (SH)
David Kirby (DK)
Andrew Kirkpatrick (AK)
Philippe le Hegaret (PH)
Glenn Adams:  (GA)
Geoff Freed (GF, scribe)
John Birch (JB)

REGRETS:
Dick Bulterman (DB)
Frans de Jong (FJ)


Telecon time:
new time is 10:00/Eastern Friday, 3:00/UK

(ed:  see important note at end of minutes)

ACTION: philippe will set up the bridge for new time

SH: Adobe is now a member of the group; still working on AOL.

SH:  implementation sheet:
Andrew has submitted Adobe's implementation.
AK:  General goal of this working group is to get version 1 of DFXP  
finished, yes?  What are details concerning cutting features or  
adding features?

SH:  No specific discussion about what would be changed yet.  Trying  
to determine current implementations and what people want for final  
version.  Need to get 2LC out in January.  Not going to be many  
changes with short timeline.  Main job is to ensure reasonably good  
coverage of features; then see if features can be removed if not  
covered.  Nobody has implemented dynamicFlow; must figure out what to  
do with it.  Currently at risk.  May be changing conformance  
requirements, however.

GF:  The only thing we're chartered to change is dynamicFlow;  
everything else is either keep or cut.

GA:  New charter doesn't rule out any additions, but adding things  
might trigger new last calls and other steps.

PH:  Charter does rule out substantial additions.  If we add or make  
substantial changes, we must go back to another last call.

SH:  What does "substantial" mean?  Can we make small changes?

PH:  Yes, but not big changes.

GA:  Had considered some SVG/SMIL-like attributes to express optional  
features before processing.  This could be valuable and should be  
looked at.

SH:  Can discuss this later.

AK:  Back to implementation spreadsheet/Adobe.  We have a minimal  
implementation fo DFXP to display captions in current  
implementation.  Re comment on list that Adobe's implementation is  
not valid DFXP:   it accepts valid DFXP as well as invalid DFXP.  
regarding CNET and Library of Congress implementations:  those aren't  
implementations, but they are using DFXP within Flash movie to  
display captions.  They use the Adobe component, not their own.  
There are others, like Subtitle Horse, Captionate, Hicaption, others  
that are more true implementations.  MAGpie implementation is the  
same as Adobe implementation except it has language support.

GF:  Will submit NCAM's chart next week.

GA:  Is there a spreadsheet online?

SH:  Not yet; just in e-mail and will be in member archives.  Will  
forward Andrew's version to member list.

AK:  Critical to support begin, end, dur for timing and will verify  
that Adobe can/cannot support it.

DK:  Will need info, contact details about new implementations.

AK:  Will talk to Automaticsync and Captionate and confirm details.  
Subtitle Horse... will look into their implementation.  Will  
investigate their implementation.  These tools target people who do  
Flash video, so they are probably targeting the Adobe subset of DFXP.

DK:  Check to see if they would participate in testing, running the  
test suite, reporting results, etc.

AK:  What does running the test suite mean?

DK:  e.g., display subtitles that have already been generated.

GA:  Would be useful to take an output and review or run them on a  
presentation processor, but that might not be useful.  Must be able  
to test DFXP generators, however.

SH:  Must generate valid DFXP, make sure it doesn't violate timing/
structural constraints.  Will be difficult to test generators.  Will  
need to discuss requirements on generating tools.

AK:  Another implementation to test:  JW player, Flash-based media  
player that supports DFXP.  They support a number of captioning types  
but does not use Adobe's component.

GA:  Re generation tools:  3.1 in spec would bear on any DFXP  
generator.  Should be a mechanism to discuss implementation or  
generators against 3.1.  Andrew's case of accepting non-valid DFXP  
would fail that test.

SH:  If non-valid DFXP is generated, it fails the test but what if a  
processor accepts it?  Is that an error?  It's the content-producer's  
problem if they generate invalid DFXP.

GA:  Some specs require processors to reject an invalid document.

SH:  HTML WG is moving that way.  We could say that the processor  
must reject invalid DFXP, or you can't claim conformance if you  
generate invalid DFXP.

GA:  Should document that and deal with in the future.

ACTION:  Everybody-- think about what happens regarding invalid DFXP  
from both generation and processing standpoints.

SH:  Geoff will upload NCAM's spreadsheet.  Sean still working on  
MSFT.  Can't get Subtitle Workshop to work.

DK:  Will try to get help.  Some people are using it, so it should work.

SH:  Will try using it again.

SH:  Where do we post spreadsheet?

DK:  I'll collate revisions and keep a master version to upload later.

ACTION:  David will keep and update master copy of spreadsheet.  Send  
all revisions to David.

PH:  Still working on test suite and will continue to do so.  
Checking on how comprehensively we've covered all features in the  
spreadsheet.  Will continue to do so.

SH:  At some point we must discuss how to populate the test  
database.  Still fairly small.

GA:  Over 50% of the features have tests, all content and style and  
most of timing have tests.  Missing TTP parameter set and metadata  
and <end>, timeContainer, textoutline, dynamicText and direction,  
etc.  Will create some additional tests for TTP and TTM and also  
placeholder test for unicodeBidi and dynamicText.

ACTION:  Glenn will create additional tests for items that currently  
have no implementations.

PH:  Let me refine my list first.

SH:  For example, how many tests do we need to prove that <color>  
actually works?  How can we determine how much to test each feature?

GA:  For those attributes that take on a set of token values, we've  
covered most of those.  Richer set of values will need bigger tests.

SH:  time value will need a lot more tests; other edge cases.

DK:  Is one test example sufficient?

SH:  For some; others not.  Must also consider feature combinations  
and interactions, which will need more tests.

DK:  What about high values in frames, will one example cover it?

SH:  May be sufficient.  Tried to express a time in many different  
ways as possible.  May have done 10 or 20 tests as an exercise already.

ACTION:  Sean will create a set of timing examples for the test suite.

SH:  Planning...  there's some movement from SMPTE caption group.  
Dick Bulterman has approached Sean about scheduling time for smilText  
discussion.  DB wants to discuss next week, if convenient.  after  
that, he's open.

ACTION:  Add smilText to agenda for 10/17.  Also 708 translation  
discussion on 10/17.

GA:  Mike Dolan would be a valuable contributor for 10/17 re 708  
discussion.

ACTION:  Sean will contact Mike Dolan to join 708 discussion next week.

PH:  Problem-- the +1 hour that we settled on earlier conflicts with  
the ISO text coordination group (?) teleconference time.  All WG  
chairs are supposed to attend that call every other week,

SH:  We must change our telecon time, then.

GA:  Could we change our telecon time every other week to accommodate?

GF:  How about we move to Thursday at 8:00am Eastern time?

GA:  How about 10:00am Eastern Thursday?

(general agreement)

SH:  New telecon time is now 10:00am/Eastern time 3:00/UK on  
Thursdays.  New telecon takes effect next week (October 16, 2008).

SH:  Would like to keep carrying forward discussion items from week  
to week but also discuss them on the list so they don't get lost.

(no objections).

SH:  Any other business?

(none)

end of call

**Note that the next call will be October 16 at 10:00am/eastern,  
3:00pm/UK, 7:00am/pacific.**

[Sean Hayes-2]

Timed-text working group minutes October 16, 2008

ATTENDING:
David Kirby (DK, chair)
Sean Hayes (SH, scribe)
Andrew Kirkpatrick (AK)
Philippe le Hegaret (PH)
Glenn Adams:  (GA)
Geoff Freed (GF)
John Birch (JB)
Dick Bulterman (DB)
Mike Dolan (MD)
Don Evans (DE)

REGRETS:
Frans de Jong (FJ)

PH: Apologies on mixup on call logisitics
ACTION PH to ensure call set up for next week.

DK: Action items

1 contact AOL - closed.
2 Philippe - matching test to feature sets. No more progress.
3 (item 10) NCAM details - closed
4 (item 11) Microsoft - no progress

Item 3: SMILText and streaming.

DB: Background

SmilText is based on dfxp with some name changes to avoid conflicts with other SMIL attributes. Has a realtext streaming structure, unlike SMIL timing.

Esseintially an XML version of realtext, where.
  All the layout is pulled.
  Design things to do style based on dfxp.
  Timing is based on time markers (tev), tev's are markers rather than containers..

Currently out for voting.
SMIL did some external consultations. NCAM and BBC.

Comments:

SH: timing model is different to SMIL. Not container based. Don't need to parse the whole file if using a SAX like model.

DB: Uses absolute and relative time markers. and rendering is based on what is currently loaded. Even if a tev is in a <p> or <div>. it is a purely additive model, with clear.

DB: Header information is fixed like it is in DFXP. Supports out of band styling, but no in stream styling. Canuse smil param elements as the out of band mechanism.

---

DB: Addresses 2 issues:
   realtext functionality with no IP encumberance.
   lightweight captioning formats to mirror support in SMIl and an external format.
   ensure a syntax support. and if we need to add things.

DB: Actions to TTWG - Mostly informative.

SH: There are things that can be expressed in dfxp which cannot be expressed in smilText, but, probably smilText could be expressed in DFXP.

SH: DFXP could use a SAX like model for streaming if constrain what is expressed.

GA: For full DFXP would require an INFOSet stream model

DB: Should study smil time sheets

SH: would be out of scope for DFXP, but we had a similar idea in AFXP.

DB: SMIL group express a willingness to work on it.


-------

708 discussion.

Out of time, but some agreement (SH, MD) that there are some things in 708 not in dfxp.

ACTION SH to circulate initial findings.


end of call

**Note that the next call will be October 23 at 10:00am/eastern,
3:00pm/UK, 7:00am/pacific.**

[Sean Hayes-2]

Initial things I spotted in 708 not in DFXP.

Window anchor points - no equivalent mechanism in DFXP but could possibly be faked by combination of region extent, origin, displayAlign and textAlign properties.

window fade in/out - dfxp has no intermediate animation, but could be approximated using set and opacity.

window wipes - dfxp has no intermediate animation, but could possibly be approximated using set and extent.

window borders - dfxp has no equivalent, but could possibly fake it with region background, padding and div background.

text subscript/superscript - dfxp has no equivalent. Could set font height in a span, but no way to accurately move baseline.

role tagging in 708 can be parameterised.


Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  [phone],
Mobile: [phone]


-----Original Message-----
From: public-tt-request@... [mailto:public-tt-request@...] On Behalf Of Sean Hayes
Sent: 20 October 2008 19:35
To: public-tt@...
Subject: TTWG minutes October 16, 2008



Timed-text working group minutes October 16, 2008

ATTENDING:
David Kirby (DK, chair)
Sean Hayes (SH, scribe)
Andrew Kirkpatrick (AK)
Philippe le Hegaret (PH)
Glenn Adams:  (GA)
Geoff Freed (GF)
John Birch (JB)
Dick Bulterman (DB)
Mike Dolan (MD)
Don Evans (DE)

REGRETS:
Frans de Jong (FJ)

PH: Apologies on mixup on call logisitics
ACTION PH to ensure call set up for next week.

DK: Action items

1 contact AOL - closed.
2 Philippe - matching test to feature sets. No more progress.
3 (item 10) NCAM details - closed
4 (item 11) Microsoft - no progress

Item 3: SMILText and streaming.

DB: Background

SmilText is based on dfxp with some name changes to avoid conflicts with other SMIL attributes. Has a realtext streaming structure, unlike SMIL timing.

Esseintially an XML version of realtext, where.
  All the layout is pulled.
  Design things to do style based on dfxp.
  Timing is based on time markers (tev), tev's are markers rather than containers..

Currently out for voting.
SMIL did some external consultations. NCAM and BBC.

Comments:

SH: timing model is different to SMIL. Not container based. Don't need to parse the whole file if using a SAX like model.

DB: Uses absolute and relative time markers. and rendering is based on what is currently loaded. Even if a tev is in a <p> or <div>. it is a purely additive model, with clear.

DB: Header information is fixed like it is in DFXP. Supports out of band styling, but no in stream styling. Canuse smil param elements as the out of band mechanism.

---

DB: Addresses 2 issues:
   realtext functionality with no IP encumberance.
   lightweight captioning formats to mirror support in SMIl and an external format.
   ensure a syntax support. and if we need to add things.

DB: Actions to TTWG - Mostly informative.

SH: There are things that can be expressed in dfxp which cannot be expressed in smilText, but, probably smilText could be expressed in DFXP.

SH: DFXP could use a SAX like model for streaming if constrain what is expressed.

GA: For full DFXP would require an INFOSet stream model

DB: Should study smil time sheets

SH: would be out of scope for DFXP, but we had a similar idea in AFXP.

DB: SMIL group express a willingness to work on it.


-------

708 discussion.

Out of time, but some agreement (SH, MD) that there are some things in 708 not in dfxp.

ACTION SH to circulate initial findings.


end of call

**Note that the next call will be October 23 at 10:00am/eastern,
3:00pm/UK, 7:00am/pacific.**

[awk]

DB: Header information is fixed like it is in DFXP. Supports out of band styling, but no in stream styling. Canuse smil param elements as the out of band mechanism.

Related to the discussion last week - what is the use case that we are trying to support where the caption or other text stream needs to change format?  I may be thinking too narrowly around captioning, but the case where captions are streaming it is all that the captioner can do to get the text of the captions into the stream, forget about modifying the style...  Are there current cases where this is needed?

Thanks,
AWK

[awk]

I'd be interested in knowing which of these 708 features are in regular use.  Perhaps your contact at Softel could tell us or maybe Brad at WGBH would know?

Do we have a general sense of the inverse - what is in DFXP that isn't in 708? I haven't had a chance to look into this yet...
AWK


Window anchor points - no equivalent mechanism in DFXP but could possibly be faked by combination of region extent, origin, displayAlign and textAlign properties.

window fade in/out - dfxp has no intermediate animation, but could be approximated using set and opacity.

window wipes - dfxp has no intermediate animation, but could possibly be approximated using set and extent.

window borders - dfxp has no equivalent, but could possibly fake it with region background, padding and div background.

text subscript/superscript - dfxp has no equivalent. Could set font height in a span, but no way to accurately move baseline.

role tagging in 708 can be parameterised.


Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  [phone],
Mobile: [phone]


-----Original Message-----
From: public-tt-request@... [mailto:public-tt-request@...] On Behalf Of Sean Hayes
Sent: 20 October 2008 19:35
To: public-tt@...
Subject: TTWG minutes October 16, 2008



Timed-text working group minutes October 16, 2008

ATTENDING:
David Kirby (DK, chair)
Sean Hayes (SH, scribe)
Andrew Kirkpatrick (AK)
Philippe le Hegaret (PH)
Glenn Adams:  (GA)
Geoff Freed (GF)
John Birch (JB)
Dick Bulterman (DB)
Mike Dolan (MD)
Don Evans (DE)

REGRETS:
Frans de Jong (FJ)

PH: Apologies on mixup on call logisitics
ACTION PH to ensure call set up for next week.

DK: Action items

1 contact AOL - closed.
2 Philippe - matching test to feature sets. No more progress.
3 (item 10) NCAM details - closed
4 (item 11) Microsoft - no progress

Item 3: SMILText and streaming.

DB: Background

SmilText is based on dfxp with some name changes to avoid conflicts with other SMIL attributes. Has a realtext streaming structure, unlike SMIL timing.

Esseintially an XML version of realtext, where.
  All the layout is pulled.
  Design things to do style based on dfxp.
  Timing is based on time markers (tev), tev's are markers rather than containers..

Currently out for voting.
SMIL did some external consultations. NCAM and BBC.

Comments:

SH: timing model is different to SMIL. Not container based. Don't need to parse the whole file if using a SAX like model.

DB: Uses absolute and relative time markers. and rendering is based on what is currently loaded. Even if a tev is in a <p> or <div>. it is a purely additive model, with clear.

DB: Header information is fixed like it is in DFXP. Supports out of band styling, but no in stream styling. Canuse smil param elements as the out of band mechanism.

---

DB: Addresses 2 issues:
   realtext functionality with no IP encumberance.
   lightweight captioning formats to mirror support in SMIl and an external format.
   ensure a syntax support. and if we need to add things.

DB: Actions to TTWG - Mostly informative.

SH: There are things that can be expressed in dfxp which cannot be expressed in smilText, but, probably smilText could be expressed in DFXP.

SH: DFXP could use a SAX like model for streaming if constrain what is expressed.

GA: For full DFXP would require an INFOSet stream model

DB: Should study smil time sheets

SH: would be out of scope for DFXP, but we had a similar idea in AFXP.

DB: SMIL group express a willingness to work on it.


-------

708 discussion.

Out of time, but some agreement (SH, MD) that there are some things in 708 not in dfxp.

ACTION SH to circulate initial findings.


end of call

**Note that the next call will be October 23 at 10:00am/eastern,
3:00pm/UK, 7:00am/pacific.**

[Glenn A. Adams]

One could adjust certain styles via simple XML element streaming without
resending header info. For example, <tt:p> and <tt:span> both take a variety
of style properties. I would imagine that foreground color, background
color, text alignment, and perhaps font style or weight would be the most
likely to be changed during the streaming process, since these
characteristics are sometimes used to indirectly reflect semantic
distinctions.

Glenn

On 10/21/08 10:06 AM, "Andrew Kirkpatrick" <akirkpat@...> wrote:

>
> DB: Header information is fixed like it is in DFXP. Supports out of band
> styling, but no in stream styling. Canuse smil param elements as the out of
> band mechanism.
>
> Related to the discussion last week - what is the use case that we are trying
> to support where the caption or other text stream needs to change format?  I
> may be thinking too narrowly around captioning, but the case where captions
> are streaming it is all that the captioner can do to get the text of the
> captions into the stream, forget about modifying the style...  Are there
> current cases where this is needed?
>
> Thanks,
> AWK
>

[awk]

Likely to be changed for...?  Do we have an example use case in mind?

Thanks,
AWK

Andrew Kirkpatrick

Senior Product Manager, Accessibility

Adobe Systems

akirkpat@...


-----Original Message-----
From: Glenn A. Adams [mailto:gadams@...]
Sent: Monday, October 20, 2008 10:33 PM
To: Andrew Kirkpatrick; Public TTWG List
Subject: Re: question re: streaming caption data format


One could adjust certain styles via simple XML element streaming without
resending header info. For example, <tt:p> and <tt:span> both take a variety
of style properties. I would imagine that foreground color, background
color, text alignment, and perhaps font style or weight would be the most
likely to be changed during the streaming process, since these
characteristics are sometimes used to indirectly reflect semantic
distinctions.

Glenn

On 10/21/08 10:06 AM, "Andrew Kirkpatrick" <akirkpat@...> wrote:

>
> DB: Header information is fixed like it is in DFXP. Supports out of band
> styling, but no in stream styling. Canuse smil param elements as the out of
> band mechanism.
>
> Related to the discussion last week - what is the use case that we are trying
> to support where the caption or other text stream needs to change format?  I
> may be thinking too narrowly around captioning, but the case where captions
> are streaming it is all that the captioner can do to get the text of the
> captions into the stream, forget about modifying the style...  Are there
> current cases where this is needed?
>
> Thanks,
> AWK
>

[John Birch-2]

Andrew,

If by captioning you are referring to US 608 and 708 captions for the
hard of hearing then I would agree.
In the UK, Europe and other global locations :-) subtitles (translation)
often uses colour changes to indicate a change of speaker.
Italics are frequently used to distinguish off screen narration from on
screen speakers, or music lyrics from spoken words.

While these effects are more commonly used for pre-coded subtitles, they
are used for true live subtitling too.
BTW by live subtitling, I mean subtitles generated without a priori
knowledge of the dialogue in real time.
In live subtitling, there can be no pre-transmission of styles, sinc3
there is no knowledge of what styles may be used... Although it is
feasible that all the potential combinations could be collected in the
header on the chance that they might be used during the performance...
However, this strikes me as somewhat in-elegant :-)

Of course, pre-coded subtitles might be used for the playout of a video
stream and be transmitted in a streaming manner, where for whatever
reason the downloading of the entire subtitle stream at the commencement
of clip playback is undesirable (e.g. when wishing to play from the
middle of a larger asset).

Regards,

John

John Birch | Screen Subtitling Systems Ltd | Strategic Partnerships Manager
Main Line : [phone] | Ext : 270 | Office :  
Mobile: [phone] | Fax: [phone]
john.birch@... | www.screen.subtitling.com
The Old Rectory, Claydon Curch Lane, Claydon,Ipswich,IP6 0EQ,United Kingdom


See us at Languages and The Media, 29th - 31st October, Hotel Intercontinental Berlin


Before Printing, think about the environment

-----Original Message-----
From: public-tt-request@... [mailto:public-tt-request@...] On
Behalf Of Andrew Kirkpatrick
Sent: 21 October 2008 03:06
To: public-tt@...
Subject: question re: streaming caption data format


DB: Header information is fixed like it is in DFXP. Supports out of band
styling, but no in stream styling. Canuse smil param elements as the out
of band mechanism.

Related to the discussion last week - what is the use case that we are
trying to support where the caption or other text stream needs to change
format?  I may be thinking too narrowly around captioning, but the case
where captions are streaming it is all that the captioner can do to get
the text of the captions into the stream, forget about modifying the
style...  Are there current cases where this is needed?

Thanks,
AWK



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

[Sean Hayes-2]

It seems to me that from an authoring point of view, especially live, being able to pre-design combinations; and then have these triggered by role/agent changes would be a convenient and flexible solution. I could imagine in a future specification, (and we have discussed this before in the context of AFXP), being able to have <style> elements which support some kind of media query, or a CSS like applicative style mechanism, to have style be conditional on attribute values.

NB region cannot hold a metadata attributes; and there is no role element (probably a mistake IMO).

However that is for the future. The actual scenario being discussed here is not so much changing the layout, but rather where the viewer breaks into a stream partway through and hasn't acquired the layout block. This doesn't really happen today in on-demand scenarios on the web, whether true streaming, or just download and play, as the bi-directional protocols allow you to get the caption data out of band or on demand; but is more likely to start happening in true multi-cast and IPTV type scenarios. For this the ability to periodically resend the <layout> block would be convenient. I personally don't think this is something we have to solve in DFXP 1.0 though, and it seems to me largely a lower level protocol and tooling issue.

In terms of compatibility with US captioning, 708 allows for only 8 region definitions at any one time, but does have the capability to destroy and create them on the fly thus has potentially a very large set of combinations over time. Thus DFXP, in order to capture/recreate a long complex 708 sequence, may end up needing a lot of region definitions. But again I think this is more theoretical than reflecting reality, in practice I expect a fairly small set of design combinations get used.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  [phone],
Mobile: [phone]


-----Original Message-----
From: public-tt-request@... [mailto:public-tt-request@...] On Behalf Of John Birch
Sent: 21 October 2008 09:29
To: Andrew Kirkpatrick; public-tt@...
Subject: RE: question re: streaming caption data format


Andrew,

If by captioning you are referring to US 608 and 708 captions for the
hard of hearing then I would agree.
In the UK, Europe and other global locations :-) subtitles (translation)
often uses colour changes to indicate a change of speaker.
Italics are frequently used to distinguish off screen narration from on
screen speakers, or music lyrics from spoken words.

While these effects are more commonly used for pre-coded subtitles, they
are used for true live subtitling too.
BTW by live subtitling, I mean subtitles generated without a priori
knowledge of the dialogue in real time.
In live subtitling, there can be no pre-transmission of styles, sinc3
there is no knowledge of what styles may be used... Although it is
feasible that all the potential combinations could be collected in the
header on the chance that they might be used during the performance...
However, this strikes me as somewhat in-elegant :-)

Of course, pre-coded subtitles might be used for the playout of a video
stream and be transmitted in a streaming manner, where for whatever
reason the downloading of the entire subtitle stream at the commencement
of clip playback is undesirable (e.g. when wishing to play from the
middle of a larger asset).

Regards,

John

John Birch | Screen Subtitling Systems Ltd | Strategic Partnerships Manager
Main Line : [phone] | Ext : 270 | Office :
Mobile: [phone] | Fax: [phone]
john.birch@... | www.screen.subtitling.com
The Old Rectory, Claydon Curch Lane, Claydon,Ipswich,IP6 0EQ,United Kingdom


See us at Languages and The Media, 29th - 31st October, Hotel Intercontinental Berlin


Before Printing, think about the environment

-----Original Message-----
From: public-tt-request@... [mailto:public-tt-request@...] On
Behalf Of Andrew Kirkpatrick
Sent: 21 October 2008 03:06
To: public-tt@...
Subject: question re: streaming caption data format


DB: Header information is fixed like it is in DFXP. Supports out of band
styling, but no in stream styling. Canuse smil param elements as the out
of band mechanism.

Related to the discussion last week - what is the use case that we are
trying to support where the caption or other text stream needs to change
format?  I may be thinking too narrowly around captioning, but the case
where captions are streaming it is all that the captioner can do to get
the text of the captions into the stream, forget about modifying the
style...  Are there current cases where this is needed?

Thanks,
AWK



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

[Glenn A. Adams]

The design criteria for supporting the metadata attributes (ttm:role,
ttm:agent), was that the element supporting the attribute was a content
element; that is, role/agent applied to content itself independent of
styling. Although, since we do apply styles to region, then perhaps it would
be good to explicitly extend this design to cover region as well.


On 10/21/08 5:24 PM, "Sean Hayes" <Sean.Hayes@...> wrote:

> NB region cannot hold a metadata attributes; and there is no role element
> (probably a mistake IMO).

[Sean Hayes-2]

I think it would be helpful if we the spec had some usage examples and clarified the intended semantics for the <agent> element and the role, actor and agent attributes.
Then we could see whether it made sense for regions to support these attributes.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  [phone],
Mobile: [phone]


-----Original Message-----
From: Glenn A. Adams [mailto:gadams@...]
Sent: 22 October 2008 01:16
To: Sean Hayes; Public TTWG List
Subject: Re: question re: streaming caption data format


The design criteria for supporting the metadata attributes (ttm:role,
ttm:agent), was that the element supporting the attribute was a content
element; that is, role/agent applied to content itself independent of
styling. Although, since we do apply styles to region, then perhaps it would
be good to explicitly extend this design to cover region as well.


On 10/21/08 5:24 PM, "Sean Hayes" <Sean.Hayes@...> wrote:

> NB region cannot hold a metadata attributes; and there is no role element
> (probably a mistake IMO).