- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 21 Mar 2019 17:33:12 +0000
- To: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <D8B97AEA.3FB32%nigel.megitt@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2019/03/21-tt-minutes.html
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
21 Mar 2019
[2]Agenda
[2] https://github.com/w3c/ttwg/issues/27
See also: [3]IRC log
[3] https://www.w3.org/2019/03/21-tt-irc
Attendees
Present
Cyril, Nigel, Gary, Glenn, Andreas, Pierre, Philippe
Regrets
Thierry
Chair
nigel
Scribe
cyril, nigel
Contents
* [4]Topics
1. [5]this meeting
2. [6]TTWG Charter
3. [7]TTML Profile Registry Actions, Pull Requests and
Issues
4. [8]Clarify codecs parameter syntax requirements (#63).
tt-profile-registry#69
5. [9]WebVTT Implementation report
6. [10]mark at-risk features in a new snapshot webvtt#449
7. [11]TTML3 Pull Requests
8. [12]sept F2F meetings
9. [13]Liaisons to MPEG and VR-IF
10. [14]AD CG
11. [15]Meeting close.
* [16]Summary of Action Items
* [17]Summary of Resolutions
__________________________________________________________
<cyril> scribe: cyril
this meeting
nigel: there is a lot to get through
... good to have 2 hours
... lots to discuss
... main topics will be charter
... TTML3 modules
... to make sure we have a consistent language
... some time for WebVTT
... actions to MPEG and VR-IF
... actions also to propose options for the Sept F2F meeting
... there are some PR for TTML3
... any AOB?
glenn: some PRs on Profile Registry
TTWG Charter
nigel: we have 4 PR to review
<nigel> [18]Timed Text Charter Pull Requests
[18] https://github.com/w3c/charter-timed-text/pulls
nigel: the issue was to make sure the new requirements that we
agreed, labelled requiring charter revisions, are supported in
the charter
... there was live contribution
... from EBU
... current charter already says to consider things from EBU
and other similar groups
... given that, we came to an agreement that we don't need a
significant charter change
... so the PR does not need much change
... there is only one line in the scope section under TTML3
... the main part that needs to change is about supporting
Audio Description
... there is a scope and deliverable section that points to the
CG report
... the scope is publish a recommendation
... a profile of TTML for Audio Description
atai2: on the first point, live streaming, we want to work on
live contribution which is a bit different from streaming
... it should not be an alternative to HLS streaming
nigel: agree, I'll add a comment to the PR
... back on Audio Description deliverable
cyril: could the profile be of TTML3?
nigel: It could be but all the features seem there in TTML2
pal: we have to be careful
... we should reserve TTML3 for significant features that would
impact conformance in a significant way
... because the timeline for TTML3 is not the same
glenn: I agree the profile should be a TTML2, if it does not
use TTML3 features
pal: can the charter be silent?
... I'm concerned with the charter be restrictive
glenn: I agree, the less we say the better
nigel: this can be changed
... I'll omit TTML version number
... expected completion are intent but can be moved
... the other update is in coordination, adding ADCG
... any other comment?
... next one is "Increase scope to include maintenance of all
Recommendations"
... the change is simple, be less specific
... about the versions of the spec to maintain
... comments?
... next one is "Update text re meeting schedule"
... the meeting schedule currently requires to meet at TPAC but
we don't necessarily want that
... the new text says meeting at least once a year, usually at
TPAC
... next "Add wording permitting TTML3 and a modular approach."
... there has been discussions in different places about the
language we use here
... it seems that we've converged on the idea that TTML3 is a
thing whose collective name is not really agreed, and each
document is a specification
... some other specifications will be defining modules
... the changes proposed by glenn in TTML3 is a module registry
... we need to know if the module registry is a deliverable
glenn: it would be the same as the profile registry, i.e. a WG
note
... the registry is not the thing that pulls them together
... the registry will list the existing internal modules
... and serve as a list of external module
pal: we are creating so much burocracy
... what problem are we trying to solve by having that in the
charter
... I love the idea of modularization
glenn: I agree we should say the minimum in the charter
pal: for example modules could be done for a 2nd edition of
TTML2
nigel: I'm happy to make this vaguer
glenn: it's good to inform AC members about the intent of the
group but we don't want to have every line item cited here
... we need to find a balance
nigel: what is the minimum we need to say?
plh: I'm thinking ...
... I don't think there is a minimum
pal: what does CSS do?
nigel: it says they will publish modules
... it says CSS is a specification consisting of modules
... the snapshot says it gathers specifications
pal: can we say the product of the group is a core
specification, profiles and modules
cyril: agree
nigel: possibly
plh: at the end of the day, the scope section defines the range
of IP affected
... what this group is working on
... if it ends in one spec or ten specs
... it does not matter, unless some AC have strong feelings but
they should be in this group
nigel: ok, so let's try to go minimal
... do we even need to say we will publish TTML3?
plh: not necessarily, not in the scope
... in the deliverable, we'll have a list of the existing
publications
... for TTML3 we can provide vague wordings
... like "the next version of the spec made of one or mode
documents"
nigel: what about notes?
plh: not necessarily
... but registry can be listed
nigel: we'll say in the scope "publish recommendations for new
TTML specifications as needed"
... in the deliverables, at the moment there is a TTML3
... I need to add that it may consist of one or more documents
cyril: we could leave '3' out
nigel: how important is the "update working draft" section
plh: that's important because if you join the group, you commit
to it
... for those that don't exist, you're commited only after
publication
... and that list will be generated by W3C
... we are tracking that
... despite your attempts to have multiple repos here and there
nigel: there is a wording change non controversial in success
criteria
... because we might publish notes that could be interpreted as
specifications
... and I don't want them to be interpreted regarding that
section
plh: one set of thoughts related to the naming, whether TTML 3
or TTML Snapshot
... you can call it whatever you want
... it's more of a marketing question
... from the process it doesn't matter
... but it's not simple to make noise about it
... we won't present each module in the press
nigel: that's a consideration of the modular approach
plh: it might make it harder to communicate about what TTML is
nigel: I think we have a bit of answer already
... make the noise about profiles
... like for Audio Description
<nigel> Cyril: Re the success criteria, it's all about
specifications, you could make it a bullet point list
plh: btw, CSS Snapshots are not recommendations, just WG notes
glenn: I generally oppose publishing snapshots documents
nigel: I think one of the problems of getting different specs
to recommendations is getting the impetus for tests
... if we do what we said, provide tests with spec, we should
not be stuck in CR
plh: regarding success criteria, would there be value in taking
consumers of TTML more into account
... for example for the VR module, do we want to make sure we
have at least one consumer that is able to understand the VR
module
nigel: in the past, we required at least one presentation
processor
... I think that point can be addressed when we think of CR
exit criteria
plh: ok, it can be pushed to exit criteria for each module
nigel: iterating through the other 3 issues: fix the timeline
(to me), assign chairs (to plh), and WebVTT (assigned to
nobody)
... my proposal is to leave these issues as is for the moment
plh: sounds good to me
TTML Profile Registry Actions, Pull Requests and Issues
pal: given that Mike Dolan is not here, I recommend skipping to
TTML2 and TTML3
... we need the right people on the call
glenn: I'd like to discuss PR 69
nigel: let's discuss PR 69 then
Clarify codecs parameter syntax requirements (#63).
tt-profile-registry#69
<nigel> github:
[19]https://github.com/w3c/tt-profile-registry/pull/69
[19] https://github.com/w3c/tt-profile-registry/pull/69
cyril: I miss some context on why we don't want to change the
IANA registry
glenn: my recollection is that we do not need to update the
body of the media type
... we did make one change to remove one misleading sentence
which should not trigger IANA review
cyril: what is wrong with triggering IANA review
<inserted> scribe: nigel
Cyril: The note should be in section 2 not section 3.
... The syntax of the codecs is being defined in section 3.
Glenn: Those are requirements on registration
Cyril: The requirements are as they are to meet the
requirements of the codecs parameter.
... My problem is we don't formally define the codecs syntax.
Glenn: Yes we do, under Section 2, codecs.
Cyril: It's defined by example only.
Nigel: If you're worried about the syntax of the operators and
where it is defined, Cyril, that's pull request #70.
Glenn: Looking at the note here, is there any argument about
the correctness of the statement?
Cyril: I'm arguing about the location, it describes an effect
not listed formally anywhere else.
... I can raise an issue for defining codecs in section 2
Nigel: I think that would be the right approach.
Cyril: I will raise the issue.
Glenn: Please could you remove your "request changes" review on
#69?
Cyril: Let me think about it.
WebVTT Implementation report
Gary: This is waiting for comments on the pull request for the
snapshot.
mark at-risk features in a new snapshot webvtt#449
<cyril> scribe: cyril
plh: I sent the email last week, we have some comments in the
PR that have been addressed
... if people have issues with republishing the document as
proposed by Gary in two weeks
... people should speak up, one more week to do so
<nigel> [20]Philippe's CfC email of 14th March
[20] https://lists.w3.org/Archives/Public/public-tt/2019Mar/0023.html
nigel: is that a call for consensus
plh: yes
nigel: any update on the implementation report
gkatsev: I added a new tab as result of API parsing
... some are failing because the tests are out of date
... I need to update the tests
plh: i'm assuming that if there was any red flag we would have
marked it at risk
... how long should we stay in CR?
... the minimum is 28 days
gkatsev: we should go with the minimum
<nigel> scribe: nigel
Cyril: There was a question about support for what Netflix
regards as essential Japanese features.
... The response was not clear to me, about if it is supported
and to what extent.
Gary: I'm not sure exactly the specifics. A lot of support in
WebVTT comes from the rendering engine like HTML, so
... Ruby is supported and a lot of the rtl and other features
are only available if the vendor supports them.
Glenn: So to do Ruby you have to do the CSS styling for Ruby
technique and then associate a stylesheet with the WebVTT
document?
Gary: You can use the ruby and rt tags.
Glenn: Directly in the text in WebVTT?
Gary: Yes. As for other Japanese features I am unsure.
Cyril: What about vertical text?
Gary: I believe that is supported via CSS.
Cyril: I thought there was a line level setting to set the line
layout to vertical?
Gary: Yes there is a vertical setting.
Cyril: Do you have a pointer to the tests that demonstrate
rendering interop for this feature?
Gary: There is a test for ruby support, I'm not sure about
vertical
Nigel: [can't find it]
Gary: [can't find it either]
Cyril: If you could offline send pointers to the tests for
ruby, vertical text?
... For ta te chu yoko and bouten you're saying it's CSS only?
Gary: I think that is currently the case, yes.
Cyril: Okay, and we don't have tests for that, right? The test
suite for WebVTT doesn't mandate CSS and there's no
... section of the tests that includes CSS?
Gary: We do have tests for styling support, yes.
Cyril: And those tests don't test the Japanese features, right?
Gary: Yes
Cyril: Ok, maybe we could add them?
Gary: I could take a look at that.
Pierre: What happens if a CR is republished and the test suite
is not sufficient. Another CR?
Philippe: No, it requires that the test suite is completed.
Nigel: We've done this before, worked on the test suite during
CR.
Pierre: The danger is that if during the test suite development
new at risk features are needed then that's a setback.
Philippe: Yes you have to republish.
... One thing is that we don't want to test CSS and rendering,
just WebVTT.
Cyril: I only want to know if Japanese support is present, so
it seems reasonable to have tests.
Philippe: If WebVTT doesn't have anything specific for Japanese
then we should not test HTML.
... It's not the job of WebVTT to test everything in HTML.
... You would be asking if HTML supports Japanese.
Glenn: The answer is WebVTT has no support for Japanese but
allows for pass-through syntax of Ruby and CSS styles
... that puts all the burden on the presentation engine to use
HTML and CSS to do Japanese formatting.
Andreas: I need to get my head clear on this, so apologies -
WebVTT lists certain CSS features, not all of them, that it
... supports through the pseudo cue setting. Where WebVTT says
it supports it, even by delegation to CSS, it is needed
... to test that it is rendered correctly by sufficient
applications. They are critical features for rendering
subtitles.
... Either they are supported or not, otherwise you would say
that WebVTT would not support colour, say, so of course
... it should be tested with WebVTT that the CSS based
rendering actually comes out correctly.
Nigel: The purpose of the tests is to demonstrate
implementability - I think you're pointing Andreas at the idea
that
... we want to ensure there is no accident that the CSS styling
actually cannot be implemented.
Cyril: I agree that the purpose of the tests for the CR process
is to demonstrate implementability interoperably and
... maybe the CG has the job to demonstrate that WebVTT can
solve classes of problem in presentation especially on the
... internet.
Philippe: Are you looking for pass-through tests with ruby
markup in it?
Cyril: David Ronca's email lists 5 things for which we have no
evidence from the WebVTT tests that it can do them.
... 1. Vertical text - a core feature with no tests.
... 2. Ruby - also a feature of WebVTT.
... 3. Bouten, 4. Ta te chu yoko, 5. Slanted text - possibly
not core features of WebVTT and reliant on CSS, so maybe
... for those the CG could demonstrate (not for CR) that the
features can be supported.
Pierre: The spec does define conformance directly related to
CSS, it's not entirely a pass-through.
... It's not entirely true that it is a pass-through.
Glenn: It does not detail specific CSS style formatting, and
all the features you're talking about here are specific
properties,
... bouten is text-emphasis, ta te chu yoko is text-combine,
and vertical is writing-mode.
... Potentially also ruby-align and ruby-position properties
also. There are at least 5 properties.
Nigel: Slanted text?
Glenn: I don't think CSS has anything to support that directly
right now.
Pierre: Correct, there's no shear.
Nigel: There's a kind of shear isn't there, but not the right
kind, i.e. it's on the wrong kind of element.
Pierre: It is definitely not what is needed, ideally. It
doesn't match the expectation of authors.
Philippe: That sounds like a CSS issue not a WebVTT issue.
Nigel: Every CSS property that is needed must be on the
whitelist in WebVTT because everything else is ignored.
Philippe: Correct. Are you saying some needed CSS properties
are not on the whitelist?
Pierre: Pointer to the whitelist?
Gary: §8.2.1
Pierre: I see.
Gary: So text-combine: upright; is allowed.
Pierre: Thanks for pointing it out.
Nigel: Sounds like something to follow up offline.
Glenn: And verify all those properties I mentioned are on the
whitelist.
Pierre: Some of the properties that are needed are in draft but
not on the whitelist because they aren't ready today,
... like fill-line-gap.
<plh> [21]https://www.w3.org/TR/webvtt1/#the-cue-pseudo-element
[21] https://www.w3.org/TR/webvtt1/#the-cue-pseudo-element
Glenn: I just mean the ones I listed.
Pierre: text-emphasis is in CSS but not on the whitelist.
Glenn: ruby-align is not there.
Pierre: No because it's part of the ruby one... maybe not.
<scribe> scribe: cyril
TTML3 Pull Requests
nigel: we have one issue "add module framework"
<nigel> github: [22]https://github.com/w3c/ttml3/pull/30
[22] https://github.com/w3c/ttml3/pull/30
nigel: cyril asked for some text to be removed
... I believe it has been removed
cyril: let's go ahead, I'll review and raise an issue if needed
nigel: I asked for a change on the name module
... the request is to define a module as elements, attributes
or specs for that
glenn: that's how I view a module
cyril: what about the term Module in TTML2
glenn: those are defined and go back to TTML1
sept F2F meetings
nigel: we have 3 proposals
[23]https://github.com/w3c/ttwg/issues/30
[23] https://github.com/w3c/ttwg/issues/30
nigel: people should add other options if they want to
<nigel> scribe: nigel
Liaisons to MPEG and VR-IF
Nigel: Liaisons have been sent, need to follow up on one of the
VR-IF recipients because the email address didn't work.
AD CG
Nigel: I've initiated a sequence of 4 meetings of the AD CG on
Tuesdays at 1100 UTC (based on a poll to find a meeting time)
... and the first one was two days ago. Please feel free to
join, and I can change the time if that's helpful.
... The goal is to tidy the document to be ready for this group
to begin taking it on.
Meeting close.
Nigel: Thanks everyone, sorry for running 6 minutes over.
[adjourns meeting]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [24]scribe.perl version 1.154 ([25]CVS log)
$Date: 2019/03/21 17:26:15 $
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[25] 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, 21 March 2019 17:33:39 UTC