Timed Text Working Group Teleconference

20 Sep 2016

See also: IRC log


Andreas, Dae, Glenn, Nigel, Pierre, Rohit, Thierry


<scribe> scribe: nigel

nigel: Let's continue from yesterday according to the agenda we planned yesterday.
... Any other agenda points not yet raised?

rohit: Reminder that we have an agenda point to discuss github experience.

TTML Profiles and Media Registration

nigel: Philippe you made some progress?

plh: Yes, it was submitted - the status in IANA today is that it has been sent
... for Expert Review. I would expect an answer within a week or two. On the action
... item I have logged the details.


<trackbot> action-477 -- Philippe Le Hégaret to Progress the update to ttml media type registration with iana -- due 2016-09-15 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/477

plh: I submitted it on Sep 15, got an ack on Sep 17. As soon as I hear back from
... them I will let you know, and if there are expert comments I will put the
... commenter in contact with Mike. If everything goes well we should be all
... set in 2-3 weeks. I don't know how long it takes to update the registry.

nigel: Thank you!

Github 1 year on - how 's it going?

nigel: I wanted to raise this as a placeholder - I think it has gone well for IMSC
... but we have had a lot more discussion about TTML. Any views?

glenn: It's working for me okay.

plh: A question: how far are you from a TTML2 CR?

glenn: Less than 3 months
... We'll ask for Wide Review in 6-8 weeks.

plh: My worry is that you give the other groups enough time to do the review.
... With the reorg happening Ralph Swick will be responsible for organising
... horizontal reviews. My recommendation to facilitate your work on that is
... For Security and Privacy there's a self assessment questionnaire - you answer
... the questions and send them to the right mailing list as part of the review;
... if they do not respond then it's fine.

nigel: Even if they don't want to comment I would expect at least an answer to
... say that, from politeness and also so we know the status.

plh: That's fair enough. Bear in mind this is shifting ground and we're changing
... the way we do this. Ralph will be harmonising this.
... For the TAG, you can ask for a review using their spec-reviews github repo


<trackbot> action-480 -- Nigel Megitt to Request schedule time for horizontal review of ttml2 -- due 2016-09-26 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/480

nigel: Please could I delegate this action to you Thierry?

thierry: Yes. This is new to me also.

nigel: I've moved the action to Thierry.

thierry: One idea we have raised is only to request review on the new features.

plh: That will help them but they may tell you about a problem with the older
... features.

thierry: And then they will destroy TTML1?

plh: Possibly they could!
... Here are some links to help you with this:
... Having difficulty joining IRC so I'll send these by email.


plh: With the W3C reorganisation I am becoming responsible for all the WGs in
... W3C, so I will be responsible for ensuring all the WGs are able to move forward
... on the Charter deliverables. I am allowed to extend Charters with Director's approval.
... It is now the responsibility of Wendy Seltzer to look after what the future web
... is going to look like and propose any changes to the Charter. Ralph is responsible
... for the entire technical coordination of W3C including horizontal reviews, TAG
... and other technical issues that groups cannot resolve. If you come to me
... with a major technical issue I will take that to Ralph for you.

nigel: Thank you for your help over many years!

andreas: +1

plh: I am still responsible for the TTWG! Nigel can still come to me and complain
... if he has issues - now all the other Chairs can do this too!
... So I won't be doing github issues etc myself unless it's super quick.
... Team Contact and Chair training are now under my responsibility too.

nigel: Thanks - any questions or any more?

plh: It's been a pleasure, feel free to contact me and I'll try to be even more responsive.

glenn: So no more ttml.js maintenance?

plh: If anyone wants to fork that and come to me for some information on it that's fine
... but I can't spend official time coding any more.


plh: You're welcome to rename it - it's under CC0 so it's public domain. I'm happy
... if someone wants to do something to put a pointer on my repo to other places to look.
... Excuse me, I need to go to another WG now.

nigel: Thank you very much!

IMSC Implementation

