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> https://
IMSC-HRM AC Review poll results (access restricted)
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.
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.
Investigate Data Model and TTML Syntax mapping w3c/dapt#214
github: w3c/
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 w3c/dapt#192
github: w3c/
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 w3c/dapt#214 about computing values and then applying them where appropriate.
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]