- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 22 Mar 2018 16:39:38 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <D6D98BE6.58033%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/2018/03/22-tt-minutes.html
We made one resolution:
RESOLUTION: After resolving the current open issues, request transition of IMSC 1.1 to CR on 5th April.
The review period for this resolution, according to our Decision Policy, ends on Thursday 5th April.
The minutes in text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
22 Mar 2018
See also: [2]IRC log
[2] https://www.w3.org/2018/03/22-tt-irc
Attendees
Present
Nigel, Pierre, Thierry, Andreas, Cyril, Glenn
Regrets
None
Chair
Nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]This meeting
2. [5]TTWG Charter
3. [6]TTML1 3rd Ed CR
4. [7]IMSC 1.1
5. [8]Meeting close
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<scribe> scribe: nigel
This meeting
Nigel: Today, we need to cover the Charter, TTML1 3rd Ed CR
transition request,
... not sure if there's anything on TTML2 or IMSC...
Pierre: I think we should plan on going to CR for IMSC 1.1 in
two weeks. There's nothing
... blocking us from doing that.
... That gives us 2 weeks to prepare the transition paperwork
too.
Nigel: OK, let's cover that.
... Any other business or particular points to cover?
group: [none]
TTWG Charter
[11]Draft 2018 TTWG Charter document
[11] https://w3c.github.io/charter-timed-text/Draft-2018-TTWG-Charter.html
Nigel: Thanks to those who reviewed and raised issues on the
repository recently.
[12]Charter repository issues
[12] https://github.com/w3c/charter-timed-text/issues
Nigel: Going through the issues...
... #1 is done, closing.
... #2 is end date.
Thierry: Currently it is end of March 2020. I want to highlight
that all our deliverables are
... mainly for end of 2018 so therefore I don't know how we
will justify that to W3M.
Pierre: Over TPAC I was told many times that it was a shame
that WGs are disbanded and
... unable to maintain their specifications.
Thierry: That's true. There was something in the past that was
life after Rec = 6 months in Charters.
... I don't know what is the case today.
Pierre: I would put 2025, if it were up to me. Something
reasonably far in the future.
Andreas: I understand Thierry's issue here, I also had this
concern, that others might wonder
... why we need the extra time. Maintenance of specs is one
thing. We already have parts
... of what we want to do that go beyond this year. Gathering
the requirements for life after
... IMSC 1.1 and TTML2 will start. We don't have deliverables
yet for IMSC2 or TTML3 but if
... it will happen it will fall into the Charter period. I'm
not sure how concrete it needs to be.
Thierry: My idea was exactly that - to add that we will work on
requirements for next
... versions of TTML or IMSC, to enable us to have a future
version.
Nigel: Does anyone oppose adding that?
group: [silence]
Nigel: I hear consensus that we have that.
... I will add a comment to the issue.
... But what should the end date be?
Thierry: W3M wants 2 years, you could ask for 3.
Nigel: I don't really want to have a battle over this point;
2020 gives us time to generate
... any requirements for new specs. I'm happy with a 2 year
period and then come back
... with new concrete deliverables. Any other views?
group: [none]
Nigel: I've added a note to #2.
... #3 is done, I'll close.
... #4 is about HTML5/CSS3 mapping.
... It's currently worded in scope of TTML2. Can it be a
separate deliverable?
Thierry: I can put it in "other deliverables"
Glenn: We should make the Charter flexible enough to allow us
to subdivide the spec into
... modules.
Nigel: +1
Glenn: I anticipate some features may be pulled out of TTML2
because of insufficient implementation,
... so we may want individual modules for those features, which
would be easier to complete.
Thierry: That's probably an update to the Deliverables section.
I could add this into "Other deliverables".
Nigel: As a refactoring of TTML2 or a TTML3?
Glenn: It can't be a change to TTML2, it has to be a new
version.
Nigel: TTML3 isn't a listed deliverable at the moment.
Glenn: Clearly we should at least imply the possible existence
of TTML3.
Thierry: We covered that in the second issue before.
Nigel: I think this means if our requirements for TTML3, say,
include refactoring then we
... would have to add that as a new Rec track deliverable in
some future Charter.
Glenn: I was not proposing, when I mentioned modules,
refactoring TTML2 into a new TTML3
... that is fully modularised. I was suggesting that new
features could be defined in modules
... while leaving the core of TTML2 unmodularised.
Andreas: I'm not sure if we need to decide already which
applications we work on. The first
... step is to gather the requirements and then find the right
publication form to satisfy those
... requirements. I'm not sure if we need to define that now in
the Charter.
Glenn: Agreed. Don't tie your hands early.
Nigel: Also agreed.
Thierry: Right.
... Will it be normative?
Nigel: I don't think we know if this potential other
deliverable will be normative or not at this stage.
Thierry: Okay, then I should not focus on
normative/non-normative in 2.2. I will probably
... withdraw the "non-normative" statement.
Glenn: Good idea.
Nigel: +1
... #5 Will -> Should.
Thierry: In the Scope intro, bullet 1 and bullet 3.
Glenn: I agree with that change.
Nigel: That's done, will close.
... #6 is about IMSC scope. Non-controversial, done, so
closing.
... #7 is remove 1.4, but Andreas would like it back.
Pierre: I have no objections to putting it back if there is a
volunteer.
Andreas: I think it is fine to have it as a document that could
possibly be updated or maintained.
... And Pierre wanted to remove it as an official deliverable?
Pierre: I understand what you're saying. We should keep it
under 2.2 as it is.
Andreas: +1
Nigel: Okay, there's no change to make for #7 so closing.
... #8 is remove 1.5, maintain SDP-US.
... SDP-US is already in the list of documents that may be
maintained, so there's nothing
... to do here. Closing.
... #9 is about removing the non-measurable objective.
Thierry: This was in the template, but has been removed from
there, so I've removed it here too.
Nigel: Okay, closing this one.
... #10 is clarify privacy and security implications
... Pierre, how much more specific do you want us to be here? I
think it's part of WG work to define what the requirement means
for each specification,
... and we should stay vague.
Pierre: But what needs to go in the relevant section? Is it
within the scope of the current specs?
... I don't feel we should sign up for something unknown.
Thierry: I don't think W3M is requiring more than what we've
been doing so far.
Pierre: That's not what the spec says, what about non-web
authors?
Andreas: Do we really expect complication here? I understand it
as a bit of a vague requirement
... to consider security and privacy. In the context where we
expect TTML to be used we
... try our best to make sure that TTML itself is not a
security risk.
... So exactly what we need to address depends on the context
of use and the time when we
... publish.
Glenn: Since we're free to put whatever we want in that section
we could simply say that
... the concerns don't apply in the sphere of use. All the
Charter needs to say is we need
... to think about security and privacy.
Pierre: "Each specification should contain a section discussing
security and privacy"
Glenn: Sounds perfect to me.
Nigel: Why don't we take the word "Web" out from before
"authors".
Glenn: I like Pierre's text better - it is more generic and
allows us to do what we need.
Thierry: We can try.
Nigel: I've added the new proposed text to the issue.
... #11 Clarify testing plans is next.
... This is in the Success Criteria section. What is the
implication of non-success?
Thierry: The section on test is intended by W3M to start
writing tests as early as possible.
... There is even a trend now adopted by some groups that each
new functionality added to
... the spec can only have a pull request merged if there is an
associated test. We are more
... and more leaning towards having tests and specs in
parallel. The statement does not
... say we must do that though.
Nigel: Right, and there's a link to that also in 2.
Deliverables. My question is what is the
... consequence of not meeting a success criterion?
Thierry: I don't think there is any at the moment.
Nigel: Also what is a "testing plan"?
Thierry: I don't know, I think developing a test suite.
Andreas: It's not so hard for me to understand it, it's just
the strategy for how specs will
... be tested.
Nigel: That's a different thing and it is worth making the
distinction.
Thierry: W3 wants to reduce time for getting to Rec so their
idea is to draft tests earlier.
... Currently it is only a goal.
Andreas: For me it is good as it is, and a good goal, I think
we should try to have this as
... an extra requirement for new features to be added to the
spec.
Nigel: +1
Glenn: That doesn't mean the tests won't change over time.
Andreas: No, of course not.
Nigel: Are we going to leave it in then?
Pierre: There's no "should" here so we cannot be successful
unless there are testing plans.
Glenn: I agree for consistency we should use "should" rather
than implying "shall".
Pierre: It's important to know what we're committing to.
Andreas: But a success criterion is not a requirement, it's a
measure for how successful we are.
... It doesn't mean we have to stop if we don't do it. How I
understand it is we say how we
... want to address testing with our specification, and write a
plan and strategy from the start,
... then I agree that we can have a requirement that there
should whenever possible be a
... test for any pull request that introduces or changes a
feature.
Pierre: I don't want to do this unless we want to do it. So far
we've not been doing this,
... and it requires more resources up front.
Nigel: The success criteria one does not require a significant
change though.
Andreas: I agree we use Should in the success criteria
sometimes.
... Thierry can we add it here?
Thierry: We can put a should.
Pierre: "A testing plan should be associated with each
specification, starting from the earliest draft."
Nigel: That works, and by the way that could be a conversation
in a meeting, with its minutes.
... I've added a comment to the issue.
... #12 Clarify accessibility section
Thierry: This comes from the template, so we've put it in.
<atai2> +q
Andreas: Can we address this by adding a last sentence: "This
will be addressed by 1.e and 3.c from the scope section"?
... It is a general template and they want comparability, so we
can keep it there and say we
... are working on that, so point to the concrete specs. Would
that work?
Nigel: I don't think so - addressing the MAURs is not the same
as saying how we address them.
Pierre: Exactly. I think we should strike out that sentence in
1.2.
Glenn: In TTML going back to the first edition we had an
appendix addressing satisfaction of
... certain requirements set by the quality control group. I
don't know if that's out of date.
Pierre: It's part of my concern that things we add need to be
maintained.
Thierry: Why don't we try to strike that paragraph and explain
to W3M that we are addressing
... it by meeting the MAURs?
Pierre: We're addressing it by the efforts of this group, to
support captions delivery worldwide.
... It is core this group to address accessibility
requirements.
<atai2> +q
<atai2> +q
Nigel: Challenging that, if that's our work, why would we not
write down how we have done it.
Pierre: Someone has to do that work, and unless we can do it we
should strike it.
Andreas: I certainly would be happy to help out with this on
some of the specification.
Nigel: I don't understand how to argue removal of this
criterion to W3M given that it is about
... a description of the intent of our work.
Pierre: Meeting the MAURs does this, we don't need to say any
more.
Glenn: I agree.
Andreas: I understand why this is needed in specs. If people
read W3C specs and know that
... they all have a section on accessibility then it will help
them, with consistency. From my
... understanding this is not a big deal. We could ask W3M what
input they really expect here.
... Also if it would be sufficient to say that our specs meet
MAURs etc.
Pierre: I think this is intended for specs whose primary goal
is not accessibility.
Nigel: My proposal is to leave this in as a "should" success
criterion.
Pierre: I object to that.
Glenn: [has to leave]
Andreas: It's not a big deal I think.
... I see the sense in having it - it's not a blocker for the
Charter if it is absent. I don't
... object to removing it, but if W3M says to add it back in I
don't think it's worth discussing again.
Pierre: I agree with you Andreas, and I would like W3M to
explain the goal here. I'm happy
... to be convinced.
Nigel: My proposal to leave it in is to avoid this argument. We
can defer the decision to the
... activity of the WG later, and make the case. It doesn't
mean that we have any particular
... failure or issue to deal with.
... I would also like to understand the motivation, and note
that it is somewhat vague.
Andreas: Can we take it out for now and explain why?
Thierry: We can try.
... This template is quite new so I have no experience with it
- it came only 3 months ago.
Nigel: I've added a note to the issue.
... #13 is clarify testing requirements.
Pierre: I suggested adding a section on development of
deliverables.
Nigel: Good idea.
... I think it needs to be scoped only to substantive changes
too.
Thierry: That's true.
Nigel: I also think it's about the WG being clear about the
intent of the change, not just about interop.
Pierre: Exactly, it's good software practice.
Nigel: Propose rewording to: "All substantive changes to
specifications should have associated tests."
Thierry: that works
Nigel: I'll add that to the issue.
... #14 is TTML2 expected completion
Thierry: I made the change to TTML2 "Q4 2018" and also in the
required timeline, now it says
... October 2018 in §2.3.
Nigel: Okay, will close that.
... Next is #15, IMSC 1.1 completion.
Thierry: That's the same.
Nigel: I'll close that too.
... #16 Missing TTML13ED deliverable.
Thierry: That one, Pierre wanted to add TTML13ED to the
Deliverables, so I think it is
... doable. It could be that it will be published at least as a
CR before the end of the Charter.
... I hope it will. If that's the case then maintenance will
not be on 2ED but on 3ED.
Nigel: Do we need anything other than maintenance?
Thierry: That's why I put it in generically under the end of
§2.1.
... If we start on this we have to highlight each version of
the Recs.
Pierre: I understand, I am not sure why IMSC 1.0.1 is listed
explicitly under normative specs
... but TTML1 3ED is not.
Nigel: There's an argument that IMSC 1.0.1 introduces features
whereas a maintenance
... update generally does not.
Thierry: Then what's in the Charter is fine.
Pierre: Where is it listed that work is happening to TTML1 3ED?
Thierry: It's an update of 2ED.
Nigel: This is listed at the end of §2.1.
Pierre: OK, that's fine, proceed. I don't understand it but it
shouldn't stop us.
... I'll close the issue.
Nigel: Thank you.
... Next is #17, the requirement for 5 active participants.
Thierry: That was in the template. I had an email exchange and
copied his response.
... I asked him if it is mandatory to have this statement in.
He said you cannot remove it
... but you need to adjust it to reality.
<atai2> +1
Nigel: Counting current active participation, we don't have any
issue with getting 6 today.
... It could give us some margin of safety if we reduce to 5,
say.
Andreas: (That +1 was a typo - I meant to add myself to the
queue)
... At the moment I don't see a big issue here. I checked other
recent Charters, and
... they all have a minimum of 6, one has a minimum of 10. Also
David Singer is the Chair,
... he must be an active participant, and with others, at the
moment I don't see an issue here.
Thierry: I think this is just for starting the group, it
doesn't say if we go less than 6 the Charter will stop.
Pierre: That's exactly what it says.
Nigel: It's an expectation not a requirement.
Pierre: It looks like a success criterion.
Nigel: Shall we do nothing here?
Pierre: So all other new charters do this?
Andreas: I looked at two or three, and they have it. One of
them has 10 as an expectation.
Pierre: alright.
Nigel: I've added a comment.
Pierre: I'll close the issue. Thank you.
Nigel: Next is #18, add text for liaisons with other SDOs.
Andreas: Our group is a central point for timed text, and we
spend a lot of time liaising,
... bringing in other SDOs' requirements. Remember fillLineGap
for example. It's not enough
... listing that we speak from time to time, it's an important
part of our work. Also it is
... important that other SDOs depend on our specs so it's super
important to put their
... requirements in new specs and to maintain the specs they
reference.
Nigel: My counter argument is that this is already stated in
section 3.
Andreas: I'm not satisfied with this. It may be that every
group formally has this requirement
... but it needs to be recognised that this group spends
significant time doing it.
Thierry: My understanding is that what we have in the external
organisations section is more
... about the review expected from the W3C point of view and
what you are saying is that
... we liaise not only on those occasions but also to add
functionality to our specifications,
... which I understand is a bit different.
Andreas: Yes, definitely.
Nigel: So you would add something to Scope like "6. Liaise as
necessary with other organisations including but not limited to
those listed in §3.2"
Andreas: Yes, but also to bring in their requirements.
Nigel: We don't want to commit to meeting their requirements in
all cases.
Thierry: No!
Andreas: Right, so that wording is fine, after removing "as
necessary".
Nigel: I've added that to the issue.
... Next is #19 Add requirements analysis for immersive media
Andreas: I linked to the minutes of the f2f at TPAC and in
Cupertino for this. Both times
... we agreed to add it to the Charter. First it was brought in
by David Singer and I supported
... it and then again in Cupertino.
... Nobody objected to it.
Nigel: My only concern was a technical one, that W3 seems to
want a starting document
... before adding as a Charter deliverable. So I wanted the
steer there.
Thierry: We can work on requirements documents.
Nigel: ok.
... Should we add it as a non-normative deliverable to 2.2?
Andreas: If possible we should add it to the scope.
Thierry: 2.2 already says "use cases and requirements
documents" which is good enough.
Nigel: I'll add to the issue, in Scope: "7. Investigate caption
format requirements for 360 Degree, AR and VR video content."
... Next is #20
... Interaction with WICG
Andreas: We should add WICG to 3.1 W3C Groups.
... I got from Wendy that it's an important new strategy from
W3C, and I think it makes sense,
... and we should signal in the Charter that we will try to
work with them.
Thierry: The only issue I have with this is that during Wide
Review we will have to ping them.
... We could add it but add a conditional statement.
Andreas: Definitely, just to signal we try to do it.
Thierry: I wouldn't want another (additional) group to review
our specs.
Nigel: I don't think WICG would consider it in their scope to
do it either.
... Do we want a subsection of 3.1 to say something like "The
Working Group will work with the following W3C groups with no
requirement for them to provide review of the Working Group's
deliverables"
... and add WICG in that list.
... I'm concerned that this is unnecessary and might be seen as
excluding other CGs,
... which seems wrong.
Andreas: I think we want to promote incubation. It's not just
another CG.
Nigel: I think any CG can incubate a new spec.
Cyril: It would be dangerous to limit ourselves to WICG because
it's very browser based.
... For TTML it's good if we get that feedback but shouldn't
preclude us from defining a feature
... if it is needed.
Pierre: I don't think there's any reason not to send an FYI to
WICG, the question is if that
... is part of the formal liaison groups. That's a pretty
important distinction. An FYI to WICG
... is not a bad idea, but putting them in the critical path is
different.
Nigel: I think what we need here is a statement that says we
will work with other CGs including WICG to coordinate the
addition of new features.
Andreas: My idea was to give a signal first to W3C to say we
think it is a good idea and will try it,
... and secondly to browser manufacturers to tell them that
they need to input into some parts
... of our specs, and using WICG would be good to get it going.
If other members have
... strong concerns to put it in I'm fine to leave it out.
Nigel: I've added text to the issue to reflect this.
... Next is #21 Implement WebVTT resolution
Thierry: I was very uncomfortable removing WebVTT, but if you
consider this Resolution
... then it should not be there.
Andreas: I remember this but I think it is very clear that some
members would like to have
... more time to bring WebVTT to CR.
Nigel: Okay, I'm raising this so that it is tracked. Right now
including WebVTT in a new
... Charter would be contrary to the Resolution, which David
Singer and Philippe agreed to.
Andreas: I think we should leave WebVTT in the draft Charter
for now and we need input from the other Chair.
Pierre: It's really hard to have this discussion without the
proponents of WebVTT on the line.
Nigel: I agree.
... Let's move on with no change for now.
... Next is #22 Require maintenance of registries
Thierry: I will add registries in under Other non-normative
documents.
Nigel: I've added a note to the issue.
Thierry: What should I do with "out of scope" which is empty?
Pierre: Remove the section.
Thierry: Ok
... The next is section 8 licence.
Nigel: Can we use the wording from the current charter "For
each deliverable the Working Group may choose either the W3C
Document license or the W3C Software and Document license."?
Thierry: That's better, okay.
... I will integrate that.
Nigel: That's everything for you to do please Thierry, as well
as removing the editorial sections from the template.
Thierry: I'll do the edits tomorrow and send a last call to the
WG with a Tuesday afternoon
... deadline for minor edits before sending to W3M on Wednesday
morning (Europe time).
Nigel: Thank you.
TTML1 3rd Ed CR
Thierry: I sent the transition request yesterday (or this
morning?)
... The Director is in China and MIT was closed yesterday, so
it will be discussed early next week.
... I will prepare the announcements etc - there's more to do
than the normal WD. Considering
... all the people who are involved it takes at least a week. I
plan to have it before the end
... of this Charter, which by the way will need to be extended
if we provide a Charter by
... next Wednesday, probably a 2 month extension for the AC
review, or something like that.
IMSC 1.1
Pierre: Can we resolve to publish as a CR in two weeks? I think
there's no obstacle to closing
... all the issues in the next two weeks.
PROPOSAL: After resolving the current open issues, request
transition of IMSC 1.1 to CR on 5th April.
RESOLUTION: After resolving the current open issues, request
transition of IMSC 1.1 to CR on 5th April.
Pierre: In the next two weeks I'll work on merging the open
pull requests and can help
... with the transition request.
Thierry: Okay, thanks, I will begin working on that.
Meeting close
Nigel: Thanks everyone, we got through a lot today.
Thierry: Thanks Pierre, Andreas and Nigel for reviewing the
Charter draft.
Nigel: We're slightly over time, so closing today now.
[adjourns meeting]
Summary of Action Items
Summary of Resolutions
1. [13]After resolving the current open issues, request
transition of IMSC 1.1 to CR on 5th April.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [14]scribe.perl version
1.152 ([15]CVS log)
$Date: 2018/03/22 16:35:47 $
[14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[15] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 22 March 2018 16:40:11 UTC