Timed Text Working Group Teleconference

31 Jan 2019


See also: IRC log


Nigel, Glenn, Thierry, Pierre, Andreas, Matt, Gary, Silvia, Cyril, Vlad, Peter_tho_Pesch, Mike
nigel, nigel_


<nigel> scribe: nigel


Nigel: Do we all know each other?

group: [almost all have met before, if only for dinner last night]

Thierry: I'm team contact for the group

Agenda and working model for this meeting

Schedule for today

Nigel: Overall goals of the meeting
... First draft for TT future requirements
... First draft Charter Revision for TTWG
... Since then we also want to understand the situation re WebVTT as well.
... [iterates through agenda]
... How does that look?

Glenn: I'd like a small discussion before we go through requirements to come up with categories for
... assigning requirements to documents. Part of that hinges on what our thoughts are re TTML2 or TTML3.
... We don't have a record of discussion of our guidelines for targeting TTML2 vs TTML3.
... And for IMSC we probably need some idea of what we are targeting, a 1.2 or what.
... I think it might be useful so when we go through the requirements we can refine with labels.
... I've been trying to go through those issues and assign labels where appropriate.
... I think it would be useful before we go through the requirements.

Andreas: Two ways to approach - what Glenn said, or what Nigel proposed to go through requirements
... first and then go through the documents. I prefer what Nigel proposed. I think it makes sense to go
... through the requirements and see for each one which documents they go in. I would start as soon as
... possible with the requirements.

Glenn: It might require a second pass through the requirements after we make decisions about
... document targets. I'm not opposed to that approach.

Nigel: We should make sure we think about documents to target for each requirement we want to meet.
... We can label at the time or later after the notes.

Glenn: That's okay but we need to have some thought about which features can go into TTML2 2nd Ed
... vs TTML3. In my mind substantive new features need to go into TTML3 whereas substantive or
... editorial clarifications can go into TTML2 2nd Ed.
... Yes with the proviso that there may be a grey area, if we forget we need to add a keyword value
... for an existing property, or a feature designator. Those could potentially be in TTML2 2nd Ed.
... New properties or elements are clearer.

Nigel: Also we could consider TTML2.1 for new features.

Glenn: I'd oppose that because we decided in the past not to use dot releases in TTML. It would either be
... 2nd edition or TTML3, not TTML2.1

Nigel: What about IMSC, are we looking at new features going in IMSC 1.2?

Pierre: Depends what they are and on the impact on conformance.

Nigel: Everyone happy with how we target version numbers for TTML?

Andreas: Yes, I think we need to see as we go through.
... The important thing is we decide to publish by the end of the year.

Glenn: That's also my goal, I'd like to get to Rec on TTML2 2nd Ed by the end of the year but also on
... TTML3 which would depend on implementation activity and may slip later.
... Some of these new features are out of my expertise so we would depend on implementers.

Nigel: As always!

Glenn: Yes, and testing also.

Nigel: I would rather defer features and publish on time than let it slip.

Glenn: I would like to get to FPWD by June 1, and hope to go direct to PR.

Nigel: That reminds me Thierry was going to draft a sketch timetable for getting to publication.

Thierry: Yes I will do that, based on FPWD on 1st June.

Glenn: Modularisation might change that, we need to discuss that.
... It's a huge amount of editing work so the editors will bear the brunt of that.

Thierry: For my schedule, if there are no substantive features then it is straightforward because it does
... not change the implementation report. It could be fast tracked.

Glenn: Both documents will have substantive changes.

Nigel: Any more questions about today?

Andreas: Our goal for the TTWG Reqs is to decide for all of them if they will be in the next TTML or IMSC
... publications, today?

Nigel: Yes, I think so.

Andreas: Just to make sure we get through all of them!
... And the target is not to find a solution for the requirement, just to support the requirement itself?

Nigel: I think if we have no idea how to meet the requirement then we probably won't be able to do it,
... so we should have at least some idea of what the solution might look like.

WebVTT Implementation Report

Gary: [Shares screen]

# WebVTT implementation report starter

Gary: I used WPT as a basis. Unfortunately some of the tests require human eyeballs and can't be automated
... so they're not showing in here.
... Some of the tests are grouped by feature, where multiple tests together make up a feature rather than
... each test being a feature in itself.
... This is partly because of the way WebVTT is written.
... For example a Cue includes multiple features.
... It's doable but not really clear cut.

Andreas: I think from the WebVTT spec there are parts you can categorise like the Cue settings.
... It might make sense to do that, and then check each value.
... Also for pseudo-selectors and all the CSS features that are supported, like color etc.

Gary: For the CSS stuff there is a bunch of different ways of selecting parts of a cue, so there are like
... 20 different tests for each one. Five tests for how text wrapping is handled. It's not necessarily a 1:1
... correspondence.

Andreas: Would you also test that color is rendered correctly for example?

Gary: Yes. There are three color tests, for hex, hsla and rgb.
... Some of the cue functions are not supported. They may be relatively new additions which is why they
... are not supported. It is often the case that newer things are less supported.

Glenn: On the spreadsheet the first line says "VTTCue Align" - is that testing the align property?

Gary: That's a folder name, which contains the two tests underneath it.

Glenn: I don't see any align property testing there, so it's confusing. Is the align property tested?

Gary: I think it is in there. The "align" one is the top one.

Glenn: You might want to change the naming to make it clearer.

Gary: yes, I'm looking at the second tab for rendering tests.
... There are Pass and Fails and some ?s where we don't know.
... The ?/F are likely to fail but I'm not sure yet.
... The ?/P are likely to pass I think.
... There are some changes to the spec since the FPWD and they seem to be involved with those I'm
... not sure about. One of the things we may need to do is update the tests for those things.

Silvia: It's a limited set, not a huge list.

Gary: Regions are one of the areas that needs work.

Glenn: I see most of the entries are blank there.

Gary: Yes, Firefox preview does some strange things with defaults.
... VLC does better but I'm not sure.

Silvia: I think VLC might implement correctly but the tests need to be updated.

Glenn: What is the strategy for all-fail tests? Will you take out features from the spec?

Gary: I feel like it might be better to remove features that have no support and then work on the next
... version to add them back.

Glenn: Another strategy is to remove the tests.

group: [laughter]

Glenn: There's nothing that defines what is tested. The WG can define what tests are used.

Andreas: I'm not sure if this was a serious proposal. If we have important features we should test them.
... The process is there for a reason to give some fidelity for implementers to show that there are
... implementations out there. This spreadsheet is really great. To remove tests that fail and then push the
... specs through containing those features that we know are not implemented correctly does not make sense.

Glenn: For a given feature, which I understand are not enumerated, what tests are mandatory to call it
... a tested feature is not determined. If there's at least one test for a feature we can claim the feature
... was tested. Some of us might claim the tests were inadequate, and they might be right. Process-wise,
... this is in the realm of the possible.

Nigel: I recall a couple of years ago David stated the group did not want to remove features, and I think
... that was partly for things like regions where there seems to be an FCC requirement for them.

Gary: We need some way to move forward.

Silvia: It's a bit of a chicken and egg thing, persuading implementers to implement. Some implementers
... wait for Rec before going ahead.
... In the case of regions there are implementations but not interoperable ones, or they have bugs.
... So we could take the feature out for the time being.

Pierre: Or wait for the bug to be fixed.

Gary: Because of the lack of uptake and implementation we may need to do something else.

Matt: We use VTT as a lowest common denominator because of the lack of support for any detailed
... features beyond text and time. If there is serious work to address the implementation gaps it would be
... worth publicising that.

Andreas: Silvia said possibly some potential implementing parties like browsers might wait for spec
... stability before implementing. This would possibly be a reason for publishing not fully implemented
... features. I see that WebVTT has been published for a long time. The strategy was always to have a living
... spec that tracks the implementations. I see that elsewhere. They are often fully implemented before CR.
... It is just an overhead to go further. Therefore I think it is possibly wise what Gary said, to look at what
... we have, see if there are quick fixes, take features out to get to publication, and if there is interest and
... expectation for new features, put them in the next version.

Silvia: Maybe it makes sense if we expect those features to evolve and change.
... The region spec particularly has evolved a lot. We have a pole in the sand now for what we want to
... implement, and scrambling (slowly) to do that. The way I look at this spec is we are putting a pole in the
... sand for the FCC required regulatory features. We went through a rigorous process to get to here.
... Nigel has been helpful and everyone else in the WG in making the spec better.
... I don't foresee any of the existing features making any changes. The next step would be adding
... functionality that isn't there. It would make sense to take everything there to Rec. We haven't
... finished checking if we have interoperability, with the JS libraries, VLC etc.

Pierre: I don't understand what you're proposing. It cannot be published if we haven't demonstrated
... interop by at least 2 implementations.

Nigel: It has to meet the CR exit criteria.

Glenn: I'm not so sure, I think publish as is to draw the line in the sand. If you roll back the test coverage
... to get minimal testing of features I see that as a good option for moving forward even if some people
... don't like that. It's been extremely painful to get this far. It will be a lot of editorial work to haul out
... features. Also on Microsoft since they're switching to chrome basically that takes one implementation
... off the table and you end up with Chrome and Mozilla as the implementation paths.
... Is there an option to pass tests by polyfill?

