MOS object definition

[nytamin]

This is a proposal to add a specification for how an OGraf MOS-object should look like.

Background

The MOS-protocol allows for arbitrary (vendor-specific) objects to be defined inside the <mosExternalMetadata> tags. I believe it would be useful to expand the OGraf specification early to include a specification for MOS-OGraf-objects, as this could cause an interoperable ecosystem of MOS-plugins and automation systems to emerge.

Proposal

Note: This proposal is dependent of the upcoming ServerAPI definition, as the properties of the MOS-object will be used by a Controller which will (likely) communicate with an OGraf-compatible API.

I propose that an OGraf graphic instance is defined under <mosExternalMetadata> below:

<storyItem>
  <itemID>1</itemID>
  <itemSlug>L3D: John Doe, OGraf expert</itemSlug>
  <objID>ABC123</objID>
  <mosID>myMosId</mosID>
  <itemEdStart>0</itemEdStart>
  <itemEdDur>7000</itemEdDur>
  <mosExternalMetadata>
    <mosScope>PLAYLIST</mosScope>
    <mosSchema>https://ograf.ebu.io/v1/specification/mos-schemas/ograf-object.dtd</mosSchema>
    <mosPayload>

      <!--
        (Optional) rendererId, used by a MOS-plugin to set which Renderer the graphic is intended for.
      -->
      <rendererId>renderer-0</rendererId>

      <!--
        (Optional) renderTarget, used by a MOS-plugin to set which RenderTarget the graphic is intended for.
        Note: CDATA must be used to wrap the JSON content.
      -->
      <renderTarget><![CDATA[{ "layerId": "layer-0" }]]></renderTarget>

      <!--
        graphicId, the ID of the graphic to be used.
      -->
      <graphicId>gfx/lowerthird</graphicId>

      <!--
        data, JSON data to be sent into the graphic.
        Note: CDATA must be used to wrap the JSON content.
      -->
      <data><![CDATA[{ "name": "John Doe", "title": "OGraf expert" }]]></data>

      <!-- 
        (Optional) customActions, a list of actions intended to be presented to a user at the time of playout.
        The user can pick from these actions to trigger a change in the graphic.
      -->
      <customActions>
        <action>

          <!-- Id of the customAction to call -->
          <actionId>action0</actionId>

          <!-- Payload to send into the customAction -->
          <payload><![CDATA[{ "data": "123" }]]></payload>

        </action>
      </customActions>
    </mosPayload>
  </mosExternalMetadata>
</storyItem>

[didikunz]

Looks good to me.

One thing: why do you suggest to use JSON strings inside these nodes? Would it not be easier to use XML key/value pairs for it? Maybe that would be understandable for the MOS side of things. I understand, that there needs to be a step in the controller code, where these key/value pairs would need to be transformed to JSON for the templates to understand them, as we do not allow XML there (as in Caspar).

[nytamin]

My reasoning for specifying the <data> content as JSON-wrapped-in-CDATA is so that it can be sent straight (unmodified) into the OGraf graphic (which accepts JSON only).

The OGraf manifest for a graphic can specify its data to be an object with deeply nested objects and arrays. If we'd go for XML-data we would have to specify how the XML would be converted to JSON before being sent into the OGraf graphic (and also there is the problem of XML not being one-to-one compatible with JSON).

[nytamin]

Notes from Working Group meeting 2025-10-29:

• This seems vendor-specific, could this be an example provided rather than part of the standard itself?
• Does this proposal contain enough information to be useful?

No conclusion, to be discussed at a later time