Define Composition Playlist Metadata Values

[james-OT]

Content owners typically require asset creators to name files or their associated metadata with specific values in order to describe the content being delivered. In the IMF ecosystem, leveraging the metadata elements available in the Composition Playlist is preferred over storing this information in the filename. As such, including a method to define the values for these metadata elements via the Delivery Schema would be very useful.

Furthermore, it would also useful to create a notion of "static" vs "dynamic" value types for each element. For example, "static" values have been pre-defined in the Delivery Schema, and cannot be modified by the user once the DS has been invoked. On the other hand, "dynamic" values can also be pre-defined in the DS, but the entire string would be user configurable after the DS has been invoked.

Here are several use cases to illustrate the idea:

Use Case # 1

Generic Pictures wishes the <ContentOriginator> value in the CPL to always be "Generic Pictures". They would create a Delivery Schema with a static value of "Generic Pictures", which the user would not be able to modify once the DS was invoked.

Ex:

<ContentOriginator>Generic Pictures</ContentOriginator>

Use Case # 2

Generic Pictures wishes the <Id> value for the <ContentVersion> element to be pre-populated with the URN string for their CMS (urn:genripedia in the below example), but needs the user to modify the pre-populated URN by adding the applicable ID for that piece of content. As such, this would be a dynamic value. However, they want the associated <LabelText> value to be static, and not modifiable by the user. In the example below, the EIDR is being indicated for the applicable content.

Ex:

<ContentVersionList>
  <ContentVersion>
     <Id>urn:genripedia:[eidr value]</Id>
     <LabelText>EIDR</LabelText>
  </ContentVersion>
</ContentVersionList>

Here is a list of the CPL metadata fields that seem like logic choices for a content owner to want to have the ability to define via the Delivery Schema:

<Annotation>
<Issuer>
<ContentOriginator>
<ContentTitle>
<ContentKind>
<ContentVersionList>
   <ContentVersion>
       <Id>
       <LabelText>
   </ContentVersion>
</ContentVersionList>

[dtatut]

@james-OT : this seems to be a great use for the DS, indeed. By looking at your samples/use cases, it seems that the logical answer to this problem would be the use of RFC6570 (https://tools.ietf.org/html/rfc6570)

What do you think?

[james-OT]

@dtatut While the URI Template method may be useful in other cases within the DS, I'm not sure if it solves any problems for us in this context. Happy to continue further conversation about if I'm missing something though.

In the use case (#2) of the <ContentTitle> --> <Id>, our idea is to simply express the URN "prefix", with the additional text of [some_value] in the DS. So for example, when urn:genripedia:[eidr value] is surfaced to the user (e.g. IMF manufacturing vendor), their SOP is to fill in the EIDR value in that part of the string. So final value becomes: <Id>urn:genripedia:123456</Id> in the final CPL.