See also: IRC log
<scribe> scribe: nigel
Nigel: Hello! [iterates through agenda]
Glenn: I have a couple of items on the profile registry
Nigel: Ok
... AOB or particular points to make sure we cover today?
group: [silence]
github: https://github.com/w3c/charter-timed-text/pull/40
Nigel: I updated this 2 days ago
and @skynavga approved it.
... Any objections to me merging this now?
group: [no objections]
Nigel: Thanks, I'll merge it now... done.
SUMMARY: Pull Request merged.
github: https://github.com/w3c/charter-timed-text/pull/44
Nigel: Andreas raised a comment
that I think I addressed and I addressed my own comments
too.
... Again, I'd like to merge this so the single document is
available for review.
Glenn: It'd be nice to merge them all because it's difficult to review the pull requests without a preview mechanism.
Philippe: Sorry I haven't had the time to look into making the preview work yet.
Nigel: Any objections to me merging this?
group: [no objections]
SUMMARY: Pull request merged.
Glenn: There are some references
to the SDP-US work which should be taken out of the
charter.
... I presume that the material on TTML2 has been changed to
describe 2nd Ed work not the original one.
Nigel: The wording has become more general there to allow new versions of the TTML specification to be published. Please take a look.
Philippe: Is SDP-US still relevant?
Glenn: It's still published as a WG Note and there's no reason to change that, but we're not doing any work on it.
Philippe: We should list it in Other Deliverables in that case?
Glenn: You want to include past deliverables.
Philippe: It says "may be updated" and doesn't require any work. [wants to keep it]
Glenn: Ok. In the scope, where it talks about new versions it would be useful to talk about new editions.
Nigel: I think that's covered.
Pierre: This needs a whole editorial pass through because this has grown organically over the years.
Glenn: +1
Pierre: I'd be happy to do it.
It's difficult to contribute to this because it's convoluted
due to the amount of work we've done.
... My goal would be to make a zero point edit, not change
small sections. Really rationalise it.
Glenn: yes, it's not organised very well.
Pierre: It needs to say what we will work on, what we will maintain and specific topics to study.
Glenn: It may make it harder to review because it may look like a bunch of changes.
Pierre: My suggestion is to start from scratch.
Glenn: I agree [ that this would be simpler ]
Philippe: I'm supportive of that.
Maintenance of Recommendations doesn't need to be said.
... We still have the deliverables, which can list the
documents to be maintained.
Pierre: At the end of the day
people want to know our scope and deliverables.
... And the dates.
Philippe: Yes, so the sections
need to stay the same in term of headers, so we have
consistency across charters.
... The scope section could be simplified.
Nigel: It would have been nice to hear that a month ago! I agree with the idea though.
Pierre: I'm offering.
Nigel: It's formally my role to
prepare the draft charter and I'm happy to take all input. The
WG needs to agree it before
... it goes forward.
Philippe: Why don't we let Pierre have a stab at it?
<plh> https://www.w3.org/Style/2016/css-2016.html
Nigel: Yes. If you have a stab at that can you and I have a call in the middle of next week to see where we're up to?
Pierre: Sure.
Philippe: The scope section of
the CSS WG is way smaller and that's the principle to follow -
define the scope to be large
... to give the WG as much leeway as possible. The rest is
mechanic.
Nigel: In that case we should
move to the next topic. All the Pull Requests are now merged so
it's a good starting point.
... I've just assigned Pierre issue #46.
Glenn: At this point there are no
pull requests and there would have been no issues but Cyril
opened an issue, #71,
... asking to put all the information that we had about the
combination operators into the media type definition
directly
... whereas previously we had augmented the introduction which
is informative. He thinks it should be normative and in
... the media type definition. We had expressed a desire to
avoid a full IANA expert review.
... He and Mike are not on the call. I'd like to point out we
need to get this Note updated on the main TR website for
W3C.
... It'd be nice if we could do that as soon as possible. I'm
willing to wait until Cyril and Mike are online to discuss
this
... issue further. I personally don't think we need to do what
he is suggesting here.
Nigel: We could update the note now and consider this for a future change.
Glenn: I would go along with
that.
... The last time it was updated on /TR was in 2017.
Nigel: Yes, https://www.w3.org/TR/2017/NOTE-ttml-profile-registry-20170117/
Glenn: All we need is a resolution and then we can do that.
PROPOSAL: Publish current Editor's Draft of the Profile Registry as a /TR Note and then consider #71 later.
<glenn> https://github.com/w3c/tt-profile-registry/issues/71
Nigel: Any objections on this
call to doing this?
... If we resolve this now there will be 2 weeks review under
our Decision Policy.
group: [no objections]
RESOLUTION: Publish current Editor's Draft of the Profile Registry as a /TR Note and then consider #71 later.
Nigel: There's a publishing moratorium coming up - does that apply here?
Philippe: No, we can use automatic publishing.
Philippe: On the CR update I didn't see any objections to updating the CR and the 2 week has passed, so can we record a decision to publish an updated CR for WebVTT?
Nigel: Yes we can.
Philippe: Decision: update the CR
for WebVTT with the draft proposed by Gary
... I'll take care of the transition request, and take any
questions back to Gary. I will try to do it before the
publication moratorium.
Nigel: I added to the agenda a
status update on the Netflix questions about Japanese language
tests, but Cyril isn't on
... the call so I suggest we skip that for now.
Gary: The IR is in pretty good
shape this week.
... I've been going through the API parsing test.
... There were a couple of things without 2 implementations but
I was able to update vtt.js so now they pass.
... For Japanese I didn't get to look at it that much but
hopefully will have a better idea for next week.
github: https://github.com/w3c/ttml3/pull/30
Glenn: I'm waiting for someone to
approve a review on this.
... The last comments I think were from Pierre a week
ago.
... He suggests that we add this support to TTML2 as
well.
... I think it's okay to consider that and would suggest Pierre
open an issue on TTML2
... asking to backport this pull request to TTML2 2nd Ed.
... That shouldn't prevent this pull request from going
forward.
... I believe I've addressed the other comments, though I can
still deal with other issues.
Nigel: There is an unanswered
question, which I asked at https://github.com/w3c/ttml3/pull/30#issuecomment-473956814
... Which is whether to use "private" and "public" for
"unregistered" and "registered".
Glenn: I took as my model the Unicode private use area, which doesn't say anything about visibility, just registration.
Pierre: I still have an outstanding question - I don't understand how processing would be different for private and public.
Glenn: There is none.
Pierre: Then we should not introduce any distinction in the spec.
Glenn: That doesn't follow! We have thousands of statements not testable implementation-wise.
Pierre: Yes and that got us into
trouble in the past so I'd rather nip it in the bud now.
... There is no use for the distinction between public and
private.
Glenn: There is if you want to know if a private definition is permitted or not. There's a note that refers to it.
Pierre: I don't understand why technically it matters.
Glenn: Do you recognise the use of a private use area in Unicode?
Pierre: Yes absolutely.
Glenn: That's the model here.
Pierre: This tells people that
some codes cannot be used later for public definition.
... I don't see the parallel here with modules.
Glenn: We define a number of extensibility mechanisms - this is simply another one.
Pierre: It's namespace driven. The allocation of namespaces is done outside this document.
Glenn: One thing we could say
with a normative impact is that a private module must not use
an officially defined
... timed text namespace.
Pierre: Sure but that's already
defined everywhere anyway.
... I'm trying to reduce unnecessary complexity. It's
additional definitions which are therefore complexity.
Glenn: I'm willing to remove the
public and private definitions but will leave in the note that
refers to private modules
... and just remove the link to the definition.
Pierre: Yes that will satisfy
that comment.
... I think we discussed enabling modules but not specifically
defining them.
Nigel: +1 - enabling modules
doesn't require spec text necessarily.
... If you take out private and public then that resolves my
question.
Glenn: Can I get an approved review if I do that?
Pierre: I'm really more
interested in the hooks we put into TTML2 to allow for external
specifications. We'll have to wait for that.
... But in the meantime you've addressed my question and
comment on public/private.
Glenn: We can always add it back in if we need it later.
Nigel: The other question is about a module registry.
Glenn: Yes, and I will be drafting it soon.
Nigel: I question if we really need that - a profile will point to the modules that define features it needs. Why do we need something else?
Glenn: I think it's obvious to
list the potential modules that can be used.
... Getting this pull request completed and merged is a gate to
defining some modules.
... We have a record of taking a modular approach - it is not a
good use of time to revisit that.
Pierre: The real gate is on TTML2.
Glenn: You've noticed I've opened pull requests on TTML2. Completion of TTML2 is a gate for TTML3.
Nigel: I don't think the modular
language is the gate to modules here, it's more the hooks for
assigning vocabulary
... to particular processing approaches such as saying
ittp:fillLineGap should be processed as a style attribute.
Glenn: [comment about profiles referring to modules by feature definitions]
Nigel: That's a new topic to
discuss later.
... We have one more TTML2 pull request but not enough time to
cover it so I propose to defer it.
Glenn: I would like to resolve #1049.
Nigel: I don't think we can do that quickly - there are insufficient tests for it right now.
Glenn: Request a 2 hour session next week.
github: https://github.com/w3c/ttwg/issues/30
Nigel: I think there's a growing
consensus for a meeting at TPAC and another F2F some time
before then in the
... timescale when we will be working towards a CR
transition.
... Any thoughts about when that would be?
Glenn: We need to start CR by early June for that.
Nigel: Previously that was when you were talking about FPWD, wasn't it?
Glenn: [checks timescales with
Philippe's tool]
... Getting to Rec by end of the year we need FPWD by July
9.
... For CR then the latest we could do it would be Oct 15.
Nigel: We know our processes take longer than this so we need to back it up more, in real world times.
Glenn: Yes, 1st Oct for CR would be a good target, assuming we don't go to a 2nd CR.
Nigel: I expected an earlier
target.
... Beginning of Sep say means FPWD early June.
Glenn: That's reasonable.
... That could get us to Rec by mid-Nov best case
Nigel: Then a meeting in July or
August would make sense.
... Terrible from a holidays perspective!
... I think I should look for dates in July. Anyone think
that's a terrible idea right now?
Pierre: Driving meeting times through a document timeline is a good idea.
Glenn: I'm hearing "let's wait until we have a FPWD or close"
Pierre: Although, knowing our
options, and starting to plan, with a placeholder might
help.
... But yes I agree that we may not be able to make a decision
until then.
Glenn: Fukuoka still looks like a good time for meeting.
Pierre: Yes, and it would be awesome if it hadn't been scheduled at such a bad time relative to other industry events.
SUMMARY: Working assumption is meet at Fukuoka and attempt an earlier f2f meeting in line with spec development.
Nigel: Thanks everyone. [adjourns meeting]