MOS is one of the most successful broadcast protocols ever created, and at the core of its stability is its XML structure. While many broadcasters rely on MOS daily for graphics, playout, automation, and editorial synchronization, very few understand how MOS actually looks under the hood. For engineers and system integrators working with rundown software, it is vital to understand these structures in detail.
A MOS message is an XML document that represents either a rundown, a story, a media object, or a control instruction. The protocol was created in the 1990s with simplicity, readability, and determinism in mind. XML, though old, remains ideal for this because it is structured, verbose, and easy for devices to parse in predictable ways.
A typical MOS message begins with the root element <mos>. Inside this wrapper is the MOSID, the message type, and the data payload. The MOSID represents the device sending or receiving the message. This allows the rundown system to distinguish between multiple graphics engines, multiple video servers, or multiple automation devices.
One of the most important structures is the “roCreate” message, used when a rundown is first created. Inside roCreate is the rundown slug, the rundown ID, and a list of all stories. Each story contains:
- a story ID
- a sequence number
- a slug
- a timing field
- attached MOS objects
- script content in XML
- story type metadata
Each of these elements must appear in a specific order for deterministic parsing. MOS devices expect consistency. For example, an older MOS graphics engine may break if optional fields appear in the wrong location.
MOS story messages use structures like <roStorySend> or <roStoryReplace>. These include: <storyID> <storySlug> <mosExternalMetadata> <mosObjects> <content>
MOS objects are described separately using mosObjCreate messages. These include fields describing:
object ID
object path
template name
field values
thumbnail data
status
update flags
The relationship between story IDs and MOS object IDs is crucial. If a story references an object ID that does not exist, devices may fail to prepare elements for playout. Strong broadcast rundown software validates these references before sending MOS updates.
Another complexity is script formatting. Scripts are embedded using MOS Script format, which includes markup for italics, bold, line breaks, presenter notes, and placeholders. Prompter systems parse these into readable cue text.
MOS uses versioning. A message may include <mosAbstract> and <mosExternalMetadata> sections to describe template mappings. When MOS devices update objects, the system uses revision numbers to ensure outdated versions are not used.
MOS messages also include heartbeat and ping mechanisms. Devices send <mosHeartbeat> to indicate they are alive. Rundown systems acknowledge with a <mosAck> message. If heartbeats stop arriving, the newsroom must assume that the device failed or went offline.
One of the biggest challenges is dealing with vendor-specific MOS extensions. Many devices implement MOS slightly differently. A modern cloud-based rundown system must normalize these variations before sending or interpreting messages.
The final complexity is ordering. MOS relies on strict sequencing. A roStoryReplace must never arrive before roCreate. A mosObjCreate must arrive before the story referencing it. Gateways often maintain ordering buffers to ensure compliance.
Understanding MOS XML internals is not just technical trivia. It is the foundation of how modern broadcasters synchronize rundowns with graphics, video, and automation systems. Tools like Falcon Rundown must interpret, generate, and validate these XML structures precisely to maintain compatibility with the entire broadcast ecosystem.