andreas: [projects Hbb4All presentation]
... I just wanted to give an update on Hbb4all. An EU funded project that ends this year.
... A strong focus on EBU-TT-D deployment. I always promoted as TTML because
... it is better known.
... 6 or 7 player implementations, 3 broadcaster apps, one being for TTAF.
... jwplayer and videojs implementations hopefully that will be open sourced.
... Also a Samsung native implementation of TTML for HbbTV 2, which I think
... was a public prototype implementation last year.
... Also, we demonstrated automatic production of subtitles, DVB TS -> audio processing ->
... speech recognition -> punctuation and captialization -> TTML generation
... Lots of other partners also.
... subtitling.irt.de - 2 demo live streams of EBU-TT-D in DASH.
... It uses the dash.js implementation so for example you will see line gaps between background areas.
... We did some interop testing for each partner with each other's TTML, to see
... how it is rendered. There are certain issues. Example with background colour
... not coming out if RGBA is not implemented properly.
... Also font being proportional even though monospace specified.
... This will be published as a report.
... Another one is overlap of lines - a big problem is application of lineHeight
... especially with the "normal" setting. There is no clear message from any group
... using TTML, or there are contradicting messages.

glenn: You mean other than the specification note to use 125%?

andreas: That's a recommendation only. In EBU-TT-D we recommend not using
... "normal" because it is not implemented the same everywhere.
... The gaps between lines differ between different renderings again because of
... lineHeight="normal".
... Another one is where implementations try to do a nice looking thing even
... though it is not specified, like including linePadding when it is not in the document.
... I also saw a lot of implementations at IBC sometimes called DFXP because they
... are not always aware that it is the same as TTML effectively.

nigel: Thank you!
... While we're on this topic it would be a good time for me to mention about
... EBU-TT Live.
... I mentioned this at the Web & TV IG yesterday also: http://ebu.github.io/ebu-tt-live-toolkit
... The project is an open source implementation of the EBU-TT Live spec
... - we're about half way through implementation. The spec is at v0.9 now
... and we hope to move to v1 in early 2017.

glenn: Do any of the efforts for live define rollup?

nigel: This doesn't - EBU-TT doesn't permit any form of animation, and in any
... case it is not clear how to use animation for smooth roll-up. In my opinion
... the best way to do this is still to allow implementation specific behaviour as
... written in the Note in TTML1.
... By the way, the context here is a sequence of TTML documents in the absence
... of any wrapper that can provide additional semantics. For our work here this
... has two impacts for TTML2, one is sequence identification and numbering

<tmichel> taking a 15 minutes break


nigel: Shows a scratch diagram with three real world concepts, the Root Container Region, the Related Media (e.g. encoded video) and the Media Player, each being an independent concept.
... default of the Media Object Region which coincides with TTML1.
... We should make sure that we all share an understanding of those different
... viewports and that they match what we need in real world use cases.

glenn: Right. I think we can look at the Safe Crop Area proposal independent of
... that, because it is orthogonal.

nigel: Right.

andreas: I think we need to gather all these concepts together and clarify them.
... Especially in relation to IMSC which talks about video frames.

nigel: https://github.com/w3c/ttml2/pull/184

glenn: So you're defining in the document coordinate space an area that
... presentation processors should keep sacrosanct.

nigel: Yes.

glenn: I don't see that as a problem. Putting all four parameter values in a single
... attribute can work. I wonder if we should constrain the values to percentages.

nigel: Yes we could do that.

glenn: I find that a lot of implementations are based on percentages.
... The one part I have a problem is the presentation semantics.
... I think we can dispatch the Visible rendering area definition, or I'd like to.

nigel: If possible that would be okay.

glenn: I'd like to describe the process in the 2nd paragraph differently and
... use should rather than shall.
... [discussion] If tts:extent is not defined on the tt element then the root container region is defined as being coincident with the related media object region.
... If the Related media object region changes during presentation then I don't
... agree that this triggers a re-layout.

nigel: I don't agree. If percentage extents and font sizes are used then it is
... possible that a re-layout is needed.

glenn: We always assumed that would not happen.

nigel: Is that written in the spec somewhere? I've never read it anywhere.

glenn: I think it's implied, I'm pretty sure it's not explicit.