Pierre: Why are we doing this? To demonstrate interop, right. This is at CR already, it's already published.

Andreas: I would support what Pierre said. It's not a problem to publish for stability.

Thierry: CR is a call for implementations.

Andreas: Exactly that. If this does not happen then it stays in CR.

Thierry: I'd like to focus on the WG task here. It's not up to the WG to decide on moving to PR, That's
... the Director's decision. Our task is to motivate why features are not passing tests and make the case
... to the Director who will decide if it passes the exit criteria and decide whether to move to PR.
... The second thing, about removing features, could be very time consuming and also delay the spec a
... lot. If we move things out we need to publish a new CR with at risk features listed. The current doc
... says there are no at risk features.
... A new CR doesn't take a long time. But then there will be a lot of work for re-editing the spec,
... removing the feature, and we don't know the impact of that, which is not an easy task either.
... The last thing is currently the Charter expires in 14 months from now and WebVTT is mentioned in
... that Charter. If we don't touch it we could wait for a year, but if we do a new Charter then we have
... to convince the Project Lead, Philippe le Hégaret, to include WebVTT in the new Charter.
... We have to remove features, or make the case for moving to PR, or add to a new Charter.

Nigel: David already established we have consensus to stop work on WebVTT if we can't move it forward.
... I think the easiest path forward is to complete the implementation report.

Silvia: How long do we have?

Thierry: In this scenario we're in, about a month.

Silvia: I'm concerned we might not have time to do it.

Gary: I have not tested VLC yet, or the polyfills.

Thierry: To make life easier, why don't you focus on the features not implemented in other browsers,
... those where you don't have enough implementations yet.

Gary: yes that makes sense

Thierry: That focuses to 20-30 tests.

Gary: Additionally some tests can be fixed in vttJS and I planned to open issues on chrome and Firefox.
... Some tests also need fixing.

Silvia: videoJS and JWPlayer have implementations to test too.

Gary: They both use vtt.js

Silvia: Ok

Thierry: You only need to test feature by feature.

Glenn: One small point. I heard Thierry say we could crank out another CR quickly adding only at risk
... features. That would provide a path for moving to PR without requiring another CR if you were to
... remove those features. A change only to the status section wouldn't require a new WD.

Thierry: That's right.
... It's a possibility but doesn't answer the question.

Nigel: We've only got one Gary, so I think it makes sense to prioritise the implementation report.
... We don't even know which features to list as at risk!

Silvia: Gary do you think we can have a full report by the end of February?

Gary: Yes I think I can make the case for that.

Silvia: Some features have multiple tests so it would make sense to group them, and collapse some tests
... together. I think I heard before that if there are multiple tests they don't all need to pass.

Nigel: All the tests in the report need to have at least two passing implementations.
... The goal is to demonstrate implementability not interoperability.

Pierre: What we're trying to do is make sure the spec is implementable, so if the spec is clear and you get
... different results then there's something wrong there.

Thierry: The Director is not going to check if all the features in the spec are tested. It's up to the WG to
... decide if we are covering the features. If we have corner case tests then it's our decision to remove it.

Pierre: Or if the spec is ambiguous, worse.

Andreas: It's important that the WG understands this process. I think it makes sense what is proposed
... to go through and structure the tests as Silvia said, and check against other implementations, and then
... decide on it. In general if a feature has not enough implementations that could be feedback for the spec.
... If we have the results then we can decide how to judge.

Thierry: In some cases we need to understand why the test is failing. It could be a bug, or an unclear spec
... where implementers disagree on the correct result. That is very different from lack of implementation.
... Two different results based on different understandings should be a red flag.

Nigel: We're running to the end of this agenda topic. I think we have consensus to move ahead by
... completing the implementation report over the next month.

Thierry: Specifically to check non-passing features against other implementations like VLC.
... I would like to thank Gary for taking this on.

Gary: Thank you. The third task is that a couple of tests may need to be updated.

Silvia: That's true.
... I would start there if I was you, so you can run those tests.
... Thanks everyone, I'm going to go.
... [leaves]

Nigel: Let's take a break for 5 minutes.

TTWG Future requirements

The first one is issue 1:

Resolve open issues in ttml2 repository. tt-reqs#1

github: https://github.com/w3c/tt-reqs/issues/1

Nigel: Is there any more detail we can add to this now?

Glenn: No, not that I know of, unless we want to go through the 73 issues.
... I need to start processing them right away.
... Quite a few of them are small, some were pushed forward that may not be so small that I need to
... start on.

Andreas: Do we take it as a given that we solve them all?

Glenn: As many as possible. If we have favourite ones then ping me.

Pierre: Timetable?

Glenn: June 1 for FPWD of 2nd Ed.

Pierre: One meta-issue is setting limits on values.

Glenn: Implementation limits?

Pierre: Maximum number limits like on seconds.

Glenn: We have some in the spec already, from TTML1 1st Ed.
... We haven't really pushed specifying limits. I think feature definitions would be the best place.
... For example something that says how many colors are supported.

Pierre: Right, a specific example is number of seconds.

Glenn: We haven't said anything about that.

Pierre: 32-bit or 64-bit. That's a ton of work, so we need to decide on that.

Andreas: Does it cause problems?

Pierre: It has caused problems, because someone had used media time origin as 1970 and that blew
... up an implementation which didn't allocate enough bits to the number of seconds.

Nigel: We do that sometimes!

Pierre: It turned into a more complex problem than at first it appeared.

Glenn: We don't have an issue on this, do we?

Pierre: Maybe on TTML1. It could be a feature designator for minimal support, say.

Nigel: Sounds like a good idea to me.

Glenn: We couldn't retro-actively apply it to TTML1. The ship has sailed.
... They would be in the range of a semantic restriction of an existing feature.

Pierre: We can introduce new features.

Nigel: Yes we can.
... Take it further - if a processor feature says 32-bit number of seconds then does that invalidate content
... with time expressions that could go beyond 32-bit numbers?

Pierre: We began to touch on this in the TTML1 issue.

Glenn: Say we define a limits feature and define a 32-bit one. Absent such a feature in the processor
... profile it would effectively be undefined.
... Then in a content profile I don't know what it means.

Constrain maximum value of @length on data element. ttml2#1023

Least upper bound on supported time expression values. ttml1#307

Pierre: what's the view on this?

Nigel: I want to know more about the implementer pain levels

Pierre: We know at least about time expressions causing pain.

Andreas: I would support doing it for time expressions

Nigel: We can ask others of course. For example I can imagine DVB implementers wanting to know this
... detali.
... Coming back to the macro requirement, are all the substantive issues for 2nd Ed?

Glenn: We haven't created a TTML3 repo yet.

Pierre: There are a couple tagged for TTML.next and 2nd Ed milestone but don't belong in 2nd Ed.

Glenn: Can we get a new repo for TTML3?

Nigel: Yes I don't see why not if that's how you want to do it.

Create TTML3 repos ttwg#23

Nigel: I've assigned that to Thierry

Glenn: I need to triage these. Most of the ttml.next ones need to get pushed to TTML3.

Pierre: Can you do this now so we can go over them this afternoon. It would be awesome if we can get
... get a good idea of it today.

Glenn: I didn't come prepared for that.

Andreas: If nobody has missed a feature and filed it then it may not be a candidate for TTML3

Glenn: I don't understand

Andreas: We opened requirements up and if nobody raised requirements for missing features then you
... could argue they are not in scope.

Pierre: We can't leave "resolve all issues in TTML2" open today

Glenn: That was a catch-all requirement.

Andreas: I agree with Pierre we need to go through them today. 10 substantive features coming in would
... change the whole picture.

Pierre: Can you make a first pass?

<tmichel> https://github.com/w3c/ttml3-tests and https://github.com/w3c/ttml3 created

Glenn: I can't do a first pass today, I can go through it this evening and change ttml.next
... to ttml3 where it's my first approximation and the group can confirm it tomorrow.
... If I think there are things for 2nd ed then I'll mark that too. It'll take me a couple of hours.

Pierre: The most important is to change the milestone.

Glenn: Once we have the TTML3 repo I need to transfer them to that repo.

Pierre: You can transfer issues on GitHub if you're an owner

Thierry: okay

Glenn: I promise not to make any other changes under the covers!

Nigel: Summarising, it is clear which specs are being targeted. We don't have consensus yet on which
... things to adopt, pending a more detailed review.
... For the substantive changes I want to get an idea of what the test will look like.

Glenn: In a preliminary basis we can describe at a high level the kind of things we need to see tested.
... For example HDR images would require images with HDR coding in them. That's a high level test.

<tmichel> ttml2 and ttml3 repos : added Glenn and Nigel as Admin.

Pierre: Can we change this specifically to TTML2 2nd Ed and constrain it to editorial features?

Glenn: We could add a ttml3 tag and include moving new features to ttml3.

Pierre: Just this one requirement.

