MOS Protocol version 2.6
Document Revision WD-2001-08-09
Revision Date Thursday, August 09,
2001
Copyright 2001, All Rights
Reserved.
This document is provided to
You under the conditions outlined below.
These conditions are designed to guarantee the integrity of the MOSä Protocol and to ensure the compatibility of
solutions implementing the MOSä Protocol. Use
or implementation of the MOSä
Protocol as described herein, may only occur if You agree to these
conditions. Failure to follow these
conditions shall void this license.
“You” shall mean you as an individual, or, where appropriate, the
company or other entity on whose behalf you are using this document, and
includes any entity which controls, is controlled by, or is under common
control with You.
You must agree to the
following in order to use the MOSä Protocol:
MOS is a three year old, evolving
protocol for communications between Newsroom Computer Systems (NCS) and Media Object
Servers (MOS) such as Video Servers, Audio Servers, Still Stores, and Character
Generators. The MOS Protocol development
is supported through cooperative collaboration among equipment vendors,
software vendors and end users.
This document reflects
changes to the MOS protocol made during the MOS meeting at NAB 2001 and is
referred to as MOS v2.6. Logic and
message content of MOS v 2.5 have undergone minor changes based on agreements
reached in the NAB 2001 meeting. Three
additional messages and one additional data structure have been added to v2.6
and are noted below in bold red.
The document contains
bookmarks and hyperlinks. The Table of
Contents and other areas contain underlined.
Depending on the viewer application used, clicking or double clicking on
underlined links should take the viewer to the relevant portion of the
document.
Examples of each MOS message
and data structure are included. These
messages may be used for testing. Developers
are encouraged to cut these messages from the document, change the value of ID
tags as appropriate, and paste the modified messages into validation tools. Other than these example messages, validation
tools are not provided by the MOS Group.
1. Introduction
1.1 Message Exchange
1.2 Identification
1.3 Encoding
2. MOS
Message Format
2.1 Extensible Markup Language (XML)
2.2 Message Acknowledgement
2.3 Message Transport
2.4 Unknown Tags
2.5 Object Description Format
2.6 Languages
2.7 Numbers
2.8 Running Orders
2.9 Samples
3. “mos” (Media Object Server) family of messages
3.1 mosAck
- Acknowledge MOS Object Description
3.2 mosObj
- MOS Object Description
3.3 mosReqObj - Request Object Description
3.10 mosReqAll - Request All Object Data from MOS
3.11 mosListAll - Listing of All Object Data from MOS
3.20 mosObjCreate – Mos Object Create
3.21 mosItemReplace – Replace an Item
Reference in an NCS Story with updated Item sent from the MOS
4. “ro” (Running Order)
family of messages
4.1 roAck - Acknowledge Running Order
4.2 roCreate – Create
Running Order
4.3 roReplace - Replace Running Order
4.4 roMetadataReplace – Replace the
metadata associated with a RO Playlist
4.5 roDelete - Delete Running Order
4.11 roReq - Request Running Order
4.12 roList - List Running Order
4.13 roReqAll - Request All Running Order Descriptions
4.14 roListAll - List All Running Order Descriptions
4.15 roStat - Status of a MOS Running Order
4.16 roReadyToAir - Identify a Running Order as Ready to Air
4.21 roStoryAppend - Append Stories to Running
Order
4.22 roStoryInsert - Insert Stories in Running
Order
4.23 roStoryReplace
- Replace Story with Another in a Running Order
4.24 roStoryMove – Move a Story to a
specific location in a Running Order
4.25 roStorySwap -
Swap Positions of Stories in Running Order
4.26 roStoryDelete - Delete Stories from
Running Order
4.31 roItemStat - Status of a Single Item in a MOS
Running Order
4.32 roItemCue – Notification of an Item Event
4.33 roCtrl –
Running Order Control
4.41 roStorySend –
Sends story information, including body, from Running Order
5. Other messages
and data structures
5.1 heartbeat - Connection Confidence Indicator
5.2 reqMachInfo -
Request Machine Information
5.3 listMachInfo
- Machine Description List
5.4 mosExternalMetadata – Method
for including and transporting Metadata defined external to MOS
5.5 mosItemReference – Metadata
block transferred by ActiveX Controls
7.1 Changes from MOS version 2.5 to 2.6 WD-2001-06-06
7.2 Changes from MOS version 2.0 to
2.5 WD-2000-08-01
7.3 Changes for MOS 2.0 WD-1999-05-12
7.4 Changes from MOS version
1.52 to 2.0 WD-1999-03-17
7. MOS 2.6 DTD
8. References and Resources
8.1 MOS Protocol Web Page
8.2 XML
FAQ
8.3 Recommended Reading
8.4 XML Web Sites
This document reflects changes to the MOS protocol made during the MOS meeting at NAB 2001.
Three new messages and one new data structure were added: mosItemReplace, roMetadataReplace, roStoryMove, and mosExternalMetadata.
A reminder: MOS equipment should ignore, without error, any unknown tags in a message, so long as the message or structure contains properly formatted XML content and the minimum subset of required MOS tags for that message or structure.
Both the NCS and MOS can
originate messages. Transmitted messages require a response from the
receiver before the transmitter will attempt to send the next message in the
queue belonging to that specific port (either upper or lower). Upper and
lower port messages are not related so that while a machine is waiting for a
response on the lower port it may continue to have a dialog on the upper port.
Note: "Two Ports - Four Sockets" Each pair of communicating machines uses two ports. Each machine must be able to accept and handle messages on a minimum of two sockets per port. Once established, socket connections do not need to be dropped and then re-established between messages. Generally, the acknowledgment of a message should be sent down the same socket on which the original message was received. However, machines should be able to handle situations in which each message arrives in a separate, discrete socket session (though this is not very efficient).
/----Socket1
\----Socket2
/----Socket1
\----Socket2
Note: "Multiple MOS Connections" Each machine (NCS and MOS) should be capable of establishing and maintaining connections to multiple systems of the opposite type. e.g. An NCS should be capable of connecting to multiple Media Object Servers. Media Object Servers should also be capable of connecting to multiple NCSs.
In practice the MOS and NCS character names are predefined in each system and IP addresses associated with each name.
The supported character encoding is ISO 10646 (Unicode) in UCS-2, as defined in The Unicode Standard, version 2.0. All MOS message contents are transmitted in Unicode, high-order byte first.
The MOS Protocol is fundamentally
a tagged text data stream. In the version 2.x, data fields are character
delimited using Extensible Markup Language (XML™) tags defined in the MOS Data
Type Definition (DTD). In MOS v1.x data fields were delimited using a
proprietary format.
The syntax of MOS v2.6 is an
application of XML, an international standard for describing document content
structure. XML is a simple, flexible text format based on SGML (ISO 8879). XML
is an abbreviated version of SGML, to make it easier for you to define your own
document types, and to make it easier for programmers to write programs to
handle them. It omits the more complex and less-used parts of SGML in return
for the benefits of being easier to write applications, easier to understand,
and more suited to delivery and interoperability over the Web.
All tags are case sensitive.
All MOS messages must be well formed XML, but are not required to be valid.
Each MOS message begins with
the root tag (“mos”), followed by the MOS and NCS ID (“mosID” and “ncsID”), and
followed by the message type. Data follows in tagged form.
Vendors are encouraged to add CR/LF and Tabs within a message to improve readability for debugging purposes.
When a message is sent by one device, it will not send another message until it receives an acknowledgement (“ACK”) or error (“NACK”) from the other device. Vendors should reset and/or retry when a timeout occurs.
Ports 10520 and 10521 were
specified as Lower and
Because some vendors
reported problems using port 10521 with Microsoft Windows NT the new port
numbers used as examples are now 10540 and 10541.
For example, an NCS
initiated create running order command and the MOS' associated ACK would take
place on
Should a MOS or NCS encounter an unknown message or data tag the device should ignore the tag and the data and continue to process the message. Unknown data tags should not generate an application error. The application has the option of indicating a warning.
Object description is restricted to plain Unicode UCS-2 text that includes Tab, CR, LF and the optional markup for paragraphs, tabs and emphasis. Formatted text such as HTML, RTF, etc. will not be allowed in the unstructured description area.
Data tags and constants are
formatted as English.
The only Data Fields that can contain
other languages are:
createdBy
modifiedBy
roSlug
storySlug
storyBody
itemSlug
description
And the data structure mosExternalMetadata
Numbers are formatted as
their text equivalent, e.g.:
The
decimal number 100 is represented as text “100”.
Hex FF55
is represented as text “0xFF55” or “xFF55”.
1) Running Order (Unique ID - may appear only once in the NCS)
2) Story (Unique ID - may
appear only once in the RO)
3) Item
(Unique ID - may appear only once in a story)
4) Object (Unique ID - may appear only once in an item)
It is assumed that all
Unique ID’s (UID’s) created by one machine are respected by others.
Order of data fields within an item is significant.
Items are sent in the order they should be played.
Order of items is significant.
Multiple Running Orders may contain the same Story.
Running Orders may contain zero or more Stories.
Multiple stories can contain the same Object referenced by different Items.
Stories can contain multiple Items.
Item IDs may appear only once in a Story, but can appear in other Stories.
Objects can appear multiple times in a Story, but only one object may appear in
an Item.
A Running Order Item is defined by the combination Running Order.Story.Item and
contains the UID’s of the Running Order, Story and Item which together can
identify a unique Item within a Running Order. Additions, deletions, and moves
within the running order are referenced in this way to the Item.
Still Store and Character Generator media objects are defined as having 1 sample per second. They are special cases that require the NCS and MOS applications to understand they do not change every second.
In the Structural Outline
sections below use of “?” specifies optional element, “+” specifies one or more
of the element, and “*”specifies zero or more of the element. Elements without
any of these three special characters are required.
Tags enclosed in parenthesis and
separated by "|" represent a selection.
The Syntax section shows the definition
of non-terminals for this message from the DTD.
Examples shown are representative of
syntax only and do not represent samples from any system.
The MOS Acknowledgement for the MOS OBJ message.
N/A
mos
mosID
ncsID
mosAck
objID
objRev
status
statusDescription
<!ELEMENT mosAck
(objID, objRev, status, statusDescription)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<mosAck>
<objID>M000123</objID>
<objRev>1</objRev>
<status>ACK</status>
<statusDescription></statusDescription>
</mosAck>
</mos>
Contains information that
describes a unique MOS Object to the NCS. The NCS uses this information to
search for and reference the MOS Object.
No specific values for this
element are officially defined.
Definition of values is left to the configuration and agreement of MOS
connected equipment. The intended use is
for site configuration of a limited number of locally named storage folders in
the NCS or MOS, such as “ControlA”, “ControlB” , “Raw”, “Finished”, etc. For editorially descriptive “category”
information, it is suggested that the <externalMetadata> block be used.
This data block can appear in several messages as a mechanism for transporting additional metadata, independent of schema or DTD. When found within the mosObj message, this block carries data defined external to the MOS Protocol.
The value of the <scope> tag implies through what production processes this information should travel.
A scope of “object” implies
this information is generally descriptive of the object and appropriate for
queries. The metadata should not be
forwarded into Stories or Playlists.
A scope of “story” suggests
this information may determine how the Object is to be applied in a Story. For instance, Intellectual Property
Management. This information should be
forwarded with the contents of a Story.
A scope of “playlist”
suggests this information is specific to describing how the Object is to be
published, rendered, or played to air and thus, should be included in the
roCreate Play List Construction and roStorySend messages.
Scope allows systems to,
optionally, roughly filter external metadata and selectively apply it to
different production processes and outputs.
Specifically, it is neither advisable nor efficient to send large
amounts of inappropriate metadata to the Playlist in roCreate messages. In
addition to these blocks of data being potentially very large, the media Object
Server is, presumably, already aware of this data.
mos
mosID
ncsID
mosObj
objID
objSlug
objTB
objRev
objDur
status
objAir
createdBy
created
changedBy
changed
description
(p | em | tab)*
mosExternalMetadata*
mosScope?
<!ELEMENT mosObj
(objID, objSlug, mosAbstract, objGroup?, objType, objTB, objRev, objDur,
status, objAir, createdBy, created, changedBy, changed, description,
mosExternalMetadata*)>
<!ELEMENT description (#PCDATA | p
| em | tab)*>
<!ELEMENT p (#PCDATA | em |
tab)*>
<!ELEMENT
mosExternalMetadata (mosScope?, mosSchema, mosPayload)>
<!ELEMENT mosScope
(object | story | playlist)>
<!ELEMENT mosSchema
(#PCDATA)>
<!ELEMENT mosPayload
(#PCDATA)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<mosObj>
<objID>M000123</objID>
<objSlug>Hotel Fire</objSlug>
<mosAbstract>
<b>Hotel Fire</b>
<em>vo</em>
:30
</mosAbstract>
<objGroup>Show 7</objGroup>
<objType>VIDEO</objType>
<objTB>60</objTB>
<objRev>1</objRev>
<objDur>1800</objDur>
<status>NEW</status>
<objAir>READY</objAir>
<createdBy>Chris</createdBy>
<created>1998-10-31T23:39:12</created>
<changedBy>Chris</changedBy>
<changed>1998-10-31T23:39:12</changed>
<description>
<p>
Exterior footage of
<em>Baley Park
Hotel</em>
on fire with natural sound. Trucks
are visible for the first portion of the clip.
<em>CG locator at 0:04 and
duration 0:05, Baley Park Hotel.</em>
</p>
<p>
<tab/>
Cuts to view of fire personnel
exiting hotel lobby and cleaning up after the fire is out.
</p>
<p>
<em>Clip has been doubled for
pad on voice over.</em>
</p>
</description>
<mosExternalMetadata>
<mosScope>STORY</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<ModTime>20010308142001</ModTime>
<mediaTime>0</mediaTime>
<TextTime>278</TextTime>
<ModBy>LJOHNSTON</ModBy>
<Approved>0</Approved>
<Creator>SHOLMES</Creator>
</mosPayload>
</mosExternalMetadata>
</mosObj>
</mos>
Message used by NCS to
request object description.
mosObj
- if objID is found
mosAck - otherwise
mos
mosID
ncsID
mosReqObj
objID
<!ELEMENT mosReqObj
(objID)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<mosReqObj>
<objID>M000123</objID>
</mosReqObj>
</mos>
Method for the NCS to
request the MOS send it mosObj messages for every Object
in the MOS. Pause, when greater than zero, indicates the number of seconds to
pause between MOS objects in the mosListAll message.
Pause of zero indicates that all objects should be sent using mosObj messages.
mosListAll
- if pause > 0
mosObj - otherwise
mos
mosID
ncsID
mosReqAll
pause
<!ELEMENT mosReqAll
(pause)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<mosReqAll>
<pause>0</pause>
</mosReqAll>
</mos>
Send MOS object descriptions
in a format similar to mosObj sequentially from the MOS
to the NCS in response to the mosReqAll message. There
is a pause between each object as defined in the mosReqAll message.
None
mos
mosID
ncsID
mosListAll
(objID, objSlug, mosAbstract?, objGroup?, objType, objTB, objRev,
objDur, status, objAir,
createdBy, created, changedBy, changed, description, mosExternalMetadata*)+
<!ELEMENT mosListAll
((objID, objSlug, mosAbstract?, objGroup?, objType, objTB, objRev, objDur,
status, objAir, createdBy, created, changedBy, changed, description,
mosExternalMetadata*)*)>
<!ELEMENT description (#PCDATA | p
| em | tab)*>
<!ELEMENT p (#PCDATA | em |
tab)*>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<mosListAll>
<objID>M000123</objID>
<objSlug>HOTEL FIRE</objSlug>
<objType>VIDEO</objType>
<objCategory>RAW</objGroup>
<objTB>60</objTB>
<objRev>3</objRev>
<objDur>1530</objDur>
<status>UPDATED</status>
<objAir>READY</objAir>
<createdBy>Chris</createdBy>
<created>1998-10-31T23:39:12</created>
<changedBy>Chris</changedBy>
<changed>1998-11-01T14:35:55</changed>
<description>
<p>
Exterior footage of
<em>Baley Park
Hotel</em>
on fire with natural sound. Trucks
are visible for the first portion of the clip.
<em>CG locator at 0:04 and
duration 0:05, Baley Park Hotel.</em>
</p>
<p>
<tab/>
Cuts to view of fire personnel
exiting hotel lobby and cleaning up after the fire is out.
</p>
<p>
<em>Clip has been doubled for
pad on voice over.</em>
</p>
</description>
<objID>M000224</objID>
<objSlug>COLSTAT
MURDER:VO</objSlug>
<objType>VIDEO</objType>
<objTB>60</objTB>
<objRev>4</objRev>
<objDur>800</objDur>
<status>UPDATED</status>
<objAir>READY</objAir>
<createdBy>Phil</createdBy>
<created>1998-11-01T15:
<changedBy>Chris</changedBy>
<changed>1998-11-01T15:
<description>VOICE OVER MATERIAL OF
COLSTAT MURDER SITES SHOT ON 1-NOV.</description>
<mosExternalMetadata>
<mosScope>STORY</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<ModTime>20010308142001</ModTime>
<mediaTime>0</mediaTime>
<TextTime>278</TextTime>
<ModBy>LJOHNSTON</ModBy>
<Approved>0</Approved>
<Creator>SHOLMES</Creator>
</mosPayload>
</mosExternalMetadata>
</mosListAll>
</mos>
Allows an NCS to request the Media Object Server to
create a Media Object with specific metadata associated with it.
mosAck (if
object can be created then status description = objID)
NACK
(if object CANNOT be created. status description = reason for error)
mosObj
mos
mosID
ncsID
mosObjCreate
objSlug
objGroup?
objType
objTB
objDur?
time?
createdBy?
description?
<!ELEMENT mosObjCreate
(objSlug, objGroup?, objType, objTB, objDur?, time?, createdBy?, description?,
mosExternalMetadata*)>
<!ELEMENT description (#PCDATA | p
| em | tab)*>
<!ELEMENT p (#PCDATA |
em | tab)*>
<mos>
<mosID>videoserver.station.com</mosID>
<ncsID>ncs.station.com</ncsID>
<mosObjCreate>
<objSlug>Hotel Fire</objSlug>
<objGroup>Show 7</objGroup>
<objType>VIDEO</objType>
<objTB>60</objTB>
<objDur>1800</objDur>
<createdBy>Chris</createdBy>
<description>
<p>
Exterior footage of
<em>Baley Park Hotel</em>
on fire with natural sound. Trucks are
visible
for the first portion of the clip.
<em>CG locator at 0:04 and duration 0:05,
Hotel.</em>
</p>
<p>
<tab/>
Cuts to view of fire personnel exiting hotel lobby and cleaning up after
the fire is out.
</p>
<p>
<em>Clip has been doubled for pad on voice over.</em>
</p>
</description>
<mosExternalMetadata>
<mosScope>STORY</mosScope>
<mosSchema>http://NCSA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<ModTime>20010308142001</ModTime>
<mediaTime>0</mediaTime>
<TextTime>278</TextTime>
<ModBy>LJOHNSTON</ModBy>
<Approved>0</Approved>
<Creator>SHOLMES</Creator>
</mosPayload>
</mosExternalMetadata>
</mosObjCreate>
</mos>
This message allows a media
Object Server to replace an Item Reference in a Story with new metadata values
and/or additional tags. The Story must
be in a MOS Active Play List. Thus, this
message is in the “ro” family of messages rather than the “mos,” or lower port,
family. However, this message is
initiated by the media Object Server, rather than the NCS.
This message must reference
as existing unique Item Reference in a MOS Active Play List through the values
of ncsID, roID, storyID, and itemID.
If metadata tags in the mosItemReplace
message already exist in the target Item Reference, values within the Item
Reference will be replaced by the values in the mosItemReplace message.
If the metadata tags do not
already exist in the target Item Reference they will be added.
If a mosExternalMetadata
block is included in the mosItemReplace message, it will replace an existing
mosExternalMetadata block only if
the values of <mosSchema> in the two blocks match, and only for the first
occurrence of a block with a matching <mosSchema> tag. Otherwise the mosExternalMetadata block will
be added to the target Item Reference.
If the ItemID in the
mosItemReplace message does not match an existing ItemID in the specified Story
then no action will be taken and the mosItemReplace message will be replied to
with an roAck message specifying the Item values in the mosItemReplace message
and carrying a status value of “NACK.”
roStoryReplace
– A successful mosItemReplace operation will result in a change to an Item
reference embedded in a Story. This new
information must now be placed in associated MOS Playlists. The roStoryReplace message will replace the
old item reference in the playlist with the newly updated item reference from
this Story.
roStorySend
– A successful mosItemReplace operation will result in a change in the body of
a Story. This change must be sent back
out if an roStorySend target has been defined for the RO.
mos
mosID
ncsID
mosItemReplace
roID
storyID
item*
itemID
itemSlug?
objID
mosID
mosAbstract?
itemChannel?
itemEdStart?
itemEdDur?
itemTrigger?
macroIn?
macroOut?
<!ELEMENT mosItemReplace (roID, storyID, item)>
<!ELEMENT item (itemID, itemSlug?,
objID, mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?,
itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*>
<!ELEMENT
mosExternalMetadata (mosScope?, mosSchema, mosPayload)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<mosItemReplace>
<roID>
<storyID>HOTEL FIRE</storyID>
<item>
<itemID>30848</itemID>
<objID>M000627</objID>
<mosID>testmos.enps.com</mosID>
<itemEdStart>0</itemEdStart>
<itemEdDur>815</itemEdDur>
<macroIn>c01/l04/dve07</macroIn>
<macroOut>r00</macroOut>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>HTTP://VVENDOR/MOS/supportedSchemas/vvend280</mosSchema>
<mosPayload>
<trigger>837</trigger>
<key>110</key>
<fade>17</fade>
<efxTime>15</efxTime>
</mosPayload>
</mosExternalMetadata>
</item>
</mosItemReplace>
</mos>
MOS response to receipt of
any Running Order command.
None
mos
mosID
ncsID
roAck
roID
roStatus
(storyID, itemID, objID,
status)*
<!ELEMENT roAck (roID,
roStatus, (storyID, itemID, objID, status)*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roAck>
<roID>96857485</roID>
<roStatus>Unknown object
M000133</roStatus>
<storyID>5983A501:0049B924:8390EF2B</storyID>
<itemID>0</itemID>
<objID>M000224</objID>
<status>LOADED</status>
<storyID>3854737F:0003A34D:983A0B28</storyID>
<itemID>0</itemID>
<objID>M000133</objID>
<status>UNKNOWN</status>
</roAck>
</mos>
Message from the NCS to the
MOS that defines a new Running Order.
mos
mosID
ncsID
roCreate
roID
roSlug
roChannel?
roEdStart?
roEdDur?
roTrigger?
mosExternalMetadata*
story*
storyID
storySlug?
mosExternalMetadata*
item*
itemID
itemSlug?
objID
mosID
mosAbstract?
itemChannel?
itemEdStart?
itemEdDur?
itemTrigger?
macroIn?
macroOut?
<!ELEMENT roCreate
(roID, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroIn?,
macroOut?, mosExternalMetadata*, story*)>
<!ELEMENT story (storyID, storySlug?,
storyNum?, mosExternalMetadata*,
item*)>
<!ELEMENT item (itemID, itemSlug?,
objID, mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?,
itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roCreate>
<roID>96857485</roID>
<roSlug>5PM RUNDOWN</roSlug>
<roEdStart>1999-04-17T17:
<roEdDur>00:58:25</roEdDur>
<story>
<storyID>5983A501:0049B924:8390EF2B</storyID>
<storySlug>COLSTAT
MURDER</storySlug>
<storyNum>A5</storyNum>
<item>
<itemID>0</itemID>
<itemSlug>COLSTAT
MURDER:VO</itemSlug>
<objID>M000224</objID>
<mosID>testmos.enps.com</mosID>
<itemEdDur>645</itemEdDur>
<itemTrigger>CHAINED</itemTrigger>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
</story>
<story>
<storyID>3854737F:0003A34D:983A0B28</storyID>
<storySlug>AIRLINE
INSPECTIONS</storySlug>
<storyNum>A6</storyNum>
<item>
<itemID>0</itemID>
<objID>M000133</objID>
<mosID>testmos.enps.com</mosID>
<itemEdStart>55</itemEdStart>
<itemEdDur>310</itemEdDur>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
</story>
</roCreate>
</mos>
Replaces an existing Running
Order definition in the MOS with another one sent from the NCS.
mos
mosID
ncsID
roReplace
roID
roSlug
roChannel?
roEdStart?
roEdDur?
roTrigger?
mosExternalMetadata*
story*
storyID
storySlug?
mosExternalMetadata*
item*
itemID
itemSlug?
objID
mosID
mosAbstract?
itemChannel?
itemEdStart?
itemEdDur?
itemTrigger?
macroIn?
macroOut?
<!ELEMENT roReplace (roID,
roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroIn?, macroOut?,
mosExternalMetadata*, story*)>
<!ELEMENT story (storyID, storySlug?,
storyNum?, mosExternalMetadata*,
item*)>
<!ELEMENT item (itemID, itemSlug?,
objID, mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?,
itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roReplace>
<roID>96857485</roID>
<roSlug>5PM RUNDOWN</roSlug>
<story>
<storyID>5983A501:0049B924:8390EF2B</storyID>
<storySlug>COLSTAT
MURDER</storySlug>
<storyNum>A1</storyNum>
<item>
<itemID>0</itemID>
<itemSlug>COLSTAT
MURDER:VO</itemSlug>
<objID>M000224</objID>
<mosID>testmos.enps.com</mosID>
<itemEdDur>645</itemEdDur>
<itemTrigger>CHAINED</itemTrigger>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
</story>
<story>
<storyID>3852737F:0013A64D:923A0B28</storyID>
<storySlug>AIRLINE
SAFETY</storySlug>
<storyNum>A2</storyNum>
<item>
<itemID>0</itemID>
<objID>M000295</objID>
<mosID>testmos.enps.com</mosID>
<itemEdStart>500</itemEdStart>
<itemEdDur>600</itemEdDur>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
</story>
</roReplace>
</mos>
This message allows metadata
associated with a running order to be replaced without deleting the running
order and sending the entire running order again.
This message must reference
an existing running order
If metadata tags in the roMetadataReplace
message already exist in the target
RO, values within the RO will be replaced by the values in the
roMetadataReplace message.
If the metadata tags do not
already exist in the target RO they will be added.
If a mosExternalMetadata block
is included in the roMetadataReplace message, it will replace an existing
mosExternalMetadata block only if
the values of mosSchema in the two blocks match. Otherwise the mosExternalMetadata block will
be added to the target RO.
If the ROID in the roMetadataReplace
message does not match an existing ROID then no action will be taken and the
roMetadataReplace message will be replied to with an roAck message which
carrying a status value of “NACK.”
mos
mosID
ncsID
roMetadataReplace
roID
roSlug
roChannel?
roEdStart?
roEdDur?
roTrigger?
<!ELEMENT roMetadataReplace
(roID, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, roMacroIn?,
roMacroOut?, mosExternalMetadata?)>
Deletes a Running order in
the MOS.
<!ELEMENT roDelete
(roID)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roDelete>
<roID>49478285</roID>
</roDelete>
</mos>
Request for a complete build of a Running Order Playlist.
NOTE: This message can be used by either NCS or MOS
A MOS can use this to “resync” it’s Playlist with the NCS Running Order or to obtain a full description of the Playlist at any time.
An NCS can use this as a diagnostic tool to check the order of the Playlist constructed in the MOS versus the sequence of Items in the Running Order.
roList
or roAck (roAck with a NACK value is sent if the Running
Order ID is not valid or roList cannot be returned for some reason)
<!ELEMENT roReq
(roID)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roReq>
<roID>96857485</roID>
</roReq>
</mos>
A complete build or rebuild of a Running Order Playlist in response to an roReq message.
NOTE: This message can be sent by either the NCS or MOS
A MOS can use this to “resync” it’s Playlist with the NCS Running Order or to obtain a full description of the Playlist at any time.
An NCS can use this as a diagnostic tool to check the order of the Playlist constructed in the MOS versus the sequence of Items in the Running Order.
roList is functionally similar to roCreate.
None
mos
mosID
ncsID
roList
roID
roSlug
roChannel?
roEdStart?
roEdDur?
roTrigger?
mosExternalMetadata*
story*
storyID
storySlug?
mosExternalMetadata*
item*
itemID
itemSlug?
objID
mosID
mosAbstract?
itemChannel?
itemEdStart?
itemEdDur?
itemTrigger?
macroIn?
macroOut?
<!ELEMENT roList (roID,
roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroIn?, macroOut?,
mosExternalMetadata*, story*)>
<!ELEMENT story (storyID, storySlug?,
storyNum?, mosExternalMetadata*,
item*)>
<!ELEMENT item (itemID, itemSlug?,
objID, mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?,
itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roList>
<roID>96857485</roID>
<roSlug>5PM RUNDOWN</roSlug>
<story>
<storyID>5983A501:0049B924:8390EF2B</storyID>
<storySlug>Colstat
Murder</storySlug>
<storyNum>B10</storyNum>
<item>
<itemID>0</itemID>
<itemSlug>COLSTAT
MURDER:VO</itemSlug>
<objID>M000224</objID>
<mosID>testmos.enps.com</mosID>
<itemEdDur>645</itemEdDur>
<itemTrigger>CHAINED</itemTrigger>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
</story>
<story>
<storyID>3854737F:0003A34D:983A0B28</storyID>
<storySlug>Test MOS</storySlug>
<storyNum>B11</storyNum>
<item>
<itemID>0</itemID>
<objID>M000133</objID>
<mosID>testmos.enps.com</mosID>
<itemEdStart>55</itemEdStart>
<itemEdDur>310</itemEdDur>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
</story>
</roList>
</mos>
Request for a description of
all Running Orders known by a NCS from a MOS.
<!ELEMENT roReqAll
EMPTY>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roReqAll/>
</mos>
Provides a description of
all Running Orders known by a NCS to a MOS.
None
mos
mosID
ncsID
roListAll
(roID, roSlug?, roChannel?,
roEdStart?, roEdDur?, roTrigger?, mosExternalMetadata*)*
<!ELEMENT roListAll
((roID, roSlug?, roChannel?, roEdStart?, roEdDur?, roTrigger?,
mosExternalMetadata*)*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roListAll>
<roID>
<roSlug>5PM RUNDOWN</roSlug>
<roEdDur>1733</roEdDur>
<roEdTrigger>MANUAL</roEdTrigger>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://ncsA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<ModTime>20010308142001</ModTime>
<mediaTime>0</mediaTime>
<TextTime>278</TextTime>
<ModBy>LJOHNSTON</ModBy>
<Approved>0</Approved>
<Creator>SHOLMES</Creator>
</mosPayload>
</mosExternalMetadata>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://ncsA4.com/mos/supported_schemas/NCSBBBBXML2.08</mosSchema>
<mosPayload>
<show>
<client>network ctrl
b</client>
</mosPayload>
</mosExternalMetadata>
</roListAll>
</mos>
Method for the MOS to update
the NRC on the status of Play List. This allows the NRC to reflect the
status of the Play List in the NRC Running Order Display.
mos
mosID
ncsID
roStat
roID
status
time
<!ELEMENT roStat
(roID, status, time)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roStat>
<roID>
<status>MANUAL CTRL</status>
<time>1999-04-11T14:
</roStat>
</mos>
The message allows the NCS
to signal the MOS that a Running Order has been editorially approved ready for
air.
mos
mosID
ncsID
roReadyToAir
roID
roAir
<!ELEMENT roReadyToAir
(roID, roAir)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roReadyToAir>
<roID>
<roAir>READY</roAir>
</roReadyToAir>
</mos>
Appends stories and all of
its defined items at the end of a running order.
mos
mosID
ncsID
roStoryAppend
roID
story*
storyID
storySlug?
mosExternalMetadata*
item*
itemID
itemSlug?
objID
mosID
mosAbstract?
itemChannel?
itemEdStart?
itemEdDur?
itemTrigger?
macroIn?
macroOut?
<!ELEMENT
roStoryAppend (roID, story+)>
<!ELEMENT story (storyID,
storySlug?, storyNum?, mosExternalMetadata*, item*)>
<!ELEMENT item (itemID, itemSlug?,
objID, mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?, itemTrigger?,
macroIn?, macroOut?, mosExternalMetadata*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roStoryAppend>
<roID>
<story>
<storyID>V: BRIDGE
COLLAPSE</storyID>
<storySlug>Bridge
Collapse</storySlug>
<storyNum>B7</storyNum>
<item>
<itemID>30848</itemID>
<objID>M000627</objID>
<mosID>testmos.enps.com</mosID>
<itemEdStart>0</itemEdStart>
<itemEdDur>815</itemEdDur>
<macroIn>c01/l04/dve07</macroIn>
<macroOut>r00</macroOut>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSBXML2.08</mosSchema>
<mosPayload>
<rate>52</rate>
<background>2</background>
<overlay>463</overlay>
</mosPayload>
</mosExternalMetadata>
</item>
<item>
<itemID>30849</itemID>
<objID>M000628</objID>
<itemEdStart>0</itemEdStart>
<itemEdDur>815</itemEdDur>
<macroIn>c01/l04/dve07</macroIn>
<macroOut>r00</macroOut>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
</story>
</roStoryAppend>
</mos>
Inserts stories and all of
its defined items before the referenced Story in the running order.
mos
mosID
ncsID
roStoryInsert
roID
storyID
story+
storyID
storySlug?
mosExternalMetadata*
item*
itemID
itemSlug?
objID
mosID
mosAbstract?
itemChannel?
itemEdStart?
itemEdDur?
itemTrigger?
macroIn?
macroOut?
<!ELEMENT
roStoryInsert (roID, storyID, story+)>
<!ELEMENT story (storyID,
storySlug?, storyNum?, mosExternalMetadata*, item*)>
<!ELEMENT item (itemID, itemSlug?,
objID, mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?,
itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roStoryInsert>
<roID>
<storyID>HOTEL FIRE</storyID>
<story>
<storyID>V: BRIDGE
COLLAPSE</storyID>
<storySlug>Bridge
Collapse</storySlug>
<storyNum>B7</storyNum>
<item>
<itemID>30848</itemID>
<objID>M000627</objID>
<mosID>testmos.enps.com</mosID>
<itemEdStart>0</itemEdStart>
<itemEdDur>815</itemEdDur>
<macroIn>c01/l04/dve07</macroIn>
<macroOut>r00</macroOut>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSBXML2.08</mosSchema>
<mosPayload>
<rate>52</rate>
<background>2</background>
<overlay>463</overlay>
</mosPayload>
</mosExternalMetadata>
</item>
<item>
<itemID>30849</itemID>
<objID>M000628</objID>
<itemEdStart>0</itemEdStart>
<itemEdDur>815</itemEdDur>
<macroIn>c01/l04/dve07</macroIn>
<macroOut>r00</macroOut>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
</story>
</roStoryInsert>
</mos>
Replaces the referenced
story with another story or stories and all of its associated Items in the
Running Order.
mos
mosID
ncsID
roStoryReplace
roID
storyID
story+
storyID
storySlug?
mosExternalMetadata*
item*
itemID
itemSlug?
objID
mosID
mosAbstract?
itemChannel?
itemEdStart?
itemEdDur?
itemTrigger?
macroIn?
macroOut?
<!ELEMENT
roStoryReplace (roID, storyID, story+)>
<!ELEMENT story (storyID,
storySlug?, storyNum?, mosExternalMetadata*,
item*)>
<!ELEMENT item (itemID, itemSlug?,
objID, mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?,
itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roStoryReplace>
<roID>
<storyID>P: PHILLIPS
INTERVIEW</storyID>
<story>
<storyID>V: HOTEL
FIRE</storyID>
<storySlug>Hotel
Fire</storySlug>
<storyNum>C1</storyNum>
<item>
<itemID>30848</itemID>
<itemSlug>Hotel Fire
vo</itemSlug>
<objID>M000702</objID>
<mosID>testmos</mosID>
<itemEdStart>0</itemEdStart>
<itemEdDur>900</itemEdDur>
<macroIn>c01/l04/dve07</macroIn>
<macroOut>r00</macroOut>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
</story>
<story>
<storyID>V: DORMITORY
FIRE</storyID>
<storySlug>Dormitory
Fire</storySlug>
<storyNum>C2</storyNum>
<item>
<itemID>1</itemID>
<itemSlug>Dormitory Fire
vo</itemSlug>
<objID>M000705</objID>
<mosID>testmos</mosID>
<itemEdStart>0</itemEdStart>
<itemEdDur>800</itemEdDur>
<macroIn>c01/l04/dve07</macroIn>
<macroOut>r00</macroOut>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
</story>
</roStoryReplace>
</mos>
This message allows a story
to be moved to a new location in a playlist.
The first storyID is the ID of the story to be moved. The second storyID is the ID of the story
above which the first story is to be moved.
**note**If the second
<storyID> tag is blank move to the bottom.
mos
mosID
ncsID
roStoryMove
roID
storyID
storyID
<!ELEMENT roStoryMove
(roID, storyID, storyID)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roStoryMove>
<roID>
<StoryID>V: BRIDGE
COLLAPSE</StoryID>
<StoryID>P: PHILLIPS
INTERVIEW</StoryID>
</roStoryMove>
</mos>
Swaps the Positions of
stories and all of their associated Items in the Running Order.
mos
mosID
ncsID
roStorySwap
roID
storyID
storyID
<!ELEMENT roStorySwap
(roID, storyID, storyID)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roStorySwap>
<roID>
<storyID>V: BRIDGE
COLLAPSE</storyID>
<storyID>P: PHILLIPS
INTERVIEW</storyID>
</roStorySwap>
</mos>
Deletes the referenced
Stories and all associated Items from the Running Order.
mos
mosID
ncsID
roStoryDelete
roID
storyID+
<!ELEMENT
roStoryDelete (roID, storyID+)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roStoryDelete>
<roID>
<storyID>V: BRIDGE
COLLAPSE</storyID>
<storyID>P: PHILLIPS
INTERVIEW</storyID>
</roStoryDelete>
</mos>
Method for the MOS to update
the NCS on the status of an individual Item in a Running Order. This allows the
NCS to reflect the status of individual Items in the MOS Running Order in the NCS
Running Order display.
mos
mosID
ncsID
roItemStat
roID
storyID
itemID
objID
status
time
<!ELEMENT roItemStat
(roID, storyID, itemID, objID, status, time)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roItemStat>
<roID>
<storyID>HOTEL FIRE</storyID>
<itemID>0</itemID>
<objID>A0295</objID>
<status>PLAY</status>
<time>1999-04-11T14:
</roItemStat>
</mos>
Allows a device, such as prompter, to send a time cue for an Item.
This command allows a non MOS or NCS device to send a time cue to the parent Media Object Server (or Automation MOS) for a specific Item event. This is not a command to execute or play. Instead, this is intended to provide feedback to the parent device as to the current execution point of the program.
The values <mosID>, <roID>, <storyID>, and <itemID> are derived from the Item reference embedded in a story. The story information is assumed to be transmitted via the roStorySend message.
The Media Object Server or automation device that receives this command may use this information to update status or generate device triggers. Optionally, the message may be redirected to the NCS as a means of providing additional status information.
roAck
mos
mosID
ncsID
roItemCue
mosID
roID
storyID
itemID
roEventType
<!ELEMENT roItemCue (mosID, roID, storyID,
itemID, roEventType, roEventTime, mosExternalMetadata*)>
<!ELEMENT roEventType (#PCDATA)>
<!ELEMENT roEventTime (#PCDATA)>
An example of a notification message forced to the NCS:
<mos>
<mosID>prompt.station.com</mosID>
<ncsID>ncs.station.com</ncsID>
<roItemCue>
<mosID>videoserver.station.group.com</mosID>
<roID>96857485</roID>
<storyID>5983A501:0049B924:8390EF2B</storyID>
<itemID>234343234</itemID>
<roEventType>Prompter</roEventType>
<roEventTime>2000-03-20T10:45:00.00</roEventTime>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://ncsA4.com/mos/supported_schemas/NCSBBBBXML2.08</mosSchema>
<mosPayload>
<triggeredby>operator</triggeredby>
<operatorType>prompter</operatorType>
<netPropDelay>10</netPropDelay>
</mosPayload>
</mosExternalMetadata>
</roItemCue>
</mos>
An example of a
notification message sent to the parent MOS.
Note the counterintuitive assignment of the parent MOS name to the
<ncsID> field:
<mos>
<mosID>prompt.station.com</mosID>
<ncsID>videoserver.station.group.com</ncsID>
<roItemCue>
<mosID>videoserver.station.group.com</mosID>
<roID>96857485</roID>
<storyID>5983A501:0049B924:8390EF2B</storyID>
<itemID>234343234</itemID>
<roEventType>Prompter</roEventType>
<roEventTime>2000-03-20T10:45:00.00</roEventTime>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://ncsA4.com/mos/supported_schemas/NCSBBBBXML2.08</mosSchema>
<mosPayload>
<triggeredby>operator</triggeredby>
<operatorType>prompter</operatorType>
<netPropDelay>10</netPropDelay>
</mosPayload>
</mosExternalMetadata>
</roItemCue>
</mos>
Allow basic control of a media object server via simple commands such as READY, EXECUTE, PAUSE, STOP and SIGNAL
The roCtrl message allows control of a running order at three levels, the Running Order itself, Story, and Item. The commands READY, EXECUTE, PAUSE and STOP, as well as general indicator, SIGNAL, can be addressed at each level. In other words, a single command can begin EXECUTION of an entire Running Order, of a Story containing multiple Items, or of a single Item.
roAck
mos
mosID
ncsID
roCtrl
roID
storyID
itemID
command
<!ELEMENT roCtrl (roID, storyID, itemID, command,
mosExternalMetadata*)>
<!ELEMENT command (READY|EXECUTE|PAUSE|STOP|SIGNAL)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roCtrl>
<roID>3dedde9jd</roID>
<storyID>A3fds3d</storyID>
<itemID>30848</itemID>
<command>EXECUTE</command>
</roCtrl>
</mos>
This message enables sending the body of story from
the NCS to Media Object Server. Item references (storyItem)
are embedded within the story’s text.
These item references are not intended to be displayed on the prompter,
but instead can optionally be used to send a message (roItemCue)
to the media object server indicated in the embedded reference. Composed from information in the embedded
item reference, the roItemCue message could be
generated by the prompter as this hidden text (storyItem)
scrolls past the imaginary execution/read line of the prompter display.
The storyItem information can
also optionally allow the prompter vendor to display the length of the embedded
object and perhaps even a countdown.
Prompters, radio systems, external archive systems,
accounting systems, and potentially other systems and devices can make use of
this information.
roAck
mos
mosID
ncsID
roStorySend
roID
storyID
storySlug?
storyBody
storyPresenter*
storyPresenterRR*
p*
em*
tab*
pi*
pkg*
b*
I*
u*
storyItem*
itemID
itemSlug?
objID
mosID
mosAbstract?
itemChannel?
itemEdStart?
itemEdDur?
itemTrigger?
macroIn?
macroOut?
<!ELEMENT roStorySend (roID, storyID, storySlug?,
storyNum?, mosExternalMetadata* storyBody)>
<!ELEMENT storyBody (storyPresenter*,
storyPresenterRR*, p*, storyItem*)>
<!ELEMENT storyPresenter (#PCDATA)>
<!ELEMENT storyPresenterRR (#PCDATA)>
<!ELEMENT storyItem (itemID, itemSlug?, objID,
mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?, itemTrigger?, macroIn?,
macroOut?, mosExternalMetadata*)>
<!ELEMENT p (#PCDATA | em | tab | pi | pkg | b |
i | u)*>
<!ELEMENT pi (#PCDATA | b | i | u)*>
<!ELEMENT pkg (#PCDATA | b | i | u)*>
<!ELEMENT b (#PCDATA | i | u)*>
<!ELEMENT i (#PCDATA | b | u)*>
<!ELEMENT u (#PCDATA | b | i)*>
<mos>
<mosID>prompt.station.com</mosID>
<ncsID>ncs.station.com</ncsID>
<roStorySend>
<roID>96857485</roID>
<storyID>5983A501:0049B924:8390EF1F</storyID>
<storySlug>Show Open</storySlug>
<storyNum>C8</storyNum>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://NCSA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<changedBy>MPalmer</changedBy>
<length>463</length>
<show>
</mosPayload>
</mosExternalMetadata>
<storyBody>
<storyPresenter>Suzie</storyPresenter>
<storyPresenterRR>10</storyPresenterRR>
<p>
<pi> Smile </pi>
</p>
<p> Good Evening, I'm Suzie Humpries </p>
<storyPresenter>Chet </storyPresenter>
<storyPresenterRR>12</storyPresenterRR>
<p> - and I'm Chet Daniels, this is the
<p>First up today - a hotel fire downtown</p>
<item>
<itemID>1</itemID>
<itemSlug>Hotel Fire vo</itemSlug>
<objID>M000705</objID>
<mosID>testmos</mosID>
<itemEdStart>0</itemEdStart>
<itemEdDur>800</itemEdDur>
<macroIn>c01/l04/dve07</macroIn>
<macroOut>r00</macroOut>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<transitionMode>2</transitionMode>
<transitionPoint>463</transitionPoint>
<source>a</source>
<destination>b</destination>
</mosPayload>
</mosExternalMetadata>
</item>
<p>...as you can see, the flames were quite high. </p>
</storyBody>
</roStorySend>
</mos>
Message sent for the purpose
of verifying network and application continuity.
mos
mosID
ncsID
heartbeat
time
<!ELEMENT heartbeat
(time)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<heartbeat>
<time>1999-04-11T17:
</heartbeat>
</mos>
Method for an NCS or MOS to
determine more information about it’s counterpart.
mos
mosID
ncsID
reqMachInfo
<!ELEMENT reqMachInfo
EMPTY>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<reqMachInfo/>
</mos>
Method for an NCS or MOS to
determine more information about it’s counterpart.
None
mos
mosID
ncsID
listMachInfo
manufacturer
model
hwRev
swRev
DOM
SN
ID
time
opTime?
mosRev
<!ELEMENT listMachInfo
(manufacturer, model, hwRev, swRev, DOM, SN, ID, time, opTime?, mosRev,
mosExternalMetadata*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<listMachInfo>
<manufacturer>RadioVision, Ltd.</manufacturer>
<model>TCS6000</model>
<hwRev></hwRev>
<swRev>2.1.0.37</swRev>
<DOM></DOM>
<SN>927748927</SN>
<ID>airchache.newscenter.com</ID>
<time>1999-04-11T17:20:42</time>
<opTime>1999-03-01T23:55:10</opTime>
<mosRev>2.5</mosRev>
</listMachInfo>
</mos>
This data block can appear
in several messages as a mechanism for transporting additional metadata,
independent of schema or DTD.
The value of the
<scope> tag implies through what production processes this information
should travel.
A scope of “OBJECT implies
this information is generally descriptive of the object and appropriate for
queries.
A scope of “STORY” suggests
this information may determine how the Object is used in a Story. For instance, Intellectual Property
Management. This information should be
stored and used with the Story.
A scope of “PLAYLIST”
suggests this information is specific to describing how the Object is to be
published, rendered, or played to air and thus, should be included in the Play
List in addition to the Story.
This mechanism allows us to
roughly filter external metadata and selectively apply it to different
production processes and outputs.
Specifically, it is neither advisable nor appropriate to send large
amounts of inappropriate metadata to the Playlist in roCreate messages. In
addition to these blocks of data being potentially very large, the media Object
Server is, presumably, already aware of this data.
The value of the
<mosSchema> tag should be descriptive of the schema used within the
<mosPayload>. The value of
<mosSchema> is implied to be a pointer or URL to the actual schema
document.
The contents of
<mosPayload> must be well formed XML, regardless of the schema used.
<!ELEMENT
mosExternalMetadata (mosScope?, mosSchema, mosPayload>
(note: value of mosSchema
is recommended to be a URI – the right most element of which is considered
significant and uniquely identifying for the purposes of validation)
<mosExternalMetadata>
<mosScope>STORY</mosScope>
<mosSchema>http://ncsA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<ModTime>20010308142001</ModTime>
<mediaTime>0</mediaTime>
<TextTime>278</TextTime>
<ModBy>LJOHNSTON</ModBy>
<Approved>0</Approved>
<Creator>SHOLMES</Creator>
</mosPayload>
</mosExternalMetadata>
This data block appears in
the MOS Protocol as a subset of the roCreate commands, but may also stand alone
as recommended mechanism for transferring Item information from an NCS plug-in
to the NCS. It is implied that this
format will also be included in the body of the Story and thus will be output
in the roStorySend messages.
The metadata in the Item Reference is a description
of how to execute playback or instantiation of an object, pointed to by the
<objID>. The <mosID> is
required for forced playlist construction, maintenance of Item References
within stories and for association with MOS ActiveX components. The <mosAbstract> field provides a
displayable abstract of the Object/Item, more verbose than the
<itemSlug>. <mosAbstract>
may contain formatting.
It is recommended that
vendor or site specific tags be included in the <mosExternalMetadata>
structure, not in the body of the message.
<!ELEMENT item (itemID,
itemSlug?, objID, mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?,
itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>
<item>
<itemID>1</itemID>
<itemSlug>Man Bites Dog
vo</itemSlug>
<objID>34323</objID>
<mosID>ncs.com</mosID>
<mosAbstract>Man Bites Dog vo trt
:48</mosAbstract>
<itemChannel>1</itemChannel>
<itemEdStart>0</itemEdStart>
<itemEdDur>1440</itemEdDur>
<itemTrigger>manual</itemTrigger>
<macroIn>2e9de</macroIn>
<macroOut>2399a</macroOut>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://mosA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
<mosPayload>
<source>production</source>
<machine>A5</machine>
</mosPayload>
<mosExternalMetadata>
<item>
Many of the terminal
elements are constrained in size and/or content as listed below. Character
entities count as one character in size constraints. Numeric values may be
provided in decimal or hexadecimal (when preceded by “0x”, or
"x"). Text constants are case
sensitive.
b
Bold
face type: Specifies that text between tags is in boldface type.
Changed Time/Date: Time the
object was last changed in the MOS. Format is YYYY-MM-DD'T'hh:mm:ss[,ddd]['Z'], e.g. 1999-04-11T14:22:07,125Z or
1999-04-11T14:22:07,125-
Last Changed by: Name of the
person or process that last changed the object in the MOS. This can be stored
in a language other than English.
command
roItemCtrl command: The
commands READY, EXECUTE, PAUSE and STOP, as well as general indicator, SIGNAL,
can be addressed at each MOS Structure level. In other words, a single
command can begin EXECUTION of an entire Running Order, of a Story containing
multiple Items, or of a single Item.
Creation Time/Date: Time the
object was created in the MOS. Format is YYYY-MM-DD'T'hh:mm:ss[,ddd]['Z'], e.g. 1999-04-11T14:22:07,125Z or 1999-04-11T14:22:07,125-
Created by: Name of the person or process that created the object in the MOS. This can be stored in a language other than English. 128 chars max.
Object Description: Text description of the MOS object. No maximum Length is defined. This can be stored in a language other than English.
Date of Manufacture.
Emphasized Text: markup within description and p to emphasize text.
HW Revision: 128 chars max.
I
Italics: Specifies that text between tags is in Italics.
Identification of a Machine: text. 128 chars max.
Item: Container for item information within a Running Order message.
Item Channel: Channel requested by the NCS for MOS to playback a running order item. 128 chars max.
Item Editorial Duration: in number of samples 0XFFFFFFFF max.
Editorial Start: in number of samples 0XFFFFFFFF max.
Item ID: Defined by NCS, UID not required. 128 chars max.
Item Slug: Defined by NCS. 128 chars max
Item Air Trigger: “MANUAL”, “TIMED” or “CHAINED”.
CHAINED (sign +/-) (value in # of samples)
CHAINED -10 would start the specified clip 10 samples before the proceeding clip ended. CHAINED 10 would start the specified clip 10 samples after the preceding clip ended, thus making a pause of 10 samples between the clips. There is a space character between the word CHAINED and the value.
Macro Transition In: Defined by MOS. 128 chars max.
Macro Transition Out: Defined by MOS. 128 chars max.
Manufacturer: Text description. 128 chars max.
Model: Text description. 128 chars max.
Modified by: Name of the
person or process that last modified the object in the MOS. This can be stored
in a language other than English. 128 chars max.
Abstract of the Object
intended for display by the NCS. This
field may contain HTML and DHTML markup.
The specific contents are limited by the NCS vendor’s
implementation. Length is unlimited but
reasonable use is suggested.
MOS ID: Character name for
the MOS unique within a particular installation.
This field is intended to imply the name of a destination, group or folder for the Object pointer to be stored in the NCS. 128 chars max.
MOS Revision: Text
description. 128 chars max.
This field implies the extent to which the mosExternalMetadata block will move through the NCS workflow. Accepted values are “OBJECT” “STORY” and “PLAYLIST”
NCS ID: Character name for the NCS unique within a particular installation. 128 chars max.
Air Status: “READY” or “NOT READY”.
Object Duration: The number of samples contained in the object. For Still Stores this would be 1. 0XFFFFFFFF MAX
Object UID: Unique ID generated by the MOS and assigned to this object. 128 chars max.
Object Revision Number: 999 max.
Object Slug: Textual object description. 128 chars max.
Object Time Base: Describes the sampling rate of the object in samples per second. For still stores this is 0. For PAL Video this would be 50. For NTSC it would be 60. For audio it would reflect the audio sampling rate. Object Time Base is used by the NCS to derive duration and other timing information. 0XFFFFFFFF MAX
Object Type: Choices are “STILL”, “AUDIO”, “VIDEO”.
Operational Time: date and
time of last machine start. Format is YYYY-MM-DD'T'hh:mm:ss[,ddd]['Z'], e.g. 1999-04-11T14:22:07,125Z or
1999-04-11T14:22:07,125-
p
Paragraph: Standard html delimitation for a new paragraph.
Item Delay: Requested delay between items in ms 0XFFFFFFFF MAX.
Presenter instructions: Instructions to the anchor or presenter that are not to be read such as "Turn to 2-shot."
Package: Specifies that text is verbatim package copy as opposed to copy to be read by presenter.
Air Ready Flag: “READY” or “NOT READY”.
Running Order Channel: default channel requested by the NCS for MOS to playback a running order. 128 chars max.
Running Order Control Command: READY, EXECUTE, PAUSE and STOP, as well as general indicator, SIGNAL, can be addressed at each level. In other words, a single command can begin EXECUTION of an entire Running Order, of a Story containing multiple Items, or of a single Item.
Running Order Control
Time: roCtrlTime is an optional field which provides a mechanism to time
stamp the time of message transmission, or optionally, to provide a time in the
immediate future at which the MOS should execute the command. Format is YYYY-MM-DD'T'hh:mm:ss[,ddd]['Z'], e.g. 1999-04-11T14:22:07,125Z or
1999-04-11T14:22:07,125-
Running Order Editorial
Duration: duration of entire running order. Format in hh:mm:ss, e.g.
Running Order Editorial
Start: date and time requested by NCS for MOS to start playback of a running
order. Format is YYYY-MM-DD'T'hh:mm:ss[,ddd]['Z'],
e.g. 1999-04-11T14:22:07,125Z or 1999-04-11T14:22:07,125-
Running Order Event Time: Time of the time cue sent to the parent MOS by the NCS for a specific item event.
Running Order Event Type: The type of event that is being queued in the Running order.
Running Order UID: Unique Identifier defined by NCS. 128 chars max.
Running Order Slug: Textual Running Order description. 128 chars max.
Running Order Status: Options are: "OK" or error description. 128 chars max.
Running Order Air Trigger: “MANUAL”, “TIMED” or “CHAINED”.
CHAINED (sign +/-) (value in # of samples)
CHAINED -10 would start the specified clip 10 samples before the proceeding clip ended. CHAINED 10 would start the specified clip 10 samples after the preceding clip ended, thus making a pause of 10 samples between the clips. There is a space character between the word CHAINED and the value.slug Textual Object ID: This is the text slug of the object and is stored in the native language. This can be stored in a language other than English. 128 chars max.
Serial Number: text serial number. 128 chars max.
Status: Options are “NEW” “UPDATED” “MOVED” “BUSY “ “DELETED”, "NCS CTRL", "MANUAL CTRL", "READY", "NOT READY", "PLAY," "STOP".
Status Description: textual description of status. 128 chars max.
Story: Container for story information in a Running Order message.
Story Body: The actual text of the story within a running order.
Story UID: Defined by the NCS. 128 chars max.
Story Item: An item imbedded into a story that can be triggered when that point in the story is reached in the teleprompter.
Story Number: The name or number of the Story as used in the NCS. This is an optional field originally intended for use by prompters. 128 chars max.
Story Presenter: The anchor or presenter of a story within an running order.
Story Presenter Read Rate: The read rate of the anchor or presenter of a story within a running order.
Story Slug: Textual Story description. 128 chars max.
Software Revision: (MOS) Text description. 128 chars max.
Tab: tabulation markup within description and p.
Time: Time object changed
status. Format is YYYY-MM-DD'T'hh:mm:ss[,ddd]['Z'],
e.g. 1999-04-11T14:22:07,125Z or 1999-04-11T14:22:07,125-
u
Underline: Specifies that text between tags is to be underlined.
Allows for identification of the parent Media Object Server when the play list is forcefully constructed on a machine other than an object’s parent Media Object Server, i.e. when a play list is constructed in a MOS Prompter.
The format of the message remains the same. The only change is the optional addition of the existing mosID tag. The value of this tag, if appropriately used, is set to the ID of the referenced object’s parent Media Object Serve. This change is reflected throughout all MOS messages which include the <item> structure.
item
itemID
itemSlug
mosID
objID
itemChannel
itemEdStart
itemEdDur
itemTrigger
macroIn
macroOut
<!--
MOS.DTD version 2.601
<!--
edited with XML Spy v4.0 NT beta 2 build Jul 26 2001 (http://www.xmlspy.com) by
Mike Palmer (Associated Press) -->
<!--Thanks
to Jiri Basek Aveco s.r.o (Jiri.Basek@aveco.com) and the Octopus Team for the
following list of modifications due to original DTD bugs :
1: element
"roStorySend" : comma added between "mosExternalMetadata*"
and "storyBody"
2: element
"roStorySend" old version : deactivated
3: element
"item" : ending bracket added after "mosExternalMetadata*"
4: element
"command" : "READY", "EXECUTE",
"PAUSE", "STOP", "SIGNAL" are not elements but
predefined strings
5: element
"mosObj" : "externalData" changed to
"mosExternalData"
6: ATTLIST metadata :
deactivated. ? should it be changed to ATTLIST mosExternalMetadata ?
8: element
"mosScope" : "object, "story", "playlist"
are not elements but predefined strings
A9: element "mos" : "reqMachineInfo"
changed to "reqMachInfo"
A10: element
"storyNum" defined
Additional changes have been
made to the formatting and sequence of the elements in order to better match
the order of structures presented in the MOS Protocol document.
-->
<!--
MOS Message - One message type per message -->
<!ELEMENT mos (mosID, ncsID,
(mosAck | mosObj | mosReqObj | mosReqAll | mosListAll | mosObjCreate |
mosItemReplace | roAck | roCreate | roReplace | roMetadataReplace | roDelete |
roReq | roList | roReqAll | roListAll | roStat | roReadyToAir | roStoryAppend |
roStoryInsert | roStoryReplace | roStoryMove | roStorySwap | roStoryDelete |
roItemStat | roItemCue | roCtrl | roStorySend | heartbeat | reqMachInfo |
listMachInfo))>
<!ELEMENT mosAck (objID,
objRev, status, statusDescription)>
<!ELEMENT mosObj (objID, objSlug,
mosAbstract, objGroup?, objType, objTB, objRev, objDur, status, objAir,
createdBy, created, changedBy, changed, description, mosExternalMetadata*)>
<!ELEMENT mosReqObj
(objID)>
<!ELEMENT mosReqAll
(pause)>
<!ELEMENT mosListAll
((objID, objSlug, mosAbstract?, objGroup?, objType, objTB, objRev, objDur,
status, objAir, createdBy, created, changedBy, changed, description,
mosExternalMetadata*)*)>
<!ELEMENT mosObjCreate
(objSlug, objGroup?, objType, objTB, objDur?, time?, createdBy?, description?,
mosExternalMetadata*)>
<!ELEMENT mosItemReplace
(roID, storyID, item)>
<!ELEMENT roAck (roID,
roStatus, (storyID, itemID, objID, status)*)>
<!ELEMENT roCreate (roID,
roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroIn?, macroOut?,
mosExternalMetadata*, story*)>
<!ELEMENT roReplace (roID,
roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroIn?, macroOut?,
mosExternalMetadata*, story*)>
<!ELEMENT roMetadataReplace
(roID, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?,
mosExternalMetadata?)>
<!ELEMENT roDelete
(roID)>
<!ELEMENT roReq (roID)>
<!ELEMENT roList (roID,
roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroIn?, macroOut?,
mosExternalMetadata*, story*)>
<!ELEMENT roListAll ((roID,
roSlug?, roChannel?, roEdStart?, roEdDur?, roTrigger?,
mosExternalMetadata*)*)>
<!ELEMENT roStat (roID,
status, time)>