TTWG minutes 02/06/09

Timed-text working group minutes 02/06/2009

Present:
David Kirby (DK, co-chair)
Geoff Freed (GF, scribe)
Glenn Adams (GA)
John Birch (JB)
Andrew Kirkpatrick (AK)
Franz de Jong

Regrets or absent:
Philippe le Hegaret (PH)
Sean Hayes (SH, co-chair)

=============================
IMPORTANT NOTES:

1.  Group agreed to keep current dynamicFlow as defined, extend it to support roll-up semantics based on discussion; define a new rollUp shorthand value (GA to do).

2.  Everyone review Appendix E and Appendix F, recently added by Glenn to the editor's copy of DFXP.

=============================



Minutes from call:

DK:  Discussion of roll-up captions between GF and GA.

GA:  Sent response to GF's sample code and proposal to list.

GF:  Will have to read and comment on-line; haven't had time yet to read completely.

GA, GF:  (discussion of how roll-up captions can appear on screen)

GA:  We can accurately represent time-coded roll-up (TCRU) captions using current DFXP models; will have to make adjustments to roll-up rows smoothly in their entirely.  Can probably easily emulate TCRU.  But do we also want to emulate real-time writing (slow and jerky)?

AK:  May not be necessary.

GF, GA:  In favor of the simplest approach

GA:  Why do we need to state that roll-up semantics with content instead of region?

GF:  Specifying roll-up semantics in content could be easier for authors; they only have to work with one timeline.  Currently, authors have to specify timing in the content and also in the region, if they want to change behavior in the region (e.g., animation).  If an author wants to switch between pop-on captions and roll-up, this is currently a region property.  Would be cleaner to allow it in the content as well.

GA:  Nothing to prevent you from targeting that information.  Since we can animate the behavior of the region, it's possible to specify scrolling behavior over time.  You can say that a region has dynamicFlow behavior at one interval, then pop-on.

Let's say there are two spans in a <p>, one with roll-up behavior, one with pop-on.

AK:  Or a situation where pop-on is mixed with roll-up.  Do you envision a need for defining only in region and not content, vice-versa?

GF:  No, both are valid.

AK:  In favor of applying dynamicFlow to regions and content, but making it simple.  Defining it within the content; it feels like an edge case; may not be feasible to do it at this late date.

DK:  Are we too far along to do content definition now?

GA:  Would not object to a shorthand value (e.g., rollUp) with well-defined semantics.  Will continue to object to assigning roll-up semantics to content.  DFXP is not an authoring format.  Intent of DFXP is to take existing formats and specify their semantics with a subset of AFXP.

GF:  Agree that DFXP wasn't intended to be an authoring format, but it is being used that way in several implementations.  Must recognize this.

Am willing to compromise and leave content specification out of DFXP for now; perhaps get it in later versions.

AK:  New solutions may present themselves later.

GF:  Is my representation of animated movement correct (in the sample sent to the list)?

GA:  Mostly.  Need line breaks after each caption; need to specify end times on all rows of text.  Each row requires a begin and an end if you use <par>.  If you use <seq> you can express a dur on each row, using a begin on the first span, dur on following spans; use a <p timecontainer="seq>; first span has a begin and a dur; following rows need a dur only.

PH:  Why a dur on the first row?

GA: Otherwise it has an implicit duration of zero.

PH:  Another comment:  in a live stream you need to know where in advance to put the captions.  If we don't know this, we will need to define a default region or regions.

GA:  We would need to define a streaming format to allow incremental update of element items.

PH:  Yes.

GA:  Or you would need to have an element that would allow you to modify region properties previously specified.  SVG has something like that?

PH:  Define several regions at the beginning and then use region attributes when you need them.

GF:  Use an animated region for pre-produced captions; pre-specify several regions for streaming captions.

GA:  Keep current dynamicFlow as defined, extend it to support roll-up semantics based on discussion; define a new rollUp shorthand value.

GF:  Agree.

DK:  Will we have any full implementations of full dynamicFlow behavior?  If not, is this acceptable?