Andreas: It makes sense to fix bugs in 2nd Ed, we don't need a big discussion.
... All new features are new requirements so I expect them not to be in TTML3. If there are important
... ones then they need to be submitted, but that period is over.

Pierre: I totally agree.

group: [discussion of handling this requirement issue]

Glenn: I will change the issue title to Resolve open issues to TTML2 2nd Ed.

Pierre: thank you

SUMMARY: TTML3 issues to move to new repo, this issue to cover TTML2 2nd Ed changes only, @skynavga to triage issues.

Support live contribution of TTML tt-reqs#3

Nigel: Given the agenda I think we can only scan through this now and will need to come back to it tomorrow.

Pierre: Do you see this as a core part of TTML3 or an add-on?

Nigel: Good question. I would happily see this as a TTML3 module for dealing with sequences of
... TTML documents arriving over time and define any additional syntax and semantics that are needed.

Pierre: Then that can be adopted independently.

Glenn: Re modularisation, I would make fine changes to enable new modules to be layered on top of
... what is already there. There are issues like namespace, conformance processing, the document
... processing module that can be tweaked to enable these without making in-depth changes. That's
... my thinking. What I don't want to do is to think about breaking off, say, styling, timing, animation etc
... and creating N new rec-track documents for each. That would be nightmarish and not possible
... within the timeframe of this year. It would enable new modules to be added on like this which would
... be a separate Rec track document.
... In regards to Charter we need to figure out if every module is a separate Rec track document. I think
... the answer is Yes, if we take the CSS approach.

Pierre: I like that.
... If a module turns out to be universally used...

Glenn: We can bring that back in.

Nigel: I wouldn't though.
... If you have a Rec track document there's no advantage to bringing it in.

Andreas: I propose a separate module to allow live processing of TTML.
... At the time of publication it is a separate module which still has the possiblity to merge later if there is a need.
... Then for live use case I have a question about the profile and the syntax.
... EBU-TT Live is a subset of TTML. I assume in the module you would not publish a profile that subsets,
... just the additional vocabulary you need and a profile.
... Then the question is where does it live, would you have a separate profile of IMSC that includes the
... module.

Pierre: That makes sense. The separate module relieves the pressure on TTML, and allows the market
... to react to it.

Andreas: You need something to experiment with, the module itself is not enough.

Glenn: We need a modularisation framework that enables features to be brought in.
... For example a convention that allows features to be prefixed.
... We need to find a way to integrate and that's part of the modularisation framework.

Pierre: Andreas, you're saying that if there's a module then IMSC still needs to be modified?

Andreas: Yes

Pierre: What if we don't know it is useful at the beginning?

Andreas: There's no implementation of the complete set of TTML2. There is a need to say what it is used
... together with, in practice.

Pierre: Sure, unless it is completely outside the scope of IMSC.

Andreas: The benefit to have it now in W3C scope is to use it together with something standardised by
... W3C which is IMSC. Otherwise the situation does not change and we get to EBU-TT Live.
... In EBU-TT Live you have timebase clock supported for example which is not in IMSC. I think it makes
... sense to discuss tomorrow if IMSC and this module can be brought together.

Glenn: Right now we have two namespaces, one for core and another for extensions. Each module could
... define its own feature namespace URI and define minimum requirements for integration into other
... profiles that use that module, and say for example that profile foo needs to support minimal feature set.
... And in addition define new features for labelling the module as a whole.
... That's part of what I was thinking about with the framework.

Nigel: I have a concrete example here which is a prototype of what Glenn describes, in the TTML in RTP
... IETF proposal, where we will be adding a processor profile that defines an extension feature describing
... how the times are handled.

Pierre: I have no objection to adopting this requirement especially if this is a separate module.

Glenn: It makes it easier if other Editors can take on modules.

Andreas: Tomorrow we can come back to this but it now makes sense for EBU to contribute EBU-TT Live
... as the basis for a new module. I think everything is already written.

Nigel: I agree, there's editorial work needed, and probably we should write less than what is in EBU-TT Live.

Glenn: Presumably the existing work is in an EBU namespace. I've objected to bringing into the TTML core
... foreign namespaces but I won't to doing so in a module.
... It would create a possible block to incorporating into the core in the future.

Nigel: That's useful.

Glenn: It might make is easier and improve interoperability too.

Nigel: +1

Pierre: One last thing. Who is going to be the Editor here, because I don't think we can accept a requirement
... for which there is no resource.

Glenn: Good point.
... I see two decisions. One is to make it a module pending a modularisation framework, and two is
... designating an editor, and it won't be me.

Nigel: It's up to the Chair to designate Editors, and I am happy to designate myself as well as anyone
... else who wants to additionally do it.

SUMMARY: Consensus at this stage to proceed with this requirement, as a new Rec track module to be Edited at least by @nigelmegitt.

Nigel: I think we need a Charter addition here to allow us to define new Rec track documents as part of
... a modularisation approach. Thierry will that likely be okay?

Thierry: Yes.
... Do you want also to be able to define profiles as well as modules? We can add that too.

Glenn: I view it as the base module definitions will define features and then those can be used by
... profiles as needed. The profiling system supports that.

SUMMARY: Add option for modules to the draft Charter

Audio Description profile of TTML2 tt-reqs#4

<github-bot> nigel, Sorry, I don't understand that command. Try 'help'.

github: https://github.com/w3c/tt-reqs/issues/4

Nigel: This is for a Rec track profile of TTML2 (or TTML2 2nd Ed) based on the existing work in the AD CG.

Andreas: So the idea is first to publish a new document which would be a profile like IMSC is a profile,
... and to make any additions or tweaks in TTML to make it fully compatible.

Nigel: Yes

Glenn: Another Rec track document basically?

Nigel: Yes

Glenn: Is there a designated Editor?

Andreas: Are we deciding now on the changes to TTML2 or just on this document.

Nigel: I'm not sure if there are any tweaks now, it may be that we want only to adjust the range of values
... that, say, tta:gain takes.

Pierre: That complicates things significantly.

Nigel: I don't think so.

Glenn: It pushes it to TTML3. We can make cases for adding values if it was left out by mistake and
... clearly needed to support the functionality that was implied.

Nigel: I don't think so, this is a mistake I think, where the range of tta:gain was discussed but what went
... in the spec was a smaller range.

Glenn: That's in a grey area, it sounds like it could be fixed in 2nd Ed.

Andreas: I added to the issue the f2f meeting of the AD CG because there were a lot of interesting ideas.
... I'm not sure how much they would be in scope for the proposed document.
... For example having more on the required processor behaviour.
... It's clearly not in TTML2 yet so the question is if you see this in scope for this new rec track document
... and if it would be more a new module than a new profile.

Glenn: It sounds like there may be more impact than just one document here.

Nigel: Yes I think so. The semantics are informatively described in TTML2 so we could either make them
... normative and more detailed in TTML2 2nd Ed or make them normative in the profile.

Andreas: It would be good to get a harmonised approach with browser manufacturers so they could
... implement the same or a similar concept.
... Also something not in TTML2 is that a processor needs to pause the video if there is not enough time
... for the descriptions.

Nigel: That's a good point.

Andreas: I want to check that this is in scope of the work.

Nigel: Yes the profile could say something about playback behaviour, which is beyond the scope of TTML.
... In terms of the Editor question, at the moment John Birch is editor in the CG, and I can ask if he is able
... to continue that here - he is a member of TTWG. I'd like to make myself an editor but am worried about
... the effort needed to do it, and chair, and look after the live subtitle work.
... We do have an editing opportunity here for anyone who wants to take it on, I think.

Pierre: It sounds like we don't have a commitment at this point?

Nigel: At the moment John is editor of that profile.
... There was a stated intention in the CG to move this to the TTWG so that won't be a surprise.

Pierre: Great.

PROPOSAL: Accept this requirement for TTWG work in 2019 and add to the 2019 Charter.

Nigel: Any questions or comments before I finalise that?

RESOLUTION: Accept this requirement for TTWG work in 2019 and add to the 2019 Charter.

Nigel: I've moved the milestone on this issue also.

Fade in/out tt-reqs#11

github: https://github.com/w3c/tt-reqs/issues/11

Andreas: This has been contributed by someone who works in the field of subtitles.
... We have to ask if it is already solved, and if there is already some syntax or mechanics, is it appropriate
... and user friendly enough to be used for the requested feature.

Glenn: I asked the original commenter two weeks ago for further input asking if they believe there is
... something not accommodated by TTML2. I haven't heard anything back since Dec 20 it looks like.
... My current assumption is there is no technical feature being asked for, possible a desire to support
... in IMSC. I think we can close this issue. We can reopen it if the commenter comes back.

Nigel: I see there's no response from the commenter. I also observe that there is an overlap here between
... this, the karaoke and the CSS extensions requirements, so it may be that we meet the requirement
... by reference to one of those others. If it is needed I think it would be needed in IMSC also.
... It is not obvious to me how this can be done in a user friendly way at the moment.

