clarification on the cpl extension JSON schema

[dcbullock]

registries/src/main/schemas/cplmetadataexts.schema.json

If I read the schema correctly, there is an array of defining documents for each single extension element, and each extension in turn has a single property.

429-16 allows an array of properties in an extension and does not define the array of defining documents.

1. should the ISDCF JSON allow an array of properties?
2. should the ISDCF JSON defining documents array instead be moved such that there is a single defining document as a child of the property?

If the goal is to have the ISDCF JSON extension match 429-16 XML, then ISDCF JSON should allow an array of properties and the defining docs should be left outside as it is now.

If we keep an array of defining documents, is it understood that the order of the documents matches the order of the extension properties. What if there is a single document defining multiple properties?

This is not a blocker. Food for thought.

[SteveLLamb]

For the purposes of this page, there are a few things to note that might help clear this up.

Each entry in the registry (currently) is a single extension defined, and currently no extensions in use anywhere have multiple properties. One entry = one extension, one property.

This doesn't preclude us from combining properties in mastering a CPL. For example, we often combine the RDD 52 and RDD57 applications into a single extension for mastering. We can make extensions an array IF anyone ever comes up with a multiple properties extension, but right now at least I have systems tied into DCNC for validation where it's not. Right now the only two extensions that share a name and scope (intentionally) are again RDD 52 and 57. Any further updates and/or additions to these (or a IAB P1, if it ever comes) will share those as well for further combining in the CPL. Previously, this feature was not utilized at all.

The reasoning for array in the defining docs are similar to other registries, where we might have an ISDCF and SMPTE doc (or multiple SMPTE docs) both having this info, or portions of the info needed - see Audio Configs. This keeps the schema consistent across the registries, even if only one is used currently - RDD 57 was two, while the SMPTE docs was being drafted for example. IMO the more documentation, the better in most cases, especially when validation (and justification of it) is concerned. If a single document defines multiple properties, it will be in multiple entries (as noted above), which can be combined for mastering.