PH:  Don't know.  We don't have two full implementations of DFXP no (have several partial implementations only).  Was counting on arguing that all the features are supported for a transformation format, not authoring, even if we don't have full implementations.

GA:  Haven't discussed the changes I've made in the current draft re required features.  Now a a long appendix, E, which contains material called "Features".  Important part of that is a table in E.2 called feature support.

PH:  But won't have implementations...

GA:  I tried to enumerate every feature in the spec; 122 of them; some of which are shorthands of combinations of features.  For each I've put in E-1 of whether the feature is mandatory or optional for transformation of presentation.  Below that is a summary of mandatory features for transformation and presentation processors.  Those are a small subset of the defined set of features.  We should focus on testing mandatory features; do a decent job on optional features.

PH:  We have that already in the current test suite, except for dynamicFlow.  Current test suite comes very close to 100% coverage.  One thing we can do is when we define our basic profile, we can use the features you define here.

GA:  Yes. Those who make claims that mandatory features are feasible... also need to emphasize that DFXP is primarily a representation language for transformation and delivery.  Direct presentation is only secondary at this point.  We should give as much or more credence that supports transformation as presentation.  We can generate an XSL style sheet that will recognize every feature for transformational purposes.

PH:  Was hoping to use existing structuring languages (608/708) and show that we can transform these into DFXP.

GA:  That would be relevant in terms of use, but people who need to transform data into DFXP will need style sheets to do so.

PH:  But we also need implementations.  We are loose with that term, but still need them. Should go beyond just recognizing features.  Goal is to show that we can transform other formats into DFXP.

PH:  We just introduced requireFeatures attribute, but we have no support for it now.  Ironic.

GA:  Agree, have to update implementations to support requiredFeatures.  If that's not done, then it won't work.  Both requiredFeatures and requiredExtensions are listed under required features for presentation processors.  I took a stab at defining mandatory features for defining presentation; please review carefully and comment.

PH:  My point is that we must be very fine-grained in the basic profile.

GA:  Already done that.

PH:  But for tts:color, just one feature is specified.  Opacity is not specified as basic feature.

GA: Re-read Appendix E; can be modified.

PH:  Not saying that we should modify it.

GA:  I'm hearing a resistance to trying to do this.

PH:  No, not at all.  To define a basic profile we must have a more fine-grained set of features than those you have specified (in Appendix E).

GA:  Not sure much more fine-grainedness is necessary.

PH:  But we need more English prose to explain features.  Not suggesting we change your features; just explain them completely.

GA:  Not sure about that yet.

PH:  You only have one feature for the tts:color; we need others besides what you've specified.  Not all useful values are specified the way you've written Appendix E.  Need more than just one feature to be specified.

GA:  Okay, we need prose to point out that if a specified color is not supported by the presentation agent, an accommodation needs to be made.  That's the case for all CSS and SVG implementations.  We really do want to make an effort to define a minimum profile for presentation and transformation.  Appx E gives us a good place to start.

DK:  Out of time for today.  What's next with dF?

GF:  Will accept dynamicFlow with its changes discussed today.

DK:  Agreed, but concerned about implementations.

PH:  We can show that we're using it for transformation instead of presentation?

GA:  Good idea-- that we can transform pop-on or paint-on to roll-up, perhaps?  And vice-versa back to 608?

AK:  If we had a beta version of the Adobe captioning component that supported it, is that sufficient?

PH:  Yes.

AK:  We might be able to do that.

PH:  Just worried about the timeline.  If it takes six months, that's too long.

AK:  Might take someone eight hours once we get it in the queue.

DK:  Doesn't need to be polished, it just needs to work.

PH:  Correct.

DK:  Still need full implementation of dynamicFlow.

PH:  Need to come up with a basic profile.

GA:  Suggest that we start with table E-3 and go from there.

PH:  We have tests now; would need to look at tests to see which match with your features.

GF:  Suggest we deal with Appendix E, as well as F, on next week's call.

DK:  Okay.  PH, can you review coverage?

PH:  Yes, will start on that.

DK:  That's it for this week.

-- end of call --