Andreas: Glenn said that he asked Pablo Romero Fresco if he agrees that TTML2 already meets the
... requirements or if he objects. As he did not respond then he would like to close the issue. I encouraged
... Pablo to file this issue because he has the requirement and he is not familiar with TTML2. I also saw
... some value in what he requested. I also said to him that if he's not familiar with the technology then
... I would help out which I'm happy to do.
... First I also support this requirement and would not like to close it.
... The important thing for now is to say this requirement should be met by TTML or IMSC.
... I would support that. Until we have not proven that it could be met by existing vocabulary then it
... should not be closed. I agree with Nigel that the current spec text does not satisfy it completely,
... especially in a user friendly way.
... How this is done is a separate issue. I can imagine some dedicated vocabulary like fadeIn or fadeOut.
... Most important is to bring this into scope, for now I would leave it open.

Pierre: Did you see the example that Glenn provided?

Andreas: Yes

Pierre: Is that too complicated?

Andreas: Pablo asked for key frames and control over the speed so I'm not sure if this is enough.

Glenn: We have spline and keyframe and interpolation modes. All that is being asked for is present.
... User friendliness is not a criteria that we have applied to any of this technology up to now.
... For me this needs a champion within our group, who would be responsible for determining the answer.

Andreas: I will champion this.

Glenn: I probably would not be inclined to support new shorthand properties for this but you could make
... the case that it is some higher level thing that could be translated into TTML syntax.
... I don't mind leaving it open if there's a champion.

Andreas: I am happy to do it. I think you're right that we need a balance for user friendliness, and we may
... not need to add anything new. User friendliness does indeed play a role in TTML, otherwise there would
... not be different syntaxes for, say, color, but this could be delegated to another time.
... We first see if technically it meets the requirements.

Glenn: There is a principle at stake called Maximum Orthogonality which we have applied as a strategy
... in TTML which says one should not define alternative ways to do the same thing.

Andreas: But we do.
... One addition: I think the request is also to have this feature in a used profile of TTML and the only
... one I know is IMSC, so there would be a request to add it there.

Glenn: On this particular issue there was some back and forth on labelling, I guess we can leave this
... open for the time being if you are going to take it forward Andreas.

Andreas: Yes, there's no real policy on labelling so it does not represent a decision and I'm fine with any labels.

Glenn: I didn't have an objection to Nigel's change here so I didn't make any noise on this issue.

Pierre: In terms of the requirement is it on IMSC to support this at the end of the day?

Andreas: Yes

Pierre: The challenge I have is who will make the implementation effort to make it happen?
... Is the one interested party the tip of the iceberg or is that it?

Andreas: I heard it also from other directions. Although it may not be a super critical feature.

Pierre: I think we need those users to show up somehow.

Andreas: The question of how we measure the weight of the feature - often it is sufficient if one member
... presents the case.

Pierre: I haven't heard form Movielabs on this.

Glenn: I haven't heard from Netflix on this.

Nigel: There's an interaction here with responsive, CSS, karaoke: essentially we need to be able to specify
... or interpolate word timings and have some presentation effects dependent on those.
... I think Cyril suggested time markers which could be relevant too.

Glenn: Once upon a time we had a different timing model in TTML presented by John Birch and that took
... a lot of time, which in the end we had no implementations for. What you're bringing up now is
... asking if we need some small amount of that. I'm open to thinking about it again but it's a complicated
... area for sure. Writing in processing semantics for such heuristics is not straightforward.
... In the context of karaoke I think we are going to run into this again so I think we will have to bite the
... bullet and look at it.

Andreas: I hear what Pierre is saying and that there needs to be sufficient support for new features, so
... I would ask if other stakeholders would take it up, and if they think it is needed. It needs a balance of
... workload in what we can achieve this year.
... I think that counts of course for every feature. I would also look at the HTML group's process for how
... they consider new features for adoption.

Pierre: We have to have this input.

Glenn: Here's a link for dynamic flow

Pierre: What do we do before we have critical mass of interest?

Andreas: I would leave it open for now.

Pierre: The question is do we schedule it for 2019? I would object to it unless we know there are people
... who will be testing it, implementing it, paying for it.

<glenn> https://www.w3.org/TR/2010/CR-ttaf1-dfxp-20100223/#style-attribute-dynamicFlow

Pierre: In the case of IMSC we have checked it is really what industry wants to do.

Andreas: OK I will check that.

Nigel: We wanted to come to a decision here but at the moment we don't have consensus to proceed
... with it or to say no.

Andreas: What is the process if we do not have a consensus on a feature.

Nigel: I propose that we proceed with this but note for ourselves that there is additional risk associated
... with this feature, which can be mitigated by getting more adoption or implementation input. Actually
... this risk applies to everything we do, but in this case it has been flagged up early. If we don't get
... enough input on this then the default should be we defer it until such time as we have enough.

Pierre: How long will it take Andreas to get additional feedback?

Andreas: End of March because I will be out of the office most of February.

Pierre: Can we make it earlier if there's strong interest?

Nigel: When we come back at the end of today we will have looked at karaoke and other additions and may
... have a change of view.

Pierre: Right now I think we can't accept it. By the way I'm not questioning the applicability, as this is used
... today in digital cinema.

Andreas: I think Nigel's compromise is a good one for now.

Pierre: I'm saying that one person alone is not enough.
... If we can't get input on this until end of March let's not schedule it for 2019.

Glenn: Some groups like CSS have an implicit operating rule which is to say that if no browsers implement
... then nobody will pay any attention to it. We should do something similar with respect to the content
... community, and if we have insufficient interest then it is not adequate.

Andreas: Whatever approach we take it is quite similar, if we don't take it in now but take it in later. It is the same thing.
... For me there is not a clear basis and transparent basis for external people, when a feature has
... sufficient support and backup to be expected. We now discuss it, so we do not have a clear statement,
... and until then we cannot just say now we need more.

Pierre: Ultimately it is the consensus of the group, the AC and the Director that counts.
... It could be that at the end of March this is a high priority thing.
... I would rather say without closing it that we don't schedule it in 2019 and revisit it when there's
... more input, which could be tomorrow, next week or at the end of March.

Glenn: I want to remind everyone that new technical requirements need to be accompanied by test content.

Andreas: I'm not happy with this, and maybe process-wise we need to deal with the case where we do not
... have consensus. Does that mean it is out of the list?

Nigel: Consensus does mean no objections, normally. Here I think the only objection is due to lack of
... perceived interest, which could change. I mean, the BBC's requirements include transition effects too.
... They're in the CSS requirement.

Andreas: I could take this if we apply the same rule to everything else. I cannot accept introducing new
... barriers now. We said that the requirements would be open for a certain time but we didn't say more.

Glenn: The Chair is responsible for determining whether we have consensus and also whether to overrule
... an objection, and if he declares consensus in the presence of an objection then there's an appeals process for that.

Nigel: That's correct in terms of process. For this specific thing I think we need a checkpoint later like
... FPWD where we know for certain if we have enough resource and input, and if we don't then we defer it.
... There are at least 2, maybe 3 or 4 sources for this requirement.

Glenn: This requires TTML3 for significant features. We could easily put an example or a note in TTML2 2nd Ed
... describing how to use animation features in for fade in or fade out, giving us some place to point to
... for people who ask questions about it.
... I think I have somewhere an open issue that says "add more animation examples" so I may already have
... an issue for that, in the 75 open issues.

Pierre: I don't agree putting this into IMSC in 2019 given the current level of backing today.

Glenn: I would support Pierre's position on this.

Pierre: I don't think it should be closed though, just not scheduled.

Nigel: Okay so we can still make progress and schedule it in for 2019 later if there is backing.

Pierre: I agree. There's huge testing effort but probably it is straightforward from a specification perspective.

Nigel: Andreas, can you live with that?

Andreas: Yes

SUMMARY: Not currently scheduled for 2019, pending additional input of resource to test and implement.

<glenn> testing

Spoken subtitle tt-reqs#13

<inserted> scribe: nigel_

Nigel: There's been good debate here. The function is in wide use especially in Europe, and we have
... some support in TTML2 but not for IMSC.
... I think the gap is in signalling.

Matt: The use case is for blind or partially sighted people which would typically be subtitled not being

<inserted> scribe: nigel

Matt: able to read the translation. Some broadcasters can transmit the text, say in Dutch, for the box to
... present as an additional audio track, so a Dutch speaker listening but unable to read the words on screen
... would have some audio representation of the text translation of the English into Dutch.

Pierre: OK, so stupid question - you could solve with alternate audio channels.

Matt: Bandwidth limitations mean its more efficient to deliver as text.
... The TTS is done client side usually. It's a very small user group who needs this.

Pierre: Assuming the client gets a TTML track, the client could do TTS on the track without any change.

Matt: You need some markup to distinguish ordinary captions vs text to speech

Pierre: Like forced but for audio?

Matt: Exactly. If I did this in Teletext it would be a separate stream.

Glenn: The use cases describe TTS of existing subtitles on the client side in companion screen.
... That's done, check!

Nigel: No way, there are loads of gaps there.
... If you'd tried to implement that you'd find them.

