- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 31 Jan 2019 17:29:58 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <5941EAB8802D6745A7D363D7B37BD1F7AD8CE49A@bgb01xud1012>
Thanks all for attending today's face to face meeting at the EBU in Geneva.
Minutes can be found in HTML format at https://www.w3.org/2019/01/31-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
31 Jan 2019
[2]Agenda
[2] https://www.w3.org/wiki/TimedText/F2F-jan-2019
See also: [3]IRC log
[3] https://www.w3.org/2019/01/31-tt-irc
Attendees
Present
Nigel, Glenn, Thierry, Pierre, Andreas, Matt, Gary,
Silvia, Cyril, Vlad, Peter_tho_Pesch, Mike
Regrets
Chair
Nigel
Scribe
nigel, nigel_
Contents
* [4]Topics
1. [5]Introductions
2. [6]Agenda and working model for this meeting
3. [7]WebVTT Implementation Report
4. [8]TTWG Future requirements
5. [9]Resolve open issues in ttml2 repository. tt-reqs#1
6. [10]Support live contribution of TTML tt-reqs#3
7. [11]Audio Description profile of TTML2 tt-reqs#4
8. [12]Fade in/out tt-reqs#11
9. [13]Spoken subtitle tt-reqs#13
10. [14]Review backlog issues for IMSC tt-reqs#14
11. [15]Add generic CSS property functionality tt-reqs#2
12. [16]Add embedded image support to IMSC Text Profile
tt-reqs#15
13. [17]Support 3D space (360°/VR/XR) as target
presentation environment tt-reqs#8
14. [18]Add support for embedded images to IMSC Image
Profile tt-reqs#16
15. [19]Support for Responsive Timed Text tt-reqs#10
16. [20]Minor enhancements for Japanese subtitles
tt-reqs#12
17. [21]Support for Karaoke tt-reqs#9
18. [22]Wrap-up
* [23]Summary of Action Items
* [24]Summary of Resolutions
__________________________________________________________
<nigel> scribe: nigel
Introductions
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
[25]Schedule for today
[25] https://www.w3.org/wiki/TimedText/F2F-jan-2019#Schedule
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]
[26]# WebVTT implementation report starter
[26] https://docs.google.com/spreadsheets/d/e/2PACX-1vSHzJtwi_2ijdV7hRUH0Fe8qZeSwMaCLErK7w7U_IFzhzNmW9YwPRWrER1eHR9-4Eo0kqyXJ4G35b1b/pubhtml
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: [27]https://github.com/w3c/tt-reqs/issues/1
[27] 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.
[28]Constrain maximum value of @length on data element.
ttml2#1023
[28] https://github.com/w3c/ttml2/issues/1023
[29]Least upper bound on supported time expression values.
ttml1#307
[29] https://github.com/w3c/ttml1/issues/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.
[30]Create TTML3 repos ttwg#23
[30] https://github.com/w3c/ttwg/issues/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> [31]https://github.com/w3c/ttml3-tests and
[32]https://github.com/w3c/ttml3 created
[31] https://github.com/w3c/ttml3-tests
[32] https://github.com/w3c/ttml3
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: [33]https://github.com/w3c/tt-reqs/issues/4
[33] 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: [34]https://github.com/w3c/tt-reqs/issues/11
[34] 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>
[35]https://www.w3.org/TR/2010/CR-ttaf1-dfxp-20100223/#style-at
tribute-dynamicFlow
[35] 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: [36]https://github.com/w3c/tt-reqs/issues/14
[36] 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: [37]https://github.com/w3c/tt-reqs/issues/2
[37] 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: [38]https://github.com/w3c/tt-reqs/issues/15
[38] 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: [39]https://github.com/w3c/tt-reqs/issues/8
[39] 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: [40]https://github.com/w3c/tt-reqs/issues/16
[40] 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: [41]https://github.com/w3c/tt-reqs/issues/10
[41] 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: [42]https://github.com/w3c/tt-reqs/issues/12
[42] 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: [43]https://github.com/w3c/tt-reqs/issues/9
[43] 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:
[44]https://docs.microsoft.com/en-us/typography/opentype/spec/s
vg#svg-documents
[44] 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.
Wrap-up
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. [45]Accept this requirement for TTWG work in 2019 and add
to the 2019 Charter.
2. [46]Proceed with this requirement in IMSC 1.1 2nd Ed.
3. [47]Close this issue.
4. [48]We will attempt to meet these requirements in 2019.
5. [49]Proceed with additional Japanese language features in a
TTML3 module in close coordination with the CSS WG.
6. [50]We will take these requirements forward for our 2019
work.
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [51]scribe.perl version 1.154 ([52]CVS log)
$Date: 2019/01/31 17:27:48 $
[51] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[52] http://dev.w3.org/cvsweb/2002/scribe/
----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
---------------------
Received on Thursday, 31 January 2019 17:30:30 UTC