rohit: There's some wording in the text on the tt element about the behaviour
... if there is no tts:extent on the tt element.

pal: IMSC 1 says explicitly that you shall map to the related media object.

andreas: So IMSC is saying that you map it to the image frame of the related media object.

glenn: Correct, but the language there does not talk about changing on the fly.
... This is a key point, whether the processing context can change over time
... or not.

pierre: If you don't specify tts:extent on tt then there's no notion of pixels at all.
... The root container sets the coordinate space for the document. Every length
... is related to the root container region always.

glenn: There's another way to think about that, which is when you establish
... the correspondence in the beginning then you can create pixel values.

pierre: That is one implementation.

glenn: Then after that if scaling occurs then you still use the same dimensions.

group: [discussion] conclusion that the requirement is to define that implementation ensures that everything that falls within the safe crop area is displayed on the screen.

glenn: If a tts:extent is present then it establishes the document coordinate space.
... If an extent is absent then you need to establish a document coordinate space (once and for all time) that overlaps the Related Media Object Region.

pierre: That's one implementation - some implementations do not use pixel coordinates.

nigel: For me it's okay to have a document coordinate space that is always only in percentages.

glenn: It's important to know the pixels for laying out fonts etc.

pierre: Each implementation decides what pixel grid it wants to render on.

dae: If you have 800x600 video and the user clicks zoom so we now have 400x300 what's the document coordinate space now?

glenn: That would cut off content on the edges.

dae: So in that case 50% would still mean 400 (or 300)?

glenn: Exactly.

andreas: Is this also how IMSC 1 defines it?

pierre: IMSC 1 makes the mapping of the root container dependent to the related media object.

nigel: The section about best endeavours is there to allow for presentation
... processors to do whatever processing they want to do to achieve the required
... outcome of ensuring the content in the safe crop area is displayed (i.e. is in the visible rendering area)
... To draw this to a close, I have an action to modify the first paragraph in
... pull req §11.3.3 to avoid referencing the undefined term "TTML content"

glenn: In the second paragraph I would rather not use shall but use a declarative approach.

nigel: This is actually a processor requirement so it's a shall. There is a defined
... feature for it, which in the case of a presentation processor, refers to the
... semantics in §11.3.3 so it would be possible to profile out this behaviour
... using that feature designator.

glenn: Okay I'll look at that.

andreas: I'm a bit worried about the number of terms and their definitions and that
... we may not all share the same understanding. Everybody has a certain view,
... but it may be that we are not all on the same level right now. This is a problem
... if different implementors understand it differently.

pierre: You should bring any differences here. ittp:aspectRatio in IMSC 1 sets the
... aspect ratio of the root container.
... For example if it were 4x3 then a reasonable implementation is to create
... a 4x3 pixel array, render the document on that, and composite that (potentially
... also scaling isomorphically) onto the related media object.

andreas: Yes, centred.

pierre: If I don't specify ittp:aspectRatio then I can choose whatever shape pixel
... array corresponds to the related media object, choosing whatever actual
... resolution I want.
... If we think it is important to explain how this works then we can generate
... examples if you think that's important. Is that your concern?

andreas: Yes it's part of it, but it's also the other terms.

nigel: And in IMSC 1 it is deliberately left vague whether the related media object
... is the encoded video or the media player for example. And different implementations can make different choices.

pierre: Yes, and that's something we should try to define possibly in specs that
... that reference IMSC 1.

andreas: For this group I would like to make sure we have clear definitions of:
... related media object, related video object, related media object region,
... image frame of the related video object, document coordinate system,
... viewport, viewport target.

nigel: Let's take a 10 minute break and restart at midday.
... Okay, we're back...

TTML2 viewports and other terminology

andreas: I would like to have the reference terms from TTML1, IMSC, EBU-TT-D
... and then look at the terms in TTML2.

nigel: Ah, that would take a bit more preparation than I think we have, but it
... sounds like a good review exercise. What we can do now is look at the new
... terms in TTML2 and do that task later or on our own.
... Glenn what are the important new concepts?