Glenn: Discount the companion screen, that's out of scope.
... OCR is out of scope
... Screen reader is an application specific thing, out of scope.
... 4th bullet is confusing because it talks about speech to text, which doesn't make any sense.
... The last one is application level and out of scope.
... I conclude that we don't have anything to do here because everything is out of scope.

Nigel: I don't agree on all of those things, I think you've thrown them out of scope too easily.
... Take TTS of existing subtitles, this is conditional and we don't have any way to signal in the TTML
... which text needs conditionally to be spoken. Even if you take out the semantic description, we still
... need a syntactic option.
... Screen readers are interesting because we don't provide any guidance to implementers on how to make
... captions or subtitles available to screen readers, and I think we should.
... I agree with the others though.

Gary: In videoJS we have something related. The audio descriptions, the descriptions kind for text tracks,
... and one of our accessibility people, when the audio description is displayed on the screen we allow
... screen readers to read it, whereas by default we don't allow screen readers to read captions.
... We allow people to have screen readers read out those captions.
... And so a potential solution is instead of marking up particular cues in the TTML file for reading aloud,
... have a direction to say that if something needs text to speech, provide a separate file.

Pierre: That's the direction industry has taken for forced subtitles.

Gary: Then it would be a standard TTML file with appropriate labelling.

Andreas: The question is if the labelling should be in the TTML or outside.

Gary: Easier outside probably.

Pierre: For forced narrative many folk wanted it inside the TTML, the direction is to have separate files.

Nigel: I would take the opposite view which is to support the player not processing multiple files simultaneously,
... so in BBC we prefer the forced approach.

Glenn: You said a few minutes ago there is no supported syntax but I disagree with that. We have the
... extensible ttm:role and ttm:role and general metadata.
... It is a huge mistake to start trying to push application semantics into the core of TTML language and
... we should resist that every time it comes up. However if there is a consensus in the content industry
... on particular metadata that helps with interoperability then it would be reasonable to propose modules
... that define application specific metadata in that regard.
... It would be a big mistake to put this into the core of the language. We have to find a balance between
... standardisation and innovation on the part of the industry. Some standardisation occurs by writing down
... existing practices and others on speculating on the industry need. The latter fail so my guidance is
... extreme caution.

Andreas: First, maybe it makes sense to separate it because if you have a TTML file and give it to a client
... you usually give it to a rendering application for subtitles which wouldn't do audio rendering.
... The other question to you Nigel is how you see the overlap with the audio description module, because
... the target audience is the same and the goal is very similar.

Nigel: Good point. I find it very difficult to distinguish this use case from audio description.

Matt: I 100% agree and struggle to understand what other than practice would change.

Pierre: Lots of systems do silly things like deployment issue.

Nigel: From a metadata perspective, there's a gap there for driving presentation behaviour because we
... don't do that with metadata. We may want to add a ttm:role value for "translation" which is absent now.
... If we handle this as AD only then there's nothing to do.
... If we handle it as interleaved, then the TTML2 condition construct could be used based on an application
... parameter that says "play back translations", then a conditionalised style that includes tta:speak to trigger
... TTS of that content.

Andreas: I would like to propose that we transfer the main part of the request to the AD module and see
... how it could be solved by that. There is certainly a request to add a metadata feature to TTML2 to
... identify the relevant parts. We not only need so much scope on the rendering part, it is possible to label
... on the production side and decide later how to render and play out as audio. That could be the path
... for us. Outside our group it would be useful to have a workflow overview that shows how to use TTML.

Glenn: The use of metadata to affect presentation semantics - I agree we have avoided that for core
... semantics but I don't draw the same line for application level semantics, so I wanted to make the point
... that it may be appropriate to define metadata or additional namespace qualified vocabulary not using
... our metadata at all. The question is if it is worth standardising on it and if there is a community that
... can agree to a common set of meaning. That's where pushing innovation is dangerous.

Nigel: There is signalling in HTML and DVB for example and this is in wide use, it's not just innovation.

Glenn: There is precedent with forced for writing application semantics into the condition system.

Pierre: I suggest we summarise what we think the requirement is. We arrived at something a lot more specific
... to summarise on the ticket.
... I didn't hear anyone say we should not do this, so I think we should accept it and move on.

SUMMARY: We think the requirement here is to signal translations, and describe (potential) workflows for triggering TTS based on translations.

Glenn: I would like to confirm that speculation with the author of this issue.

Pierre: We should ask the commenter if they agree, that sounds good to me.

Nigel: I'm happy to do that.

SUMMARY: Check with @porero
... Flag timed text as a translation so that it can be used to drive text to speech.

Pierre: On much modern content there is both a caption file and a translation subtitle file, the latter is
... 100% translation.

Matt: In that scenario the caption file would just be descriptions of sound effects. The two would interleave.

Pierre: In this definition, what's the difference, couldn't you just text to speech all the translation subtitles?

Gary: That's my question, do we want to limit to hard translations?

Matt: That goes back to Nigel's comment about a player constraint on one TTML file being active.
... In that case there needs to be a mechanism of identifying what content needs to be spoken.

Glenn: We decided not to interleave languages in the same file.

Nigel: This is all same language though.

Glenn: For me it is an application policy. If you're authoring in TTML you might use different stages and
... merge them upstream or downstream.
... I don't agree to anything until I hear a better description of the requirements.

Pierre: I think someone should write down what we think the requirements are and go back to the submitter.

Nigel: I'm happy to do that.

SUMMARY: @nigelmegitt to try to recast the requirements as per the TTWG discussion and check in with @porero.

Review backlog issues for IMSC tt-reqs#14

github: https://github.com/w3c/tt-reqs/issues/14

Pierre: I'd like to narrow this to 2nd Edition of IMSC 1.1 rather than a new edition.
... I don't think "review backlog" is a requirement.
... We can fix errors and apply editorial improvement, but permitting embedded image is a brand
... new requirement that would potentially be IMSC 1.2 or IMSC 2, so on this one we should deal with
... editorial errors.
... That's #465 and #469 for example.
... Just like we said for TTML2 2nd Ed earlier.

Nigel: I just added #469 to the issue.
... And removed #82.
... Shall we just say we'll do this?

Pierre: Yes I'm happy to schedule this for IMSC 1.1 2nd Ed

Nigel: Do we need to do it in IMSC 1.0.1 too?

Pierre: No we should not touch that now.

Nigel: OK
... Any other views on this? Do we have consensus to proceed?

RESOLUTION: Proceed with this requirement in IMSC 1.1 2nd Ed.

Add generic CSS property functionality tt-reqs#2

github: https://github.com/w3c/tt-reqs/issues/2

Nigel: [summarises requirement]

Glenn: The title says "CSS property" which I'm happy to see because it does not say "CSS Selectors".
... I want to confirm here that the ask does not include CSS selectors, which would make things enormously
... more complicated.
... I can see a straightforward path to supporting CSS properties.

Nigel: What's that path?

Glenn: 1. Put it in a separate module.
... Define a new attribute tts:cssStyle= and then a value space that is a set of CSS properties, and define
... the semantics so that if both apply in some circumstance then the TTML property... we'd have to
... establish a priority for when there's an intersection, let's say tts:color and tts:cssStyle="color: XXX;".
... If a system did not support the CSS style mechanism then I would presume that the TTML property applies.
... If it supports the CSS property applies then the CSS property could be designated to win, but I'm open
... to it being the other way around. I don't have a strong opinion on that.
... That would be the simplest path.

Andreas: That sounds like a feasible approach. Two comments also on the thread. First, we need to make
... sure that there's really a defined behaviour if you apply CSS properties inside the TTML style and layout
... system so that there is a deterministic rendering behaviour. That does not have to be true always because
... TTML does not rely on CSS but on XSL-FO. The second thing is I would like our long term strategy
... to align TTML and CSS. We had discussions with CSS WG 2 years ago and we had agreement to bring
... it closer however it may look. The target was TTML3 at that time.
... I think this first idea could be a transition phase. In general it would be worthwhile to meet the CSS WG
... about this approach and in the long term plan consider how CSS could be handled, if it could be a way
... to make timed HTML rather than TTML.

Glenn: I would like us to limit the scope of this particular requirement to what the title says, which is
... adding generic CSS properties. Andreas it sounds like we're on similar thinking in that regard, details
... to be worked out. What I do not want to mix in with this is any discussion of general long term
... migration to a new as yet defined language that would not be TTML if it is intended to diverge from
... an XML based language. I do not want to include that in this issue.
... I don't object to someone opening a new issue defining a timed version of HTML5 with a migration
... path from TTML but in my opinion that's not part of TTML standardisation, it is part of a new language
... that could potentially be done in this working group. It would certainly require a new Charter entry, and
... strong buy-in from the content community. Personally I think it's a bad idea and would divert precious
... resources from an already diverse implementation field by introducing yet another language
... ostensibly with the same goals but a different syntax. If that ever comes up under a proposal for a
... new Charter Skynav will object to it formally because we don't think it is justified by the industry or any
... particular use case.

