Meeting minutes
This meeting
Nigel: We have a bit on DAPT - just the implementation report.
… and on IMSC we just need to cover the ja character set
Pierre: Agree, we need to figure that out.
Nigel: In AOB we have meeting times in March when its DST in north America, but not in Europe.
… Anything else for the agenda, or to make sure we cover?
no other business
Improve the ja character set per ARIB feedback w3c/imsc#614
github: w3c/
Nigel: We had some good input that we processed last meeting. What's the status?
Pierre: [shares screen showing preview of the pull request]
… Atsushi, what do you suggest?
Atsushi: ARIB TR document is some sort of operational manual which records the current situation.
… It is not normative.
… It could be changed.
Pierre: Remove the TR-B39 sequence?
Atsushi: Maybe just note that these are operationally used but not normative.
Pierre: suggests removing the explicit list and just referencing TR-B39
Atsushi: the note also could apply to CJK ideographic characters
Pierre: Make the reference to the ARIB TR a note?
Atsushi: Yes something like that, or suggest that IVS is used for CJK and operationally used IVSes are
… used in ARIB.
Pierre: What's the down side of referencing ARIB-TR-B39?
Atsushi: It's a link from normative text to a non-normative document.
Pierre: The entire annex is just a SHOULD not a SHALL.
Atsushi: SHOULD is normative too.
Pierre: It's useful though.
Atsushi: Yes, useful but the normative definition in ARIB STD is that IVS may be used, but operationally
… characters listed in ARIB TR are the ones currently used.
Pierre: Exactly.
Atsushi: That's why I'm afraid that the TR definition may be changed, so I want to turn that part into a non-normative note.
Pierre: Sure, [makes edit that the IVS is a Note.]
Pierre: Nigel, are you happy with this?
Nigel: Yes. Are there any other issues related to the ARIB ja character set that we should be covering off here?
Pierre: [checks] I don't think so
Atsushi: Yes
Nigel: Great, let's go for it then.
Pierre: [pushes the change]
Nigel: The note about 10646 and Unicode - why is that in the ja section? Oh, because it's only referenced in the ja character set
Pierre: That's right
Atsushi: There are corrections that are only in the ISO spec.
… I approved the PR
Nigel: I approved it too
Pierre: I have to fix the merge conflicts then I'll merge the PR.
SUMMARY: PR to be merged.
IMSC 1.3 next steps
Nigel: I think there's nothing more to do?
Pierre: Yes I think we're done
Nigel: So the Implementation Report is empty as expected.
… I can't recall when the exclusion period ends.
<atsushi> https://
Atsushi: The exclusion period has ended. We need an implementation report and consensus for advancing,
… and AC review.
IMSC 1.3 Implementation Report
Nigel: The next step is for me to issue a call for consensus to request transition to Rec on this basis,
… when the last pull request has been merged.
Atsushi: If we can issue a CfC within this week and have a resolution in two weeks that could help me
… because I may possibly be offline for a while in the later half of March.
Nigel: OK I'll aim to do that.
Pierre: PR Preview just started to work!
Nigel: Amazing, we can close off that other issue then.
Pierre: What do you need from me?
Nigel: I don't think anything - do we need to prep a Rec version?
Atsushi: I believe you can use the /TR version for the CfC
Nigel: That's what I expect.
DAPT Implementation Report
Cyril: We've now implemented #daptOriginTimecode
Nigel: That's great.
… I've updated the IR with the new BBC validator link
Nigel: For the #daptOriginTimecode were you able to validate it?
Cyril: Not yet - does your validator check it?
Nigel: Yes it does
Cyril: OK I can give it a try or you can
Nigel: From the Charter, there is some text we can lean on.
Nigel: I'm proposing to bring some of that wording into the IR as explanation, and separately list the
… different kinds of implementation that we have examples for.
… Hopefully that allows us to tell the story a bit more clearly.
… Does that makes sense?
Cyril: Sure, yes.
Nigel: Anything else for us to cover on DAPT?
Cyril: How are you thinking about resolving the last features that are not yet interoperable?
Nigel: What are they?
Cyril: The at risk features where we wanted implementation feedback
Nigel: Those are two different things.
… The last non-interop feature in the IR is #xmlLang-audio-nonMatching which is fairly minor.
… We either wait for an implementation that supports it,
… or we explain how there's no behaviour defined except for a validator, and propose advancing with an exception based on the scale of the issue.
… (which is tiny)
… For the at-risk features, that's different. Ideally I would like to have more input.
… We could try to choose a minimum viable set and add in extra options if people ask for them.
… Or we could include all the options and put a note on saying that we may prune some of them in future
… versions based on usage and practice.
… I think as a rule choosing the minimum set and adding more later is better.
Cyril: I agree, it minimises the tests and implementation tasks too.
Nigel: OK the action is on me to go to AD providers and double check with them what their
… preference is for including or referencing audio recordings.
Cyril: We could think also about workflows.
… If someone delivers to you a script and audio assets, how would that work?
… Do you have a way to receive multiple linked assets somehow?
Nigel: Good question
Cyril: Pierre being here reminds me of IMF where there's a manifest and a set of assets.
… You could supply a zip of all the assets for example,
… or include all the audio base64 encoded.
… Maybe the solution is to provide both and then see what companies want to receive and what vendors support.
Nigel: That's a good thought process to go through. I will check in with my colleagues in media supply as well,
… because they likely have preferences here.
… It is true that managing single files is easier if possible.
… But then, how can you validate that a zip includes all the audio files referenced by the DAPT, say?
… Maybe that's another kind of validation.
Cyril: Right, and if you receive a zip and need to store it in the asset management system, that's one thing.
… But if you have references you have the problem of what they are relative to, what URL to put.
… If you put it in a zip file it can be relative to the path of the document.
… But if it gets stored in the MAM you have to replace the URL with something, an identifier or something
… like a proprietary URL.
Nigel: Yes that could be a problem.
Cyril: Do we care about playback of these files or just transmission between a creator and a receiver?
… One of the use cases is sending to a client device for local mixing.
… The technical requirements for sending the audio may be different than from sending it to a platform.
Nigel: Yes, it may, that's right.
… There are a few approaches.
… One is to use relative URLs
… Another is to create a single audio track and use range identifiers
… like clipBegin and clipEnd which are already available.
Cyril: or byte ranges
… It seems to me that it's hard for us to pick A or B, we have to support both because different people will
… have different ways of doing things.
Nigel: [iterates through the at risk issues]
… For the values of encoding, I think we can just choose one - presumably base64 would be the one.
Cyril: Yes it is the most deployed one.
Nigel: For the length attribute on data we can simply keep it because it's useful
Cyril: for the referencing of resources, we could take the approach of requiring <source> but restricting
… the number to 1 for now, with the option to add more later.
Nigel: That would work, yes.
… Would work for both embedded and external
… Or we could prohibit the src attribute and allow any number of <source> elements and leave it to
… implementations how to deal with them.
March meeting times
Nigel: The proposal is to keep the current UTC time for our two meetings in March,
… so that this call is an hour later in local time in north America.
Cyril: Sure that works.
Nigel: OK let's do that, it keeps things the same everywhere else.
Meeting close
Nigel: Thanks all, we're at time, let's adjourn.
Next meeting is 2026-03-12 1600 UTC
Nigel: [adjourns meeting]