See also: IRC log
<scribe> scribe: nigel
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]
Draft 2018 TTWG Charter document
Nigel: Thanks to those who reviewed and raised issues on the repository recently.
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.
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.
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.
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]