Nigel: Thanks, Glenn that's my 3rd bullet effectively. Another is to add a feature designator, which I
... don't think is contentious.
... Another was to add a class attribute to allow external stylesheet support. That would need us to define
... how to populate the class attribute of every element in an ISD.

Glenn: I think supporting external CSS stylesheets and selectors would be a step further and would like
... to exclude it for now. It would make it harder to get consensus - I would object to it, for example!
... I'm sort of in the middle on the properties themselves. I am trying to be amenable to your proposal Nigel,
... I see the utility in having a system that facilitates rapid adoption of CSS properties without going through
... a language iteration on TTML, and it would facilitate future modules where if we see a particular
... property being very important we could bring it in to TTML directly as a TTML style attribute.
... That would certainly enable some movement on your requirements Nigel.
... It does make things complicated and creates interoperability problems, for example TTT is probably
... never going to support CSS style properties.
... It would have to be behind a feature for sure.

Nigel: That is part of the proposal.

Glenn: On your last bullet about precedence, it would obviously depend on whether your system supports
... CSS properties. I'm open to either direction for precedence.
... I feel that CSS is somewhat of an overwrite and am not convinced on that yet.

Pierre: What happens with inheritance? Do you inherit CSS styles like you do TTML styles?
... What if the inheritance rules are not the same in CSS and TTML? What about different length units?
... What's the interaction? What's the viewport?

Glenn: Exactly, there's a whole different terminology.

Pierre: Directions and padding are both different.

Glenn: Individual properties are challenging. Syntactically it is easy, testing is hard.

Pierre: The thing I have never fully understood is, in order to import additional styles, that can be done
... with extension attributes, literally tomorrow. BBC can experiment to its heart's content, and if it is
... successful and useful it can be added later. With a use, implementation, examples, semantics it is
... trivial to add. I do not understand why this does not meet the requirement.

Nigel: One of the requirements is low overhead of adoption, what you're describing sounds like high overhead.

Pierre: From an imsc.js perspective it is always high overhead - the property has to be parsed, inherited etc.

Andreas: [scribe missed]

Pierre: The hard part is mapping the semantics of e.g. viewport related units. The hard part is not in the
... syntax of the attribute.

Glenn: Adding the modularisation system might make it much easier to add new style properties than
... has been the case in the past.

Pierre: Exploring modularisation, the modules can use the TT namespace, so the module can introduce
... a new property, get it to FPWD, experiment with it, tweak it, then publish it, without having to change
... namespace and all that stuff.

Glenn: This goes to the modularisation framework. We enumerate all the style properties in a table. We
... are going to have to do something to make that table extensible so that we don't have to change that
... table every time we add a module that defines a new property.
... When we have the modularisation framework in place it should be a much easier process to push out
... a spec for one or a few related properties. I can see it being used on a group of semantically related
... properties.
... I could see this turning into three requirements: 1. class and selector, 2. new language, 3. CSS property support.
... It would be much easier to process these if we divide it into multiple issues or requirements.

Andreas: First I think what is different from Pierre and Glenn is to have a clear selection of what can be
... supported specifically, i.e. which CSS properties. And then figure out what are the problems with
... applying it to TTML and finding a good way to represent it syntactically. I'm not sure if we need to agree
... on this today, but maybe we do need to agree today is that it is worthwhile not just to open the door
... but make a selection of what needs to be supported and deal with the difficulties of each property.
... I would also see it as a different module and a list of style properties. Would that satisfy your original
... intention NIgel?

Nigel: I think it could, potentially. One other idea as a sort of middle ground is to create a module that
... defines some generic ways to add CSS properties, and maybe adds some available CSS units, and then
... via a registry we could whitelist specific CSS properties, adding them by consensus of this group, and
... for each understanding the potential overlap and clash with TTML style attributes and how to handle
... any such clash.

Pierre: How do you see that a registry would be less work than updating a working draft?

Nigel: I wouldn't propose to keep updating a WD, because that never gets to any kind of standard.
... I'd propose a generic Rec and then a dynamic registry.

Pierre: From an implementation standpoint you haven't solved anything.

Andreas: What would the publishing process be for the modules? I thought they would not be Rec track?

Glenn: They would have to be Rec track.

Pierre: That's the idea.

Nigel: +1

Andreas: Then each time you want to update you have to iterate.

Pierre: Sure.

Glenn: You might have one module defining property 1 and another defining property 2 and each time
... you rev that you have a certain level of work to do, but we can control the granularity.
... The TTML3 document itself would need to have some framework and mechanisms to enable the
... modularisation process.

Andreas: Then I agree if the module goes through the process then a separate registry would be duplicate
... work.

Glenn: Let's say the CSS extensions module exists and just refers to a registry, in which we bless the CSS
... properties for use.
... Then there's a quasi-generic module that does not enumerate the properties but refers to a registry.
... Technically speaking we don't need the registry but that gives us a process for blessing uses which
... makes it better for testing. If we make it completely open ended then we have no control over testing
... or blessing uses. Given there may be semantic issues with impedance mismatches to deal with.

Pierre: I would make it a WD that we update rather than a registry.

Glenn: The other option is just to define new TT style properties directly in new modules.

Pierre: I would go down that path from the beginning, because the work will be the same in the end, no
... matter how you cut it.

Glenn: Then that is an alternative option, to promote fine granular modules for making extensions to
... the existing suite of style properties by having, say a border style extension module and that we define
... some number of tts: property names that deal with the border issues that Nigel wants to deal with.
... The turnaround on that module could be much shorter, for, say, flex.

Nigel: Bad example in the context of TTML!

Glenn: You're right Pierre the work has to be done somewhere no matter what.

Andreas: What is different, the work may be similar, but the turnaround time to publication is different.
... The general mechanism like Nigel proposed could be done fairly easily, camelcasing and so on, and we
... could bring this through the process to Rec, but if you combine it with a first list of features, then you
... possibly get stuck with each feature to add. If we separate it then the general mechanism is first, and
... if someone wants to do it then they can do in a standardised manner.

Glenn: The risk is with interop where content authors start throwing in CSS properties right and left and
... make use of application specific processors and JS code to do this.
... Then interoperability might decrease as a result. We would have less control over testing.

Pierre: The argument I hear is that the Rec track is too slow?

Nigel: Yes, we want to be able to access CSS features that already on Rec track with minimal additional delay.

Pierre: TTML is not HTML, you cannot just adopt CSS properties so easily.

Nigel: CSS is not restricted to HTML either!

Andreas: Concerned about time for this and other issues we have to cover. Also as an AC rep there's a
... large number of Recs to review.
... We haven't dealt with this modularisation yet, so we should not try to solve it now.

Nigel: Thanks for that, I think other organisations are interested in the requirement too but we don't
... yet know the acceptable solution.

Glenn: I just want to make clear that if we do semantic mapping it is a non-trivial process that we cannot
... put in a generic module definition. It would have to be on a per-property basis. Otherwise the only
... option is to put the semantic mapping nowhere or in a registry.

Nigel: Where are we up to here?

Pierre: I haven't heard anyone speak against an easy path to adding style properties to TTML.
... The obstacle to doing this on the Rec track should be minimal overhead and we're talking about how
... to make it happen.

SUMMARY: Group agrees to look for ways to add new style properties with minimal overhead and to try to solve this in 2019.

Cyril: There are two parts - adding new style properties and adding the class attribute. Are they both in scope?

Nigel: There was some push-back against adding class

Glenn: The overall goal to reduce overhead is shared.

Add embedded image support to IMSC Text Profile tt-reqs#15

github: https://github.com/w3c/tt-reqs/issues/15

Pierre: Remind me why fonts wouldn't solve this?

Nigel: It's not interoperable and it is not accessible.

Glenn: You can use private use area easily.

Nigel: You have to manage authoring and distribution fonts carefully.
... Also there's no text alternative.

Cyril: You can use glyph substitution so there is a text alternative.

Glenn: It's implementation dependent.
... You can embed the font in the document to ensure the private use area usage is consistent.

Nigel: If we can't use glyph substitution then you have the accessibility issue. There's no text alternative.

Pierre: You can put altText on the span containing it.

Cyril: If you have text in English how do you select altText in English.

Glenn: You can use it you can do whatever you want with it.

Cyril: Yes so you can't use it because there's no semantic defined.
... Is glyph substitution implementation widespread?

Glenn: g subtable

Vlad: Yes it is universally implemented and supported in all browsers.

Glenn: So native TTML renderers or translators like imsc.js it is not supported unless you map the font
... into the browser world and pass along the string, maybe it could be supported that way.

Vlad: Just to give me a bit better understanding of the subject, what do you think would stop this?

Glenn: For gaijin characters, and emerging emoji.

Nigel: And things like company logos.

Glenn: The idea is to use a downloaded or embedded font and use PUA code to map to a glyph.

Nigel: Or glyph substitute a set of characters like "twitter" to the twitter icon.

Vlad: That works - for example the word Zapfino in the Zapfino font gets replaced by a logo for the font.

Pierre: If you go to a text alternative as a fallback there's a bigger issue that it may require a different layout.
... The entire idea of having an image fallback be unstyled simple text doesn't work very well. How do you
... specify the style (color, italics) of that fallback. That's why in IMSC you have a separate file for images.
... The text equivalent of image is not always what is written in the image.