glenn: viewport and viewport target.
... I don't personally like that definition of viewport because it is too general.
... In our context it should be closely related to the root container region.
... What I was thinking at the time is that it is possible to think of different
... viewports, one for presenting the related video object and another for
... presenting the root container region, but for us the root container region
... is the only concept that has any significance.
... In TTML1 there was a long outstanding bug to improve the definition of pixel.
... At the same time we began introducing mechanisms involving aspect ratio.
... where we introduced display aspect ratio in IMSC. I needed appropriate
... terminology for discussing aspect ratios. Then I had to distinguish between
... time of authoring and time of presentation, where aspect ratios may differ.
... Then there's the vw and vh unit definition which effectively assume a viewport term.
... We already have this defined in the XSL-FO space.
... The first note in refers to the page-viewport-area which here
... corresponds to the root container region. They play a crucial role in defining
... a local coordinate space in which the children are positioned and rendered.

pierre: Why do we need to define viewport given that the definition of the vw and vh units do not use it?

glenn: Well we need that to define viewport target.

nigel: Why do we need viewport target?

glenn: This is to relate the root container region to some other context such as
... encoded video's image area or the area including the black bars etc.
... Viewport target is a formalisation of an initial attempt to provide a conceptual
... model for associating a root container region with something other than the video frame.
... I don't know if it's something that we want to nail down in TTML2. To support
... it fully we're going to need some new parameters like viewport target parameter.
... What's in the spec right now is preliminary and needs more conceptual
... thought as well as syntactic support.

pierre: I don't see why we need anything other than root container region.

glenn: If we are talking about the outer world we need it...

pierre: That's a separate step.

glenn: Yes it is. The question is does the author want to give some hints about it.

pierre: Everything that relates to generating pixels should always be related to
... the root container region, and then we should separate out the concept of
... how the root container region relates to any real world thing.

glenn: I have no problem with that, but we have only one terminology section.

pierre: True, we don't want more than one of those.

nigel: It sounds like there's more work to do here and some group members may
... have questions in their minds about how far we need to go in TTML2 to relate
... the root container region to some physical thing.

glenn: I'll proceed with this - it's possible I'll pull it out depending on effort constraints

rohit: If we have root container region and some aspect ratio defined, is there
... anything else that needs to be normative?

glenn: IMSC defined DAR, so now we have all three aspect ratios and it's possible
... to generate a conflict.

rohit: Let's say we get past that issue, is there anything else that needs to be
... normative?

glenn: Then I think we need normatively use some definitions in other parts of
... the spec to give semantics to definitions.
... If we do want a viewport target parameter then we need normative
... syntactic definitions. We could segregate some of this into an informal annex.

nigel: Where is the use case or requirement coming from to define viewport
... target in the document?

glenn: Someone said it at some point but I can't point to any formal submission.
... If nobody thinks it is useful then I would just as soon not spend time on it.
... We do start to touch on this with safeCropArea.

nigel: All we are doing there is admitting the idea that not all of the root container
... region might be displayed.

glenn: The only other thing is nigel's suggestion to rename vw and vh.

dae: it would seem more consistent to use rw and rh since they are related to root container region.

nigel: My concern is that vw and vh will be misunderstood and misused.

group: discusses impact of changing vw and vh to rw and rh, concludes that we will change.

nigel: Thanks for the constructive approach everyone.
... I've updated issue https://github.com/w3c/ttml2/issues/181

TTML2 initial element

pal: So initial was introduced to set defaults for style attributes; and there's already an inheritance
... scheme for initial. Why not make non-inheritable style attributes inheritable instead?

glenn: That would break CSS and XSL-FO models very badly, for example all the background properties.

pierre: You could just reference a style from a region, where the desired defaults are in that style.

glenn: That's not style inheritance, that's referential styling.

pierre: Okay, so you could enable referential styling for backgroundColor with no impact.
... That's my proposal, to use referential styling instead of initial.
... The style resolution process already does this.
... I then don't need to introduce a new vocabulary.

