- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 14 Mar 2024 17:22:43 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <046A2A10-ABF1-4205-8FAA-F30E7BE482DC@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2024/03/14-tt-minutes.html
In plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
14 March 2024
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2024/02/29-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/276
[4] https://www.w3.org/2024/03/14-tt-irc
Attendees
Present
Andreas, Atsushi, Gary, Matt, Nigel, Pierre
Regrets
Chris, Cyril
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]IMSC-HRM AC Review status
3. [7]DAPT
1. [8]Investigate Data Model and TTML Syntax mapping
w3c/dapt#214
4. [9]Clarify language application and inheritance model
w3c/dapt#192
5. [10]Meeting close
Meeting minutes
This meeting
Nigel: On the agenda today, we have the IMSC-HRM AC review,
… and some DAPT issues and pull requests
… Is there any other business, or points to make sure we cover?
Andreas: Nothing from me
group: nothing else
Nigel: I just wanted to apologise again for the shifting
meeting time for today.
… Just for advanced information,
… I think we should stick to this time for our call in 2 weeks,
… and then move to 1 hour earlier UTC, to revert to the normal
local time for most people,
… unfortunately excluding Atsushi, but an hour earlier might be
a good thing in Japan?
Atsushi: That works for me.
… Thank you for the consideration. The i18n call immediately
before this sticks to UK time,
… so that allows me to attend both.
Nigel: I think that's a decision. Any last words on this?
Atsushi: Thanks for that.
IMSC-HRM AC Review status
Gary: Philippe just closed the transition request just now, so
I guess it's published.
<gkatsev> [11]https://www.w3.org/TR/2024/PR-imsc-hrm-20240229/
[11] https://www.w3.org/TR/2024/PR-imsc-hrm-20240229/
[12]IMSC-HRM AC Review poll results (access restricted)
[12] https://www.w3.org/2002/09/wbs/33280/202402-PR-IMSC-HRM/results
Nigel: The AC review is open for another two weeks.
Nigel: That transition request was for transition to PR, which
happened 2 weeks ago, I think the request
… issue just got closed as an admin task.
… [summarises poll results for those on the call]
… It would be helpful to have as many responses as possible,
… particularly not abstentions, so if you know any AC reps you
can reach out to
… and encourage a response, that would be very helpful.
Atsushi: If we cannot collect support from participating
organisations we may have a hard
… situation for transitioning to Rec so please get your own
organisation to review positively.
Nigel: I assume invited experts cannot vote?
Atsushi: Yes, only member organisations.
… Thank you for the consideration, this is quite important.
[13]Proposed changes from BBC
[13] https://github.com/w3c/imsc-hrm/issues/79
Nigel: I looked at these and I think they're completely
editorial and all are improvements.
Pierre: Sounds good, thanks to Chris for his review.
Nigel: There's no problem making edits like this between PR and
Rec?
Atsushi: I need to check.
Nigel: I think the answer is that it's okay but happy for you
to check.
Atsushi: From Proposed Rec to Rec, substantial changes are
prohibited.
… The easiest way is to raise comments via AC review.
Nigel: That is what Chris has done.
Atsushi: Then it's simple, we just need to fix.
… If substantive issues are raised by AC review we need to go
back through the process, but
… it is common to make changes after AC Review.
Nigel: I guess that's with you as Editor Pierre.
Pierre: What's the right timing to generate a PR?
Nigel: I think you can do it whenever you like.
Atsushi: There's no formal timing for revising Proposed Rec.
Everything should be Editor's Draft,
… so everything should be fine, subject to our CfC period.
Pierre: Okay, I will address them ASAP
Atsushi: Thank you for that.
… Please note that we may need to take one extra week to get
back to reviewers after AC review,
… on any changes. A bit like with a Charter we need to check
with reviewers that they're happy with the changes.
Nigel: I imagine that Chris would directly review the Pull
Request.
Atsushi: It's a formal process - we need to go back to all the
reviewers.
Nigel: Anything more on IMSC-HRM?
DAPT
Nigel: Since the last meeting we closed one issue and merged
one pull request.
… More importantly, Cyril and I spent quite a bit of time
thinking through the open issues, particularly
… the one we discussed last call about backwards/forwards
compatibility and how to handle
… conformant DAPT documents that don't map directly to the DAPT
Data Model as it stands.
[14]3 DAPT agenda items
[14] https://github.com/w3c/dapt/labels/agenda
Investigate Data Model and TTML Syntax mapping [15]w3c/dapt#214
[15] https://github.com/w3c/dapt/issues/214
github: [16]w3c/dapt#214
[16] https://github.com/w3c/dapt/issues/214
Nigel: The issue is that it is possible to construct TTML
documents that are conformant DAPT documents
… but which contain things that do not map directly to the DAPT
data model.
… Things that we considered were:
… Adding more constraints to the DAPT documents to prevent
that;
… Adding to the data model a generic grouping of Script Events
to match nested divs
… Adding statements into the DAPT Data Model -> TTML
representation saying how to reverse it
… Adding a new section explaining TTML -> DAPT Data Model
mapping (we decided to do that)
… Add no extra constraints or features (we decided it is better
not to add any, and to have explanations instead)
… I am drafting a pull request to add a possibly informative
new section explaining
… suggested rules for mapping TTML to DAPT, and also updating
the Foreign Vocabulary section to make it
… more generally apply to any unrecognised vocabulary even if
it's in the TTML or DAPT namespaces.
… Any thoughts about this?
Andreas: You say the new section will be informative?
Nigel: That's what I'm thinking at the moment.
Andreas: What's the normative expected behaviour of a
processor. Is it implementation dependent?
Nigel: It's what's defined by the TTML features and extensions
Andreas: Er, ok. Nested divs for example, are not forbidden?
Nigel: That's right
Andreas: That would be part of the expected behaviour to deal
with that?
Nigel: Yes
Andreas: You say the mapping rules will be informative, but
what will the normative expected behaviour be?
Nigel: It's what TTML says. There's no normative requirement to
map into the DAPT data model.
… The fact that a DAPT document was generated from the data
model is interesting maybe but
… doesn't define the processing behaviour.
Andreas: So you cannot guarantee that two DAPT data model-based
implementations handle a generic TTML
… document the same way?
… There's no normative deterministic parsing into the data
model?
Nigel: That's right, but parsing into the data model isn't a
requirement.
… There is already text around handling unknown stuff in §5.2,
which is normative, and quite broad,
… but essentially the processing semantics are defined by TTML,
because DAPT is defining a profile of TTML.
… Most of the extension features are constraining syntax, I
don't think there are any that define
… processing behaviours that wouldn't apply more generally.
… In particular, none of the extension features is based on
anything in the DAPT data model;
… they are all constraining the TTML representation directly.
… I think adding this guidance feels helpful, but the question
is if it actually needs to be any more normative than guidance.
… I suspect you're thinking about it and need to see the pull
request.
Andreas: Yes, it would be good to see it written down and then
play it through.
Nigel: Sure, I just wanted to inform you where we got to and
the direction of travel.
… Happy to have any comments either on the issue or the pull
request when opened.
SUMMARY: @nigelmegitt to continue drafting a pull request
Clarify language application and inheritance model [17]w3c/dapt#192
[17] https://github.com/w3c/dapt/issues/192
github: [18]w3c/dapt#192
[18] https://github.com/w3c/dapt/issues/192
Andreas: We discussed this last time and I think the conclusion
was that we should add
… lang to Script Event.
Nigel: That's easy, we can do that.
… Thank you for the reminder!
SUMMARY: Add Language to Script Event as an optional property
Andreas: My recollection is we think that makes sense, Cyril
suggested it, nobody objected.
… My only question is what happens if xml:lang is on the <body>
element?
Nigel: We discussed in relation to [19]w3c/dapt#214 about
computing values and then applying them where appropriate.
[19] https://github.com/w3c/dapt/issues/214
Pierre: It's a two step process - first compute the value of
xml:lang on every element, then when you map
… those elements to your model, you get the values of xml:lang
on the objects where you care about it.
… Would you like me to add a note to the ticket?
Nigel: Yes please, on 214.
Pierre: OK
Nigel: Thank you, that would be really helpful.
Pierre: It works in both directions. If you map the model to
XML you can just specify it on elements where it applies,
… because that will always override the inheritance.
… You can make another pass and simplify the serialisation
using inheritance, but that's optional.
Nigel: [nods]
Pierre: I suffered through that on TTML validation parsing.
There's no way to finesse it. There are always corner cases.
… One fun one in TTML - you have to do xml:lang inheritance
before ISD processing, because you end up
… moving body under region as part of the ISD generation
algorithm so if you haven't computed it already
… then you might end up with the wrong value.
Nigel: That's a really good point.
… There's no need for regions in DAPT normally, but it's a
gotcha that someone might use them for some reason
… and might put an xml:lang on them, who knows why, and then it
needs to work how you just described it Pierre.
Meeting close
Nigel: Thanks everyone, as discussed at the top of the call, we
will meet next in 2 weeks
… at the 1600 UTC time. The meeting after that will be adjusted
to 1500 UTC to track DST in Europe, which
… also works for Atsushi.
Gary: It helps me too.
Atsushi: I am quite sorry but could send regrets for next time
- that day I will be travelling, but I will try.
Gary: Don't try too hard if it's a travel day.
Nigel: +1
Nigel: Thanks again everyone. [adjourns meeting]
Minutes manually created (not a transcript), formatted by
[20]scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).
[20] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 14 March 2024 17:22:54 UTC