Meeting minutes
This meeting
Gary: Today we have a couple of IMSC topics, specifically more discussion about the
… ARIB liaison, something about IMSC /rec.
… A question for WebVTT around Unicode normalisation.
… Some TTML2 2nd Ed IR updates, and then more TPAC planning maybe.
… Any other business?
group: [no other business]
IMSC 1.2 - ARIB liaison
Nigel: Not sure if we can cover the IMSC ARIB liaison topic today, actually.
Atsushi: I can write a private email to get more information.
Nigel: Thank you that would be great, also to remove any potential language issues from
… being a problem. Thank you.
IMSC /rec
Atsushi: For information, the in-place republishing has finished,
… so there are updated links in the Rec publications for 1.0.1 and 1.1.
Nigel: Thank you for that. I'll remove this from the agenda now!
WebVTT: over-specification in Conformance: Unicode normalization w3c/webvtt#483
github: https://github.com/w3c/webvtt/issues/483
Gary: This issue came from the i18n working group, about Unicode normalisation.
… WebVTT specifically disallows this, and says to compare the bytes directly.
… The issue raised is that it is not what we want, potentially.
… I don't have much knowledge personally of why you would want or not want to do it.
… From digging around in the history, it sounds like it was mostly to make sure that
… things that are required in WebVTT are easy to identify like the arrow in the time
… signature so that we aren't matching normalised Unicode and can find it more easily.
… I want to ask if anyone had more knowledge about it, or if TTML or IMSC handle
… Unicode normalisation.
Nigel: I think in TTML it is delegated to XML so whatever XML says, which we assume is
… the correct thing, is what happens.
Gary: Yes. It's relevant that WebVTT is not XML but a text format with markup.
… David Singer said that for the text of the cues we could do normalisation, but even that
… might be a bit more complicated because HTML tags are allowed to be used.
Nigel: Also what about metadata payload in the cues?
… For example if it is JSON, does that specify Unicode normalisation? I do not know.
<atsushi> https://infra.spec.whatwg.org/#json
Atsushi: In JSON I believe that it depends on the processor for values
<gkatsev> json specification
Gary: The spec is quite small and just says it is a sequence of Unicode code points.
Atsushi: I think currently in WebVTT, case sensitive non-normalised matching is defined.
Nigel: The issue is that it is _not_ using that.
Atsushi: I think the linked document was written after work on WebVTT began.
… The standard operation was written after WebVTT so maybe even if the result is the same
… but some text is over-specified in the current standard.
Cyril: A different angle: do we have tests for this in WPT?
Gary: For Unicode normalisation?
Cyril: Yes, to match the MUST NOT in the spec.
Gary: I'm not sure
Nigel: Are you thinking about if we can establish what implementations do now via the tests?
Cyril: Yes
Gary: From a quick look I'm not seeing anything specific to Unicode.
Nigel: I'm a bit confused about where the line is drawn between parsing the WebVTT
… document e.g. during processing, cue matching etc. and text presentation.
… If some payload text is passed onto a text renderer and there's a step that does
… normalise the text, is that broken, according to the spec text in §2.2?
Gary: The example is about cue matching, which is very specific.
Nigel: Is "processing" a defined term?
Gary: It could refer to the "processing model" part of the spec.
… That would make sense because that's when you would be applying styling and whatnot.
Atsushi: I am not sure that there is any case that is not covered by "case sensitive non-normalising"
… if there is no such case then I suppose it may be possible to write it into the standard
… in a simpler way.
Gary: You mean to link to the charmod-norm spec to the section that matches what
… we want to do in WebVTT?
Atsushi: Actually the character model normalisation is not a Rec track doc but a WG note
… so it cannot be normative. You would need to copy and paste the spec text.
… Recently there are several standards that say this kind of thing so having this kind of
… spec may be easier for readers and may not have some strange cases.
… The last point of the issue comment is for character encoding, but I'm not sure if we need
… to have this strong restriction for later processing by scripts or web browser.
[not sure I got that very well]
Gary: You mean from cue text?
Atsushi: Yes
Nigel: Does the requirement that WebVTT is always UTF-8 make some of the concern
… disappear here?
Atsushi: I need to think about that more.
… At this moment I don't see any difference between the suggestion and the current
… spec text and description.
Nigel: Not sure how we move to a resolution on this. Gary?
Gary: I think I need to read up on the charmod-norm first and it would be good to get
… clarification on how WebVTT being specified as UTF-8 affects/does not affect things.
… It does sound like it might be okay to change how we handle the cue text normalisation
… but we likely don't want to do that for other parts of WebVTT.
SUMMARY: Investigation of impact to continue.
TTML2 2nd Edition Implementation Report
Nigel: For the IR I think, unless there's an update, we still need to update the IR page
… to reflect the full set of TTML2 2nd Edition tests.
Cyril: yes, still need to do that.
… Did we merge all the test PRs?
Nigel: I see 2 open pull requests to add tests.
Cyril: #252 is not approved yet. Nigel and I commented on it.
… #235 is not approved, only a comment from Nigel.
Nigel: Aargh I forgot to review Glenn's commit on #252 that he says addressed my comments.
… On #235 there's an outstanding comment that hasn't been addressed.
<nigel> s/253/235
Nigel: Looks like we need to do those first.
Cyril: What's the outcome. Should we wait until we merge those pull requests?
Nigel: They're likely to be fixed and merged.
Cyril: I can consider them merged for the purpose of mentioning them in the IR
Nigel: I think that's pretty safe.
Cyril: Then I'll do that.
… Then is this the end, can we give implementations a prompt to start filling their parts.
Nigel: I believe so.
Cyril: I will try to update the Netflix column.
… As I said last time I don't expect that we will pass many of the tests because most of
… them are features that we're not interested in.
Nigel: On the topic of implementations I just updated our Adhere audio description
… implementation, which is at https://bbc.github.io/Adhere/ so you can try it out if you like.
… It includes the TTML2 audio-in-body test which I believe passes.
AOB - TPAC 2020 planning
github: https://github.com/w3c/ttwg/issues/112
Nigel: On the time-per-session question, we sometimes go to 2 hours here, but I always
… force a break in the middle.
Gary: Yeah, longer than 2 hours is too much.
Nigel: We discussed hallway conversations, any more progress on that?
Gary: A comment from last time is to have a "hallway track" session open all the time,
… not tied to a working group.
Nigel: That's a good idea. I've seen breakout rooms used on Zoom, but only where there
… is a central person creating them and sending people to them.
… I don't know if they can be used in an ad hoc way.
Gary: Yes it's easier on zoom, I don't know if anyone can do it if the permissions can be setup that way.
Meeting close
Nigel: Let's adjourn for today. Thanks everyone. [adjourns meeting]
<nigel> s|s/253/235||