See also: IRC log
<cyril> scribe: cyril
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
nigel: we have 4 PR to review
<nigel> Timed Text Charter Pull Requests
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
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
<nigel> github: 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.
Gary: This is waiting for comments on the pull request for the snapshot.
<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> Philippe's CfC email of 14th March
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> 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
nigel: we have one issue "add module framework"
<nigel> github: 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
nigel: we have 3 proposals
https://github.com/w3c/ttwg/issues/30
nigel: people should add other options if they want to
<nigel> scribe: nigel
Nigel: Liaisons have been sent, need to follow up on one of the VR-IF recipients because the email address didn't work.
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.
Nigel: Thanks everyone, sorry for running 6 minutes over. [adjourns meeting]