Add links to MOS protocol documentation e.g. roCreate docstring would link to http://mosprotocol.com/wp-content/MOS-Protocol-Documents/MOSProtocolVersion40/index.html#calibre_link-32

Decide if we should depart from the mos protocol convention in roStorySend where the following is used:

<roStorySend>
 <storyBody>
  <p>
  <p>
  <storyItem></storyItem>
  <p>
  <storyItem></storyItem>
 </storyBody>
</roStorySend>

We currently flatten to to <story><item>...</item></story>

By flattening, we depart from the mos convention for stories, and also make final.xml less easy to comprehend from a structural perspective, where <p> and <storyItem> are truly children of <storyBody>, not peers of, for example, <storySlug>.

Given

• In some working scenarios, MOS servers are configured to emit main and reserve path traffic.
• In these circumstances, MOS messages, when collated by receiving MOS devices (that can have main and buddy servers defined), the main path and reserve path messages end up saved side-by-side in the same directory
• mosromgr does not work correctly when processing a directory of mixed main and reserve MOS messages received for the same running order

When
mosromgr loads MOS messages from a directory

Then
A filtering process should be applied to messages to skip those arriving via the buddy NCS server

AC/s

• That MOSROMGR will correctly order stories on a client configured with main and buddy NCS servers

BBC use of main and buddy
Main and buddy NCS configurations are common across the BBC. See this recent example in Cardiff where Autoscript clients are configured with main and buddy server connections.
The FIP servers in News are configured with main and buddy connections.

Developer notes
Messages that emit from main and buddy servers feature a handy way to identify buddy messages.

A typical main message contains the following basic data:

<mos>
  <mosID>mosid.w1.bbc.mos</mosID>
  <ncsID>ncsid.w1.bbc.mos</ncsID>
  <roCreate>
  ...
  </roCreate>
</mos>

A typical buddy message contains the following basic data:

<mos>
  <mosID>mosid.w1.bbc.mos</mosID>
  <ncsID>mosid.salford.bbc.mos</ncsID>
  <roCreate>
  ...
  </roCreate>
</mos>

The tell-tail sign of a buddy message is a consistent difference between the domain_name values for used in the mosID vs ncsID elements in the message.

To

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.

Decide /quickly/ if we should be departing from the mos protocol spec here, before we get too many (any) customers that rely on the schema of this document.

We need to add a non-strict mode to MosCollection to allow merges with errors to pass as warnings.

We've noticed stories occasionally ending up in the wrong order, and we've found one example of a root cause - but there could be more similar instances as it's about how edge cases are handled.

The bug we've found lies in EAStoryMove.merge(), specifically on line #1705. Essentially it boils down to the case when a story is moved to the bottom - as this message doesn't include a story id to move the story below. The logic for working out where to place the story counts the number of story tags, and inserts the story at that position - but this counting doesn't account for any non-story tags at the same level.

The same bug probably exists in other places, such as EAItemMove.

I can add a test which will demonstrate this bug, and it should be easy to fix, but we should really expand the tests to include all edge cases.

Test for EAStoryMove merge: https://github.com/bbc/mosromgr/blob/main/tests/mostypes/test_mostypes.py#L299 so we need to add a test for a case where the story is being moved to the bottom.

Describe the merge processes in the MosFile merge method docstrings

Currently the RunningOrderControl class assumes it is one type (the one we use for MOSART timing) but there are others which are different - it might need to be a whole set of subclasses like ElementAction. Additional types not essential but we should not stabilise the API with RunningOrderControl that only works with one type of file.