Vlad: Remind you that fonts can have glyphs defined in SVG and that glyph can be selected when conditions
... are right. It will still be text for all intents and purposes.

Pierre: When you substitute long text with one emoji that might affect the layout significantly.

Vlad: I agree

Pierre: that is a significant issue here.

Vlad: Rendering differences are not as bad as they used to be. Using a particular font is probably the only
... way to make sure the rendering is right. Assuming that some font will be right is wishful thinking.

Glenn: We don't define line breaking or space distribution semantics so implementation dependent.

Cyril: Pierre raised an interesting point, the layout. I agree replacing a small image with 10 or 20 characters
... is a big change. Focusing on the requirement, is there any objection to the requirement being agreed?

Glenn: I have a problem with the requirement because it is written in terms of images not text.

Pierre: What about recasting it in terms of glyphs?

Cyril: Using inline images with alt text does the trick, right?

Glenn: That's the traditional way with gaijin.
... We have a terminology issue with Text and Image profiles each being constrained.

Pierre: The entire discussion so far has been really about custom characters, right?

Nigel: Yes, I don't think we want to support generic pre-rendered text in an image into text profile.
... However the change doesn't make a substantive difference.

Cyril: You can put any image into the font though, right?

Glenn: Correct you could.

Cyril: You want to say that if you don't make fonts available the content of the file should be human readable and carry the content?

Pierre: I don't agree with that

Glenn: I don't see that as a requirement.

Cyril: I'm not sure of the requirement, we're talking about solutions.

Pierre: This is for visual elements as text.

Nigel: The only requirement that ties it to text is to size the image using the font size.

Glenn: Also font kerning, spacing, scaling etc are all affected by laying out as text.

Nigel: Recasting, the request back seems to be to support custom font embedding in IMSC Text profile.

Pierre: That is how it is done in ARIB-TT.

Cyril: I don't think it is the same thing.
... This is not the gaijin character use case. That gaijin is readable, but the private use area character is
... not readable.

Pierre: It can be a cartoon.

Cyril: It is not accessible, as Nigel explained earlier, if you don't process the font the text is still readable
... by a screen reader.

Vlad: I've been listening to the discussion. As far as the requirement is concerned there are three
... requirements that should be connected.
... 1. Support custom fonts by embedding
... 2. Support of inline images as part of text (not how it can be done, but that seems to be the requirement)
... 3. (blanking out on that!)
... Having font embedding functionality is a way to support inline glyphs.

Nigel: Also we need a screen reader to do something sensible here.

Glenn: The two options are potentially orthogonal solutions to this problem.

Vlad: Not necessarily.

Glenn: The embedded font is more consistent with treating this as text and is more compatible with the
... text profile which does not include image, but as has been pointed out it might not satisfy some
... screen readers but I think they are out of scope.

Nigel: No way are screen readers out of scope.

Vlad: Accessibility was my third requirement.
... All those requirements are valid concerns and there may be one solution that satisfies them. If we can
... agree on the requirements that would guide us and many other implementers on the solution.

Andreas: Can we bring this to a close (time)?

Cyril: I agree with Vlad's phrasing and support all three of those requirements.
... We could use this heavily at Netflix.

Glenn: I do not agree that we have separate requirements for embedded glyph and image support in text.
... They are two different scenarios for solving one requirement, which is to support the ability to display
... as text some form of an image either as a glyph or an inline image characters for which there is no
... standardised visual representation. There's probably something on accessibility too if you cannot
... display the rendering. I view Vlad's first two requirements as two different solutions to the underlying same requirement.

Nigel: +1

SUMMARY: Solution options available, need more thought and investigation, overall requirement to find some way to present images like glyphs are presented, in an accessible way, is accepted.

Support 3D space (360°/VR/XR) as target presentation environment tt-reqs#8

github: https://github.com/w3c/tt-reqs/issues/8

Nigel: Thank you for dialling in Peter, I'm going to take what you say as coming from Andreas as IRT for the purpose of IPR.
... Summarise the requirement please?

Peter: The work comes from a research project with a couple of other broadcasters, investigating
... accessibility services in VR/360º environments.
... We tried to put a workflow together with existing standards.
... There are a few gaps. The one corresponding to subtitles I presented here. The first requirement
... I put there is formulated quite generally.
... The main issue is we need to find a way to refer 2D space in IMSC into a 360º or 3D environment.
... It can be done technically, that's not a problem, we did it with some implementations and user testing
... but there's no standardised way to do it.
... We know there is more and more 360º content on the web or VR stores. They sometimes have
... subtitles but the quality is often very poor so we see a need to improve it and bring the features that
... IMSC has already into that new environment.
... The requirement is that a way is provided that 3D environments can be used as a target rendering area,
... relating the 2D subtitle into the 3D environment.

Nigel: Is that representing a position in 3D space?

Peter: Yes that's the main thing needed, and to describe what this position could be exactly.
... For example if we link the centre of the rendering container to a 3D environment.
... There are different approaches for that, and this is what my addition to this requirement is about.
... I described what we are doing and there is another approach I described.

Glenn: Peter, we have in TTML2 appendix H on root container region semantics. We would have to find a
... way to merge or integrate 3D into this model to make effective use of what is being proposed here.
... Maybe it would be useful for you to review that appendix and make some suggestions for how to tweak
... the model to include the Z axis, if we are talking about Euclidean geometry.

Pierre: It could be spherical or cartesian models.

Glenn: Is the proposal primarily spherical?

Peter: We used spherical angles to describe it but it is a matter of translation from one to the other.
... We have a concrete implementation but it doesn't really matter how this is expressed. There are good
... reasons for how. We need good definitions for how to standardise.

Andreas: The main part in terms of time is to focus on the decision if we want this requirement as a new
... feature in TTML3.
... 1. Do we understand the requirement?
... 2. Is there enough backing from content providers?
... 3. Are there implementations?
... For the second part there is a need in the industry - maybe Vlad can come in. For implementation Peter can say more.

Vlad: To try to add more clarity. Looking at this issue, the use cases span over 360º video and immersive
... reality. For subtitles, if we consider 360º and 2D being basically the same, you paint an object that
... occludes anything else in the video. If you do exactly the same in immersive reality domain, when you
... occlude something behind an object, and the occlusion is located behind the object then that's the kind
... of occlusion that creates conflict in the human brain - when it happens it breaks down the perception
... of the stereoscopic scene.
... This is why depth position is such an important requirement for subtitles.

Andreas: You are also in the VR industry forum that has the issue to resolve.

Vlad: That is not a standards organisation, it helps guide the industry, but has a different scope.

Nigel: Is the requirement to identify a 3D location associated with a content element independently of
... the region?

Vlad: Yes that is one of the requirements.

Nigel: Is it enough to associate zero or one 3D position and allow the implementation to do the presentation to meet user requirements?

Vlad: Yes, that is definitely one piece of the puzzle.
... Also the content provider may want to associate an on-screen object with the character in the video.
... For example if I want an avatar per person in the screen I may want to define that in addition to the
... location, and my content may want to use that icon to associate the symbol with something outside
... the viewport.
... Another use case is that the content creator would want to use something as well as a directional arrow
... to identify where the speaker is.

Andreas: Can we agree there is a requirement to add some specification text, vocabulary and semantics
... to position a content element or region in 3D space?

Cyril: I'm not opposed, I'm wondering where the most appropriate place is, a separate module or appendix H?

Glenn: We have defined a pan audio property which is effectively an angle on the horizon, if you multiply
... the range of -1 .. 1 by pi you get the full range. I wonder if that could be used to support the first of
... the two solutions that were suggested here. I realise we defined it for audio not 3D per se.

Nigel: I'd almost go the other way and support audio positioning in 3D space rather than the 1D pan parameter.

Glenn: I would support making this a module and it may require modification to appendix H also.

Andreas: Is this TTML3?

Nigel: I think it needs TTML3 and IMSC as it has been put.

Pierre: I think IMSC is a longer path. There's a desire to put things in TTML before IMSC where possible.
... If we want to go down that path TTWG is going to need to coordinate closely with other organisations,
... I would hate to be inconsistent with other efforts. We need a champion for this. MPEG has a significant
... effort there.

Peter: Yes we recently sent from the VR industry forum a letter to MPEG asking questions about their
... suggestions for handling subtitles in 3D. They also support IMSC in their OMAF draft and I think there
... are still some gaps so they try to provide that link from their side. It is true that needs to go hand in hand.

Pierre: The first step here is to write down what we want to do and make sure it is consistent or if not then
... it is for a good reason, then once there is interest adding to IMSC is a simple editing task.
... There's a lot of work to do first.
... If someone is wiling to do the work, then yes, it's interesting.

Glenn: This would definitely be a module.

Andreas: IRT would possibly champion this. We already made a start with Peter working with other
... standards organisations in the direction Pierre requested. We need to figure this out but possibly we
... will try to push it in this group.