glenn: That forces users to adopt a particular authoring style and it may not be efficient in some contexts.
... For example say you have tts:showBackground which defaults to "always" which you may want to change to
... "whenActive" so that's a good example for using initial to set it to a different value instead of its normal default.
... In the case of an anonymously generated region by putting an extent and origin on a p or div, it would not be possible to have
... them style the region that was created anonymously via the use of a style attribute. Any style attribute on p for example
... do not apply to the region, only to the p.
... The region created picks up the initial values as defined.

nigel: This touches on the question of whether region style attributes modify the existing region or create a new one.
... Another syntactical approach could be to introduce say a tts:regionStyle attribute to reference a style for the created region.

pierre: [Notes that he objected to this solution to meeting the default value requirements back in January]

Andreas: I see a use case for this - the only thing is are there problems in current implementations that make this necessary,
... because every additional feature adds to the implementation burden. Does anyone have a problem in TTML1 that makes this
... necessary?

glenn: I have noticed that people often fully specify styles that are redundant. I view initial as a highly useful authoring tool to
... reduce the size of documents and the complexity.
... I use initial all the time, and it's an option to profile it out if necessary.

pierre: Is there anything you can do with initial that you cannot do with referential styling?

glenn: No. Indeed you could also use full inline styling.

rohit: If you specify all styling attributes you also would not care about it.

glenn: I found this in change proposal 17 going back to issue #207 in tracker...

nigel: From the discussion, to summarise, we have consensus to leave initial in the TTML2 spec.
... Thanks, there's no issue to update on this, though this initial element does appear to satisfy https://github.com/w3c/ttml2/issues/36
... Let's take lunch now, return at 1400.

TTML2 - timing

nigel: I don't feel we have a lot to do here.

glenn: That's my take too - cleaning up some language may be adequate.
... Adding some notes about SMIL may be helpful. We need to firm up the
... idea of a document timeline.

nigel: I have three things to raise here:
... 1. I would like us to have a defined document timeline for which the document
... defines some activity.
... 2. Consider removing SMIL normative references and replacing them with our own normative text.
... 3. Consider adding a time expression model controlled by a parameter on the tt element
... in which all the time expressions are flat and on the document timeline,
... so no calculations are needed for nested timed elements. We would need to
... be careful to clarify that elements can only active in this new model when
... their parent elements are active.

glenn: We could do that, being aware of the potential additional time taken to
... advance the specification.

nigel: Note that there's no feature designator right now for nested times in TTML.
... I would add a feature designator for the new flat timing model to allow
... profiling for implementations that only support flat timing, which would be
... much simpler to write.
... This also would offer a path to a nice solution for the first problem, which
... would simply be to allow a document's active period to be defined by begin
... and end/dur elements on the body element.

andreas: You could simply profile out nested timed elements.

nigel: You could but then you would need a different way to define the document
... timeline.

rohit: From a use case perspective I prefer flat timing.

dae: I don't see a use case for nested timing.

nigel: If we decided to adopt this then I would volunteer to do the editing work.

glenn: Post TTML2 it might be more feasible to identify some specific extensions
... like a new timing model and write a spec just for that, in a modular approach.
... We would have to put a framework in place in order to deal with the use
... of modules.

pierre: I've never seen nested timings used, and probably hardly any
... implementations do it properly.
... I've never seen content for distribution that has nested timing.
... I think our time is better spent clarifying the timing model.

glenn: I've read the SMIL timing and synchronisation section probably 20 times
... and implemented it at least 3 times, and every time I have different questions
... and implementations, so I think it's difficult to get it right.
... Absent some reviewed test content I don't think we have dealt with the questoin
... of correctness in a way that's satisfactory.

nigel: As a minimum I think we need a feature designator for nested timing.

andreas: Yes.

pierre: Why not just require non-use of nested times?

rohit: I think you can specify that by saying that on the traversal from root to
... leaf only one element specifies a begin or end time.

nigel: From the discussion, I think we're not generally supportive of adding
... a flat timing model now but we are interested in reproducing the SMIL semantics
... and making them normative in TTML2.

glenn: That would take a lot of time, so I'm thinking it should be a post-TTML2
... task because there are too many things that are higher priority.
... I wouldn't object to anyone else going ahead and doing that work but
... I'm not sure I would have time to review it and sign off on it.

