Implement roElementStat

[bevand10]

Given
That the BBC have requested OpenMedia/CGI to implement <roElementStat element="STORY"> messages here

Then
We need to ensure that this library can support the message they are expecting.

ACs

• That when a <roElementStat type="STORY"> messages appears it is processed.

Developer Notes
A typical message is of the form:

<mos>
   <mosID>aircache.newscenter.com</mosID>
   <ncsID>ncs.newscenter.com</ncsID>
   <messageID>506702</messageID>
   <roElementStat element = "STORY">
      <roID>5PM</roID>
      <storyID>HOTEL FIRE </storyID>
      <status>PLAY</status>
      <time>1999-04-11T14:13:53</time>
  </roElementStat>
</mos>

This example is taken directly from the MOS Protocol specification: https://mosprotocol.com/wp-content/MOS-Protocol-Documents/MOS_Protocol_Version_2.8.5_Final.htm#_3.8.2_roElementStat_-_Status%20of%20a%20S

The message will generally have two recognised values for <status> (these are the ones the BBC have asked CGI to implement):

• PLAY - indicates that this story was "started" (transmitted) at the <time> given.
• STOP - indicates that this story was "finished" (no longer the active story) at the <time> given.

Effect of receiving one of these messages

• That an attribute be added to the STORY structure that retains the PLAY and STOP times. The suggested element to add to the <story> element within FINAL.XML is either:

<story>
...
  <roElementStatPLAY messageID="506702"/>1999-04-11T14:13:53</roElementStatPLAY>
  <roElementStatSTOP messageID="506705"/>1999-04-11T14:15:21</roElementStatSTOP>
...
</story>

or probably better, the elements could be added to the more generic <mosExternalMetadata> STORY child element as follows:

...
<story>
...
  <mosExternalMetadata>
    <mosPayload>
      .....
      <roElementStatPLAY messageID="506702"/>1999-04-11T14:13:53</roElementStatPLAY>
      <roElementStatSTOP messageID="506705"/>1999-04-11T14:15:21</roElementStatSTOP>
    </mosPayload>
  </mosExternalMetadata>
</story>
...

There are other potential values for the <status> value in the incoming MOS message - these include:

• EXECUTE
• PAUSE
• SIGNAL

and could all be covered by the above suggested construct.

BBC: Database considerations
These additional time values are actuals so should probably be stored separately against each story - i.e. we shouldn't overwrite the 'estimated' story duration we build by adding item and script duration times. These should augment those estimates, and if/when available, be used in down-stream processing systems (e.g. creating super-stories JSON/OTIO documents, SMP markers, PIPS chapters etc, etc).

Handling absence of STOP times
Though this is not what we have asked CGI to implement, should our database only possess a series of PLAY times, then we should consider creating "fake" STOP times as follows:

<roElementStatSTOP origin="calculated">1999-04-11T14:13:53</roElementStatSTOP>

roElementStat for other element types
In the MOS spec, roElementStat> messages could arrive for other types as follows:

• RO - applies to the running order. roID will be supplied to 'locate' the message.
• ITEM - applies to an item within a story. itemID will be supplied to 'locate' the message.

Whichever approach is taken to store and 'export' the actual timing data provided by <roElementStat>, for full coverage of the MOS spec, the behaviour should be equally applied to RO and ITEM, as well as STORY.