Vlad: I think that similar to previous discussion there are two separate issues. First is to agree on the
... requirement and then how. It sounds like we are all in agreement this is a requirement to adopt and
... how is a secondary issue.

Nigel: That's a nice summary, thank you Vlad. Any dissent on that?

Glenn: IRT would provide an editor for a module?

Andreas: No we haven't decided how to do that. I cannot commit to it yet.
... Can we defer the editor discussion for now?

Pierre: OK then this is 2019 contingent on an Editor.
... I don't mean someone to do typing, I mean caring about it, aligning with other efforts etc.
... Someone to really make it work.
... I should say a more generic champion for this rather than an Editor.

Peter: For me it is hard to estimate how much work it would be so I cannot commit to it now, which maybe
... is what Andreas is saying, it's in our interest to follow up on this.
... I see that people start to do it in one way or another and probably within the project and now after
... it only works in a closed environment. It would be good to avoid letting different variations appear, which
... is happening already.

Pierre: I share your concerns!

Andreas: Can we proceed with what Nigel proposed? We have interest but cannot commit today.

SUMMARY: Group discussed this, generally supportive, contingent on effort being available to make it happen.

Add support for embedded images to IMSC Image Profile tt-reqs#16

github: https://github.com/w3c/tt-reqs/issues/16

Nigel: This seems pretty straightforward?

Pierre: I asked a question on w3c/imsc#82 - someone called @shobanaberlin mentioned fragmented MP4 HLS.
... I've received no response to my question.

Gary: It's in the HLS RFC.

Pierre: Right, fMP4 supports images so I don't understand this comment. There's literally an MPEG spec
... for embedding images in MP4.

Glenn: What has that got to do with this requirement? Aren't you raising a separate issue?

Pierre: No because you don't need to embed in the IMSC document if you can embed in MP4.
... The commenter asked for a way to get images in fMP4 and there is literally a spec for it so I was trying
... to get more information on it. I haven't seen the use case where it is impossible to do it other than
... embedding in MP4 then we could do it, but big XML documents filled with base64 encoded images is
... not great.

Cyril: I'm with you here, there's a spec here for doing it as binary blobs, referenced by MPEG.

Nigel: We have a significant concern here, a better alternative way of doing it in ISO/MPEG 14496-30,
... and no support, and no feedback from those who commented.
... We have consensus to close this without taking it forward.

RESOLUTION: Close this issue.

Support for Responsive Timed Text tt-reqs#10

Peter: [has to leave]

github: https://github.com/w3c/tt-reqs/issues/10

Nigel: Cyril raised this and I supported it. Does anyone have anything bad to say about it right now?

Pierre: I think this approach is worth a try.

Glenn: My conclusion is requirement 1 is already supported and requirement 2 is problematic.

Pierre: Problematic in the solution or the requirement?

Glenn: I see it as an ask to support event based timing.

Nigel: I don't see that.

Cyril: I am not married to the marker proposal.
... The idea is to provide not line break opportunities but event based opportunities.
... It could be a conditional timing hierarchy for a given unit of content.

Pierre: This is a really important topic. I don't know the answer, but if we succeed it will really help the
... industry so we should give it a shot.

Glenn: One solution is to produce different documents.

Pierre: There are multiple combinatory choices

Glenn: This is also needed for karaoke where we have an algorithm for pushing content into a display
... region dynamically.
... You can't reuse IDs so that's off the table.

Pierre: Setting aside the solutions, do you think the requirement is relevant?
... Looking at the images.
... Being responsive to those different aspect ratios.

Glenn: I haven't given enough thought but it seems something worth considering.

Andreas: From our side we think it is an important requirement.
... Making responsive web content is important and it would be good to do the same for TTML.

Glenn: It is only the splitting that is an issue.

Vlad: I agree it is important to be responsive in this way. I like the way you put it Cyril but the samples
... don't go beyond line breaks and text size, you don't do it justice, but the requirement is good.
... Responsive design and typography, i.e. using full scale variability using variable font support, which
... every browser does with CSS support and we are talking about scaling font from condensed to wide.

RESOLUTION: We will attempt to meet these requirements in 2019.

Minor enhancements for Japanese subtitles tt-reqs#12

github: https://github.com/w3c/tt-reqs/issues/12

Nigel: If CSS has done this then we should do it.

Cyril: We should work with CSS and adopt what they do.
... I'm not asking for doing this without CSS support.
... This is mostly about edge cases not fundamental Japanese language support.

Nigel: So Cyril does that mean you will take the lead with CSS WG to get these defined?

Cyril: I will try!

Glenn: This is the case where a module to define this would be appropriate and can be tracked to a
... timeline that matches what CSS is doing. We can do things in parallel with modules without having to
... waterfall it all together.
... Then we can explore with CSS their interest in solutions, and propose something to them and see how
... they react to it. I have no strong feeling on whose solution we adopt, the one we came up with or something new.

Nigel: Anyone want to speak against doing this?

RESOLUTION: Proceed with additional Japanese language features in a TTML3 module in close coordination with the CSS WG.

Support for Karaoke tt-reqs#9

github: https://github.com/w3c/tt-reqs/issues/9

Nigel: This is closely related to some of the other issues we discussed earlier, including granular timing and transitions.

Cyril: The use cases are quite different. It is not about responsiveness but transition styles, not about
... changing the layout. We would like to signal the semantics of karaoke separately from the styling.
... For example ingesting IMSC content with karaoke styling and then we would decide what karaoke means
... and apply styling ourselves, or in the document.

Glenn: Without agreeing with the specific requirements or proposed solutions I'm in favour of moving
... forward with some kind of requirement for supporting karaoke. I need to digest this a little more and I
... also want to look at what ARIB-TT did because they defined some support for karaoke that I haven't
... looked at in detail. It is something to map to a module if possible.

Nigel: I see a lot of overlap between different requirements today, for example the text emphasis style
... seems to have something in common with the inline image requirement.

Pierre: Emphasis style allows a quoted string so you can have the emphasis be whatever you want.

Cyril: Okay that's a potential good solution.

Glenn: It could conceivably even be an animated glyph because you can use SVG animation in an embedded font.

Cyril: I'm interested in animation between words not within the glyph.

Nigel: Isn't this a completely new layout requirement for animating a moving ball between words?

Vlad: It is and strictly animations are not permitted in SVG glyphs.

Cyril: I am fine with this in a TTML module but what about IMSC, maybe a karaoke profile?

Pierre: One data point supporting getting it into IMSC at some point is that IMF supports karaoke without
... this key functionality. I suggest doing the TTML3 module first and then if there is industry support
... adding it into IMSC as a small change.
... Then if it doesn't have to be part of IMSC by end of 2019 that makes it a lot easier.

Cyril: Instead of IMSC 2019 being published on the same date as TTML3 then we could pipeline them and
... that would make it easier.

<Vlad> SVG glyph limitations as defined by the OpenType spec: https://docs.microsoft.com/en-us/typography/opentype/spec/svg#svg-documents

Pierre: We said we would try to publish all new specifications by end of 2019 and pick requirements based on that target.

Glenn: To raise the modularisation approach we should be motivated to minimise what we have to do in a TTML3 baseline document
... so we get it out the door more quickly than the modules we define functionality in, by focusing on the
... framework for modularisation as the key thing in TTML, then focus in parallel the modules that take
... advantage of that framework. Then we decouple to a certain extent getting IMSC to a particular gate.

Pierre: Makes sense to me. If we think we get it done by June in TTML3 then the feature in IMSC by the end
... of the year is feasible.

Andreas: Is this issue accepted?

PROPOSAL: Take up the karaoke requirements in 2019

Glenn: There are a bunch of requirements, 6 of them, I don't know if I would agree to all those at this time
... but I think we should move those forward.

RESOLUTION: We will take these requirements forward for our 2019 work.


Nigel: Wrapping up very quickly because we're over time.
... Today we went through all the requirements issues that were open, and made a call on them where we
... could, and we agreed to create a modularisation framework for TTML to allow us to work on orthogonal
... functionality in separate Rec track documents. I have the action to draft the TTWG Charter update
... to grant us permission to do this, which I will do in the next month.
... We meet same time tomorrow, 0830 Geneva time, and will revisit the Live requirements.

Andreas: If someone could draft timelines for our work that would help.

Nigel: Thierry has that action.

Andreas: We need a plan for the modules work.

Pierre: Could the glue be added to TTML2 for modularisation because it doesn't affect conformance?

Glenn: Let's take that up at a later date.

Cyril: I may not be able to join tomorrow because of the timezone.

Nigel: Thanks everyone. Enjoy your evening, I'll adjourn the meeting now. [adjourns meeting]

Summary of Action Items

Summary of Resolutions

  1. Accept this requirement for TTWG work in 2019 and add to the 2019 Charter.
  2. Proceed with this requirement in IMSC 1.1 2nd Ed.
  3. Close this issue.
  4. We will attempt to meet these requirements in 2019.
  5. Proceed with additional Japanese language features in a TTML3 module in close coordination with the CSS WG.
  6. We will take these requirements forward for our 2019 work.
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/01/31 17:27:48 $