andreas: The first thing is that SMIL is hard to understand for everyone; the
... second is if we have any existing problems that we need to solve. If not, then
... is there an urgent need to clarify it in TTML2? Perhaps the clarifications could
... be done in a separate document for example.

nigel: We could certainly do that as a Working Group Note say.

pierre: The situation in most implementations is probably that there are bugs.

rohit: People who author do so with a "flat timing" mindset.

pierre: Most players assume that, and are just based on leaf elements having
... begin and end attributes.
... My suggestion for going beyond that is if there's part of the industry that
... wants more than a flat simple model then getting out of SMIL would help
... get beyond that. If we don't care about that for now then we don't have to
... do anything for TTML2.

glenn: There are not a lot of timing tests in the TTML test suite.
... but there are a few that would be useful to run through existing code.

rohit: One possibility is that you produce ISD sequence and check if two
... implementations produce identical ISD sequences.

nigel: By the way I still have a problem with making the ISD serialisation normative in the spec.
... it's a useful concept but I don't think it needs to be normative.

glenn: I'd be prepared to make it informative.

nigel: Going back to my first point, I would like to be able to indicate without
... changing the SMIL timing semantics or the syncbase the time from which
... any given document defines some output behaviour.

glenn: You could just use the first ISD time.

nigel: That only defines the time at which some content is displayed. I want to
... be able to define a time at which the document becomes active even if at
... the beginning for some period there is no content displayed.

andreas: [explains concept on whiteboard]

glenn: It sounds like you want to introduce the idea of a supra-document timeline
... that covers multiple documents' timelines.
... [expresses problem as needing to put documents onto a separate timeline via the whiteboard]

andreas: What problems exist with the current mechanism?

nigel: It would solve some specific cases for assembling live subtitles onto some
... kind of "global" timeline, also potentially for feeding into a packaging mechanism.
... I would make an "entry point" and "exit point" parameter on the tt element,
... which would be optional. It would not modify any of the existing time
... resolution or computation semantics, but effectively tell the presentation
... processor to "seek" into a particular moment on the document timeline, and
... "stop" on a different moment, if specified.

andreas: [expresses concern that this could duplicate functionality in other layers]

rohit: This also has some analogies in IMF for example.

nigel: I would make this optional so that it can be used when there is no external
... wrapper format.

andreas: Possibly it would be interesting to view this as a proposal.

nigel: Ok I'll do that! [break for coffee, return at 1550]

andreas: Over coffee I had another idea that might solve your use case Nigel...
... If there's no wrapping information there's no way to get the information for external processing context.
... So what you could do is define a new element outside the tt element that could be used as a wrapper,
... then have a tt element inside it. So you just define a wrapper element for the tt document.
... This could be a short note or whatever defining the new element and the semantic.

nigel: Ok, why would that be better than having a parameter on the tt element?

andreas: The semantic of the tt element doesn't change at all, and it would work for any kind of document.

rohit: This would make TTML2 documents look very different from TTML1 documents.

andreas: You could wrap TTML1 documents in this also.
... And it doesn't conflict with current semantics.

nigel: One issue with this is that the active begin and end times should be in the document's timebase and
... you would have to inspect the contents to discover what the outer wrapper values actually mean.
... As a general concept I can see it could be useful but for this it feels to me on first glance a bit "heavy".

TTML2 - condition

nigel: https://github.com/w3c/ttml2/issues/128
... The issue here is how you use the condition mechanism to set different attributes on regions or styles
... for example based on an externally passed in parameter or media query.

glenn: Style attributes can point to multiple styles.

nigel: True, but region attributes cannot.

glenn: I need to review this and think about some alternative solutions. Region can refer to style elements.
... That's probably what I would do. It would be useful to put some motivational examples on to
... describe why one would use condition.
... I do have some open questions by what it means 'ignore the semantics' when the condition is false.
... For example let's say you have a chain of styles that refer to each other, if one of the middle ones in the
... chain has a false condition do you ignore it and all the rest of the chain, or just the styles defined on that
... style element. I haven't decided in my mind the best approach to that.
... For every element we probably have to say something about what it means to ignore that content.

rohit: One use case would be on the content side, to replace the "forced" functionality.

nigel: Agreed.
... Glenn you mentioned recently that adopting the 'modify' semantic for inline anonymous region would
... require a reversal of the direction of reference. Does that have any impact here?

glenn: The way that content and animation are associated using xlink:href to point from an animation to
... content, in SVG. When we started with TTML2 animation we started with that same approach. The SVG
... spec probably defines SMIL animation better than SMIL does.
... We changed it so that content elements point at animate elements, so to pick up an animation for an
... out of line animation then the content would have an animate attribute pointing at the id for the animate element.
... If we want to animate the current region then the logical place for the animation would be as a child
... element of the content, for example a <p tts:extent="..." etc.> you would synthesise a set element that
... is a child of a p, but targeting the region of the p not the p itself. Now we need the animate element to
... point at the element to be animated.
... I don't really like using xlink for this purpose so I am contemplating using a target attribute on the animate element.
... However we do have xlink already because we added support URL linking, so using the xlink version would
... be feasible here and may be desirable for consistency.

nigel: In that case you could resolve this issue by having set elements that change region attributes as well
... as condition attributes, so that would effectively conditionally apply styling etc to regions using that mechanism.
... The next question is does a set element have to have timing?

glenn: No, it is a timed element so it has times whether defined or not, but it could have implied times
... that would be inherited from its parent.

nigel: Presumably its 'rehomed' parent not its lexical parent, the animation element?

glenn: That's a good point.

nigel: I've added a note to the issue on github there.
... https://github.com/w3c/ttml2/issues/168

glenn: I think we already have consensus on doing this.

TTML2 simplification options.

nigel: I don't have any specific proposals for this but have been wondering if there are any options for
... structuring the TTML2 spec to reference TTML1 and add to it, for example. I think it's almost certainly
... not something that we would agree to right now, but it's occurred to me that we could consider it.

group: [discussion of possibilities, predictable lack of willingness to vary from current path]

andreas: For implementers it might be helpful to have an EBNF notation for TTML1 and TTML2.

glenn: I would leave that as an exercise for the reader. It would not add any precision because all the
... information is already present for every syntactic feature. For example for attribute values we use a more
... general EBNF but for element definitions I used a different syntax, I think from how SVG and SMIL did it.
... Points at §2.3 for a definition.

nigel: Are we going to hit an accessibility problem with the spec by using colours only to indicate
... deprecated or obsoleted features?

glenn: Whenever there is one it is also written out in the specification text.

nigel: Ok there's no problem there then.

rohit: Does this cover the expression syntax too? Or is that classic EBNF? if it is we should call it out.

glenn: Actually I think we followed CSS, where for example || means "in any order" and && means a particular
... order (but we don't happen to use any of those).
... I guess we should check if we say in the conventions if we make use of those.

rohit: I don't think we do. We should be explicit that we're using EBNF or whatever.

nigel: Please could you add an issue to the github repository for that please Rohit?

rohit: Sure, more than happy.

TTML2 issues

rohit: https://github.com/w3c/ttml2/issues/168

glenn: Mike Dolan's response to this was that it should be illegal or an error. I think we can easily update
... the formula in Annex N to accommodate fractional seconds in clock-time expression in smpte mode.
... If it is allowed it should probably only be permitted in smpte continuousmode, since they by definition
... can not be labels as are used in smpte discontinuous mode.

nigel: I've heard a question like this before. I think you have to quantise to a specific frame value, and I don't
... know how you choose whether to use floor or ceiling or whatever to do it.

glenn: [Go to H.3 in TTML2] clearly you could end up with fractional frames, and it does not look like we
... have defined any floor or ceiling rules here.

nigel: Whatever we do we could end up generating a frame value that turns out not to be valid according to
... dropMode, so I'm beginning to come round to Mike's point of view that we should just not allow this and
... consider it to be an error, since this seems to be nonsensical.

rohit: That sounds like a resolution.

nigel: It would also be coincident with EBU-TT (not permitting fractional seconds in smpte timebase)

rohit: Do we also not allow offset time expressions with anything other than ms and t metrics?

nigel: You are also permitted fractions in offset times.

rohit: Then exclude fraction components too.

glenn: I noticed another problem in H.3 - it does not refer to subframes, but we do have a subframe component.
... That was intended to match an earlier smpte spec that allows you to specify field numbers.

nigel: I don't see this problem - subframes are counted in H.3
... I would propose to prohibit offset-time expressions in TTML2 even if that's a breaking change. It would be better for the world! At least we would put it out for review.

glenn: I would accept a "shall not" when version="2" for TTML2.

nigel: I've updated the issue with this.

rohit: Re notation, I created https://github.com/w3c/ttml2/issues/186

TTML2 - sequences of documents

nigel: We have already discussed this last year and have https://github.com/w3c/ttml2/issues/122
... I propose that we move on unless there's a change to what we agreed - we just need to create a pull
... request for this and do it.

glenn: In the context of entry and exit time parameters it would be preferable to have them all either in
... the metadata namespace or the parameter namespace.

nigel: Arguably there's a philosophical difference since a processor would not take action based on the
... sequence id and number when processing a single document, but it would to based on the entry and
... exit time parameters.

Audio Description

nigel: I made a submission early on Monday morning for requirements for audio description.
... Describes the requirements document; [describes expected TTML2 structure on flipchart]
... It seems that TTML2 could easily be expanded to fit these requirements by adding pan and gain
... attributes, an audio mixing model and an additional interpolation mode for animate. BBC has a
... prototype AD mixer using the Web Audio API that could easily be modified to run off a TTML2 document
... that supports these extra features.

glenn: TTV can validate the audio element so that could be another implementation.

nigel: There's currently no AD document spec other than a proprietary one that I'm aware of so this would
... be helpful to the world also.
... If anyone has interest in taking this further please respond to my reflector email with any comments
... on the requirements or any other implementation thoughts.

<glenn> +Present glenn

Text Track and Text Track Cue interface

andreas: Having raised this in yesterday's Web & TV IG joint meeting the question is what role this group
... would want to play.

glenn: I think it would have to play a major role.

andreas: Tomorrow there will be an unconference session on this. I think it would be good if not only
... driven by TTWG.

glenn: +1

andreas: But also not a lot of people will want to do the work and have the expertise so they may well point
... to this group. So tomorrow if there is interest to move this forward one proposal would be that the
... requirements would be documented and taken to the Web & TV IG.

nigel: To clarify: ask them to validate the requirements?

andreas: I'm not sure how this would work - we may possibly document requirements and possible
... solutions, and then discuss there for contacting other working groups from W3C that are dealing with
... the HTML specs.

<glenn> https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2-api/Overview.html

nigel: We would need some active participants from Web & TV IG to take this forward otherwise it could be
... that nothing happens until next year's TPAC! Maybe we need to go more directly to e.g. Web App WG.

andreas: I was wondering if the attendees of tomorrow's session might be able to bring some work to this
... working group?

nigel: I wonder if we could reuse the TTCG for this?

andreas: I would rather set draft a document in the TTWG and encourage others to join. We might isolate
... this work from the rest of the group's work. This was similarly an issue with the mapping document work.

nigel: It's not in our Charter so we would need to publish as a Note only, or if we want a Rec then recharter,
... or use this group as an incubator and donate a document to another group that might have it in scope
... of their charter.

thierry: We could set up a new CG for this - it would be more neutral than doing it in TTWG and wouldn't
... have the same encumbrances for joining.

andreas: Yes, we could do that.

TTML2 editorial actions

nigel: We're really out of time for this, but Glenn are there any editorial actions you would like help with?

glenn: No, not right now, I will ask when there are some.

nigel: Okay, thanks.

Meeting close

nigel: Thanks everyone - we've covered a huge amount over two days including every topic we had on our
... agenda and more besides, with a really constructive atmosphere.

Glenn: That's thanks to your chairing.

Andreas: Thanks for chairing!

nigel: [blushes] Thanks everyone, have a great rest of TPAC everyone. [adjourns meeting]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/09/20 17:16:09 $