MOS Protocol version 2.8
Document Revision 5.10
Revision Date:
Copyright 2000, 2001, 2002,
2003, 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 five 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 discussed during the MOS meetings at NAB 2003 and
IBC 2002 and is referred to as MOS v2.8.
This is the final draft. Changes
are summarized here.
The document contains
bookmarks and hyperlinks. The Table of
Contents and other areas contain underlined phrases. Depending on the viewer application used,
clicking or double clicking on underlined links will take the viewer to the
relevant portion of the document.
Please make special note of
the Profiles section which provides context for the use of command messages
which are later defined in detail.
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
2. MOS
Profiles
2.1.
Profile 0 – Basic Communication
2.2. Profile 1 - Basic
Object Based Workflow
2.3. Profile 2 – Basic Running Order / Content List Workflow
2.4. Profile 3 – Advanced Object Based Workflow
2.5. Profile 4 – Advanced RO/Content List Workflow
2.7. Profile 6 – MOS Redirection
3.
Media Object
Server Protocol Message Definition
“mos”
(Media Object Server) family of messages
3.1.
Basic Object Communication
3.1.1. mosAck - Acknowledge MOS Object Description
3.1.2. mosObj - MOS Object Description
3.1.3. mosReqObj - Request Object Description
3.2.
Object Resynchronization / Rediscovery
3.2.1. mosReqAll - Request All Object Data from MOS
3.2.2. mosListAll - Listing of All Object Data from MOS
3.3.
Object and Item Management
3.3.1. mosObjCreate – Mos Object Create
3.3.2. mosItemReplace – Replace an Item Reference in an NCS Story
with updated Item sent from the MOS
“ro” (Running Order) family of messages
3.4.
ro
Playlist Construction
3.4.1. roAck
- Acknowledge Running Order
3.4.2. roCreate – Create Running Order
3.4.3. roReplace - Replace Running Order
3.4.4. roMetadataReplace – Replace the metadata associated with a
RO Playlist
3.4.5. roDelete - Delete Running Order
3.5.
ro Synchronization, Discovery & Status
3.5.1. roReq
- Request Running Order
3.5.2. roList - List Running Order
3.5.3. roReqAll - Request All Running Order Descriptions
3.5.4. roListAll - List All Running Order Descriptions
3.5.5. roStat - Status of a MOS Running Order
3.5.6. roReadyToAir - Identify a Running Order as Ready to Air
3.6.
ro Story and Item Sequence Modification
NOTE: The following messages are included only for backwards
compatibility with MOS v2.6 and have been replaced by 3.6.12 roElementAction in
MOS version 2.8. These messages will be
dropped from future versions of the Protocol.
3.6.1. roStoryAppend -
Append Stories to Running Order
3.6.2. roStoryInsert - Insert Stories in Running Order
3.6.3. roStoryReplace - Replace Story with Another in a Running
Order
3.6.4. roStoryMove – Move a Story to a specific location in a
Running Order
3.6.5. roStorySwap - Swap Positions of Stories in Running Order
3.6.6. roStoryDelete - Delete Stories from Running Order
3.6.7. roStoryMoveMultiple
– Move one or more stories to a new position in the playlist
3.6.8. roItemInsert
– Insert Items in Story
3.6.9. roItemReplace
– Replace an Item with one or more Items in a Story
3.6.10.roItemMoveMultiple
– Move one or more Items to a specified position within a Story
3.6.11.roItemDelete – Delete Items in Story
3.6.12.roElementAction – Performs specific Action on a Running Order
3.7.
ro Control and Status feedback
3.7.1. roItemStat - Status of a Single Item in a MOS Running Order
3.7.2. roItemCue – Notification of an Item Event
3.7.3. roCtrl – Running Order Control
3.8.
Metadata Export
3.8.1. roStorySend – Sends story information, including body, from
Running Order
4.
Other messages and data structures
4.1.
Other messages and data structures
4.1.1. heartbeat - Connection Confidence Indicator
4.1.2. reqMachInfo - Request Machine Information
4.1.3. listMachInfo - Machine Description List
4.1.4. mosExternalMetadata – Method for including and transporting
Metadata defined external to MOS
4.1.5.
mosItemReference – Metadata block transferred by ActiveX Controls
5.
ActiveX Control Specification
5.1. Methods,
Events & Data Types
5.2. Behavior
5.3. ActiveX
Communication Messages
5.3.1. ncsAck
5.3.2. ncsReqAppInfo
5.3.3. ncsAppInfo
5.3.4. ncsReqAppMode
5.3.5. ncsStoryRequest
5.3.6. ncsItemRequest
5.3.7. roStorySend
5.3.8. ncsItem
5.3.9. mosItemReplace
5.3.10.ActiveX
Specific Fields
7.1. Changes from MOS version 2.6 to 2.8
7.2. Changes from MOS version 2.5 to
2.6 WD-2001-06-06
7.3. Changes from MOS version 2.0 to 2.5 WD-2000-08-01
7.4. Changes for MOS 2.0 WD-1999-05-12
7.5. Changes from MOS version 1.52 to 2.0 WD-1999-03-17
8.
MOS 2.8 DTD
9.2. XML FAQ
9.3. Recommended Reading
9.4. XML Web Sites
This document reflects changes
to the MOS protocol discussed during the MOS Working Group meetings at NAB 2003
and IBC 2002.
The following new section has been added:
This document now contains
standard descriptions of the minimum functional implementation of the MOS
Protocol. These descriptions are called “Profiles.” Seven Profiles are defined:
Profile 0 – Basic Communications
Profile 1 – Basic
Object Based Workflow
Profile 2 – Basic
Running Order/Content List Workflow
Profile 3 – Advanced Object Based Workflow
Profile 4 –
Advanced RO/Content List Workflow
Vendors wishing to claim MOS
compatibility must fully support, at a minimum, Profile 0 and at least one
other Profile.
The following command messages have been added:
1) A single preferred command message, roElementAction,
is now available for manipulation of story and item sequences. This command message can effectively replace
all existing use of roStory and roItem commands.
2) Five additional commands were added as alternates to roElementAction
to ease transition and provide backward compatibility. These commands are allowed in MOS v2.8 but
will be phased out at some point in the future
a. roItemInsert
d. roItemDelete
e. roStoryMoveMultiple – allows multiple stories to be moved in a single command.
Item
level commands are analogous to the story-level commands with similar names.
The
item-level Append and Swap commands can be performed by using roItemInsert and
roItemMoveMultiple, respectively, and provide no extra performance gain. Hence
roItemAppend and roItemSwap are not needed.
Note:
these commands are used to manage items within a single story; these cannot be
used to copy or move items between stories.
The following command messages have been changed:
1) mosReqAll
- command has reversed the meaning of the <pause> tag, so that a pause
value greater than zero means that individual mosObj messages are sent by the
MOS. A pause value of zero means that a single mosListAll message is sent by
the MOS.
2) mosListAll
- command now contains <mosObj> tags, instead of all the object fields
appearing as direct tags inside <mosListAll>.
3) roListAll -
command now contains <ro> tags, instead of all the ro fields appearing as
direct tags inside roListAll.
4) listMachInfo
- command contains additional tags to define the MOS profiles supported by the
MOS, and optional ActiveX configuration information.
A
reminder: MOS Protocol v2.8 compatible
equipment will 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.
The purpose of these
profiles is to define basic levels of functionality enabled by the MOS Protocol
v2.8
There are seven Profiles
defined:
Profile 0 – Basic Communications
Profile 1 – Basic
Object Based Workflow
Profile 2 – Basic
Running Order/Content List Workflow
Profile 3 – Advanced Object Based Workflow
Profile 4 –
Advanced RO/Content List Workflow
Vendors wishing to claim MOS
compatibility must fully support, at a minimum, Profile 0 and at least one
other Profile.
When claiming MOS
compatibility or using the MOS Logo, vendors must clearly state which profiles
of one through six they support. For
instance “MOS Compatible – Profiles 1,2,3,4,6”
In order to claim support
for a specific profile the vendor must fully implement all messages in the
manner specified by the profile. In
addition, the vendor must fully implement and support the workflow described by
the profile.
If a vendor does not state
profile support, or does not support all messages or functionality described by
a profile, or does not support at least two profiles, one of them being Profile
0, they cannot claim MOS compatibility.
Optional functionality is
clearly identified with the word “Optional” or with the phrase “Recommended
Work Practice” in bold, followed with optional information in italics.
All
other functionality is required.
The purpose of MOS Profiles
is to describe minimum levels of functionality and support. Vendors are encouraged to derive more complex
levels of functionality from any Profile so long as support is maintained for
the basic profile and MOS syntax and transport rules are not compromised.
This
Profile enables basic MOS XML message exchange and discovery between
applications and machines using TCP/IP sockets.
Messages
required for support of Profile 0:
General
Work Flow for Profile 0
·
Establish
communication to another MOS device
·
Send a <heartbeat>
message to another application and receive a <heartbeat>
message in response
·
Send a <reqMachInfo>
message to another application and receive a <listMachInfo>
message in response.
Implementation
Notes
This
Profile encompasses the most basic requirements and functions to support MOS
Protocol message transfer. The three
basic messages included in this profile, <heartbeat>,
<reqMachInfo>
and <listMachInfo> can be exchanged between
any MOS v2.8 complaint devices
Profile 0
required MOS message support
The
heartbeat message is designed to allow one application to confirm to another
that it is still alive and communications between the two machines is viable.
An
application will respond to a heartbeat message with another heartbeat
message. However, care should be taken
in implementation of this message to avoid an endless looping condition on
response.
Recommended Work Practice: It is useful for a MOS Protocol enabled
application to be aware of the three levels of connectivity which are required
for MOS message exchange:
1) Network
Connectivity: You must be able to “
2) Socket
Connectivity: You must be able to
establish a socket connection with the remote application
3) Application
Response: You must be able to receive an
ACK message in response to the message you have transmitted.
If you can send a <heartbeat>
message and receive a <heartbeat> message in response you have verified
the continuity at all three levels.
Each
heartbeat message contains a time stamp. This gives each application the opportunity to
synchronize time of day, with a relatively low degree of precision, and to be
aware of the other machine’s local offset from GMT.
This
message is a request for the target machine to respond with a listMachInfo
message.
This
message allows the machine to identify itself with manufacturer ID, model,
hardware and software revisions, MOS version supported, etc.
This message identifies which MOS Profiles it
supports.
The
machine may also optionally identify information necessary for remote devices
to install and configure an associated ActiveX control.
Recommended Work Practice: Applications may optionally use the
information contained in this message to provide automatic or semi-automatic
configuration.
General
Explanation of MOS message format and construction
Identification
In
practice the MOS and NCS character names are predefined in each system and IP
addresses associated with each name.
Encoding
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, also known as “big endian.”
MOS Message
Format
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.
Extensible
Markup Language (XML)
The
syntax of MOS v2.8 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.
Unknown
Tags
Should
a MOS or NCS encounter an unknown message or data tag the device will ignore
the tag and the data and continue to process the message. Unknown data tags
will not generate an application error. The application has the option of
indicating a warning.
Data Format
for Object <description> field
The
value of 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.
Languages
Data
tags and constants are formatted as English.
The
only Data Fields that can contain other languages are:
And the data structure
Numbers
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”.
Running
Orders
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 will 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.
Definition
of Object Sample Rate
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.
Message
Transport
MOS
uses two ports bi-directionally.
Applications will simultaneously listen for messages on both ports – see
Message Exchange below.
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
Message
Exchange
To
send a MOS message from MOS to NCS or vice versa:
1. An application will open a socket on the appropriate
port to the receiving device if a socket has not already been established.
2. The application will then send the message.
3. The application will then hold the socket open and
wait for a mosAck message to be returned on the same socket before either
dropping the socket or transmitting the next message.
4. Optionally, either device may send <heartbeat>
messages at regular intervals to the other machine and look for a response.
Recommended Work Practice: It is not
necessary to disconnect the socket once the ACK has been received. It may be more efficient and require less
overhead to simply leave the socket open until the next message is transmitted,
even if this is not immediate. If the
socket is dropped the application should re-establish the socket before the
next message is transmitted.
Important Application Note: When a socket is closed, either locally or
remotely, care should be taken to ensure the socket is completely
disconnected. This is a 4 step process
involving communication between both machines.
Socket tear down is normally taken care of at a level below application
development. However, if problems are
experienced establishing a socket between machines after at least one socket
connection has been established and then dropped, this may be a sign the first
socket was not properly closed. Check
the status of all network connections on both machines. Indications of “fn_Wait2” on ports used for MOS
communications are a sign of a problem.
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 will 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) will be capable of establishing
and maintaining connections to multiple systems of the opposite type. e.g. An NCS will be capable of connecting to
multiple Media Object Servers. Media
Object Servers will also be capable of connecting to multiple NCSs.
Message
Acknowledgement
When
a message is sent by a device to a target device, that device will not send
another message to the target device on the same port until it receives an
acknowledgement (“ACK”) or error (“NACK”) from the target device.
MOS
enabled equipment and applications will retry when a timeout occurs. This
applies to all messages on the same port.
Message
acknowledgment on one port is independent of the flow of messages on the other.
If
a message is not acknowledged, it and all subsequent waiting messages will be
buffered.
Recommended Work Practice: It is recommended that these messages
be buffered in such a way that machine or application restart or reset will not
destroy these buffered messages.
This
profile allows a Media Object Server to push messages to other machines which
describe objects contained on the Media Object Server.
In addition to support for Profile 0,
these additional messages are required for support of Profile 1:
General Work
Flow for Profile 1
·
Media Object
Servers push <mosObj> messages describing media to
the NCS. This description includes a
pointer to the media object as well as descriptive metadata.
·
The NCS exposes
<mosObj>
information to users through lists, searches or other mechanisms in such a way
that pointers representing the media objects are able to be moved or copied
into text as Item References. Item
References are derived from <mosObj> information.
·
Optionally, an
ActiveX control, provided by the Media Server Vendor, can be instantiated
within the NCS UI. This ActiveX control
has the ability to form an Item Reference and pass it to the NCS for
integration as an Item Reference into a Story. (See the MOS v2.8 ActiveX
Specification)
·
Optionally,
activating a pointer within the NCS (for example: in a list, embedded in a
Story, etc.) instantiates an ActiveX control, provided by the Media Server
Vendor, within the NCS UI. This ActiveX
control provides, at a minimum, the ability to browse or display a proxy
version of an object and also facilitates the integration of that object into
an NCS Story as an Item Reference. (See the MOS v2.8 ActiveX Specification)
·
The only MOS
External Metadata (MEM) blocks that can be carried from the mosObj to the Item
Reference are those with a <mosScope> of either “STORY” or
“PLAYLIST”.
Implementation
Notes:
<mosObj>
messages are sent from the Media Object Server to other applications to make
them aware of objects stored on the Media Object Server.
Recommended Work Practice: Other machines can populate their own
database structures from the data contained within the <mosObj> messages
they receive. It is possible then for
these other applications to maintain a synchronized metadatabase describing
objects contained within the Media Object Server.
Other NCS applications have the
opportunity to store and update a local metadatabase with this information. These applications can then perform searches
on the local metadatabase and retrieve pointers to objects stored on the Media
Object Server with matching records.
These objects can then be referred to by unique <objID> without
the immediate need to copy or move the essence of the object from the Media
Object Server to the other applications.
Object
Creation and Notification
When
an object is created on a Media Object Server a <mosObj> message is
pushed from the Media Object Server to a target application configured to
receive this information. The initial
<mosObj> message will have a <status> value of
“NEW”.
As
metadata associated with an object stored on the Media Object Server changes,
the Media Object Server needs to update the metadata already sent to other
applications where it has been stored locally.
Subsequent <mosObj> messages with updated metadata are sent from
the Media Object Server with a <status> value of “UPDATED”.
When
the object is deleted from the Media Object Server or when the Media Object
Server determines the object no longer has relevance to other devices, the
Media Object Server sends a final <mosObj> message with a status of
“DELETED”.
Recommended Work Practice: In many
implementations both the target NCS and MOS sender need to have prior knowledge
of each other stored in local configurations before messages can be
meaningfully exchanged.
It is possible, and sometimes desirable, to
limit the number and type of objects which are pushed from the Media Object
Server to other applications so that other applications are aware of only a
subset of the entire population of objects stored on the Media Object Server.
Care should
be taken to avoid unnecessary <mosObj> updates.
For instance, if an object is being
ingested or recorded by a media server the duration of that object could be
expected to be constantly changing as the recording continues. It is not reasonable to assume that other
systems will want to receive updates every 1/10th of a second, every
second, or even every few seconds when the recording is in progress. Such frequent updates, in most systems, would
not be useful and would only serve to consume network, disk I/O and CPU bandwidth.
<mosObj> updates
will be sent only at a frequency which is useful. There may be exceptions to this general rule
and thus the protocol does not specifically define a maximum or minimum update
frequency.
Object IDs Must
Be Unique
<objID>’s
are absolutely unique within the scope of the Media Object Server and are used
to unambiguously reference media stored on a specific server. The combination of <mosID>
and <objID>
will serve as a unique reference to an object on a specific server with an
enterprise or multi-Media Object Server environment. The <objID> associated
with an object will never change. Even if
an object is moved from online, to nearline, to offline storage it will still
use the same <objID> for unambiguous reference.
Applications
should never, ever allow a user to enter or type an <objID>. Users should be presented indirect methods,
such as lists, drop downs, drag and drop operations, etc. to choose and
manipulate objects and object pointers.
Object
Slugs are intended for display and use by Users
<objSlug>’s
are the non-unique, human readable analog to the unique, machine assigned <objID>.
In short, <objSlug>’s are
for humans. <objID>’s are for
machines.
<objSlug>’s can optionally be assigned
or changed as necessary by users. <objID>’s can never be assigned or
modified by users directly.
Recommended Work Practice: Display the <objSlug>
to users and hide the <objID>.
The
<objSlug>
field will contain the primary one line reference or name for an object exposed
to users. This field is limited to 128
characters.
Abstracts
and Descriptions may contain more information
The
<mosAbstract>
can contain a somewhat longer, but still brief, description of summary of the
object which may applications may choose to alternately display.
The
<description>
will contain a verbose description of the object with information necessary to
find the object via search functions.
MEM blocks
carry Metadata Payloads
The
<mosExternalMetadata> block (aka MOS
MEM) is intended to be the mechanisms through which full and verbose
descriptions of objects can be carried, which include the use of non-MOS
schemas and tags for fielded data.
The
MEM is the mechanism by which MOS supports Metadata Schema Standards such as
NewsML, SMEF, SMPTE, MPEG7 and user specific schemas. MEM data blocks are not directly manipulated
by the MOS Protocol and can be considered an information Payload which is
carried between systems by the MOS Protocol.
Because
MEM blocks can potentially carry large volumes of information, and because this
information may not be relevant to all aspects of MOS applications, it makes
sense to specifically state the scope of processes to which this information
may be relevant. Thus, MEM blocks need
only be carried as far into the process as is needed, and not unnecessarily
consume network bandwidth, CPU or storage.
The
<mosScope>
tag describes to what extent within an NCS type workflow the MEM block will be
carried.
A
value of “OBJECT” implies that the MEM payload will be used for list and search
purposes, but will not necessarily be carried into Stories or Play
Lists/Content Lists.
A
value of “STORY” implies the MEM payload will be used like the “OBJECT” case,
but will be further carried into MOS Item References embedded in Stories. However, MEM Payloads with a <mosScope>
of “STORY” are not carried into Play Lists/Content Lists.
A
value of “PLAYLIST” implies the MEM payload will be used and included in all
aspects of the production workflow, including embedding this information in the
Item Reference in the Story and in Item References contained in the PlayList.
Exchanging
Messages between MOS devices
To
send a <mosObj>
message from MOS to NCS:
1) The MOS device will open a socket on the lower port
to the NCS if it is not already open
2) The MOS device will send the mosObj message
3) The MOS device will hold the socket open
4) The MOS device will wait for a mosAck message to be
returned on the same socket before either dropping the socket or transmitting
the next message.
5) The MOS device can optionally send <heartbeat>
messages at regular intervals to the remote machine and look for a response.
Recommended Work Practice: It is not
necessary to disconnect the socket once the ACK has been received. It may be more efficient and require less
overhead to simply leave the socket open until the next message is transmitted,
even if this is not immediate. If the
socket is dropped the application should re-establish the socket before the
next message is transmitted.
Important Application Note: When a socket
is closed, either locally or remotely, care should be taken to ensure the
socket is completely disconnected. This
is a 4 step process involving communication between both machines. It is normally taken care of at a level below
application development. However, if
problems are experienced establishing a socket between machines after at least
one socket connection has been established and then dropped, this may be a sign
the first socket was not properly closed.
Check the status of all network connections on both machines. Indications
of “FIN_WAIT_2” or “CLOSE_WAIT” on ports
used for MOS communications are a sign of a problem.
MOS message
flow is strictly sequential
The
Media Object Server will not send the next lower port message until the last
message is acknowledged.
Flow
of message traffic on the upper port is unrelated to acknowledgements on the
lower port and vice versa.
If
the value of <status> in the mosAck message is “NACK”
then a more verbose error message is contained in <statusDescription>.
Data
ownership and Synchronization
Metadata
sent from the Media Object Server, including descriptions, pointers and MEM
blocks, may not ever be changed by the NCS device. No mechanisms exist to reflect such changes
back into the Media Object Server. Such
an operation would be conceptually incompatible with the MOS Protocol.
If
application developers wish to enable users at an NCS workstation to change
this data they should provide such functionality in an ActiveX control,
provided by the Media Object Server vendor, which can be instantiated within
the NCS UI and provide the desired functionality. This is permitted since it is the vendor
ActiveX control and not the NCS which is modifying the object information.
There
may be times when an application may wish for the Media Object Server to send a
full list of objects and descriptions.
This may happen on initial installation and integration of systems, or
at any other time when an NCS device wishes to synchronize its <mosObj>
metadatabase from the Media Object Server.
The <mosReqAll> and <mosListAll>
messages are designed to facilitate this.
There are methods enabled by these messages.
Method
1:
1. NCS sends a <mosReqAll> with
a <pause> value of “0”
2. MOS replies with a <mosAck>, and then
sends a series of <mosObj> messages encapsulated within a
single <mosListAll> tag.
This
enables the receiving NCS device to detect the start and end of the
synchronization sequence. It can also
potentially consume large amounts of network, CPU and disk I/O bandwidth.
Method
2:
1. NCS sends a <mosReqAll> with
a <pause>
value greater than “0”
2. MOS replies with a <mosAck>, and then
sends a series of individual <mosObj> messages.
The
value of <pause>
indicates the number of seconds the MOS will
pause in between <mosObj> messages intended for
synchronization.
Other
<mosObj>
messages can be transmitted by the MOS between and concurrent with <mosObj>
messages created as a result of the <mosReqAll>
request. For instance, new objects,
updates and deletions caused by work flow interaction.
This
second method has the advantage of less impact on MOS and NCS resource
bandwidth, but there is no differentiation of <mosObj> messages
intended for synchronization as opposed to those generated as a result of
normal work flow.
The
<mosReqObj>
message is rarely used in actual operation but must be supported so that it can
be used as a diagnostic tool.
This
Profile allows an NCS application to build dynamic Running Order/Content List
sequences of Item References within a Media Object Server.
In addition to support for Profiles 0 and 1, these
additional messages are required for support of Profile 2:
“roConstruction” family of messages
Included
only for backwards compatibility:
General
Work Flow for Profile 2
·
Within the NCS
Stories containing Item References can be placed into Running Orders (RO’s or
also referred to as Content Lists).
·
The NCS then
examines all Stories in a RO/Content List, extracts the Item References and
uses these to build Playlists or Content Sequences within the parent Media
Server machine.
·
Playlists built
in the Media Object Server by the NCS are filtered so they contain only Items
which are stored on the target device.
For
instance, if a Running Order/Content List contains one story with embedded Item
References from three different Media Object Servers, this single story would
result in the creation of three Playlist/ContentLists – one in each of the
Media Object Servers represented in the Story’s Item References. Each Playlist/Content List would contain only
one Item – the Item which references an Object stored on the local
machine.
In
practice, this means that a Story which contains Item References for a Video
Object, a CG Object and a Still Store Object will create three different
playlists – one in the Video Server, one in the CG Server and one in the Still
Store Server. Each playlist would
contain a single Item.
Exceptions
to this rule are machines which conform to Profiles 4 and 5.
·
Only MOS
External Metadata (MEM) blocks included in Item References with a <mosScope>
of “PLAYLIST” are included in these construction messages. MEM blocks with a <mosScope>
of “STORY” are stripped and not sent.
·
The NCS thus provides
to the Parent Media Object Server a list pointing to Objects in the same order
they are used in the Play List/Content List.
·
The Media Object
Server must always keep track of the list sequence as sent from the NCS without
making changes to it. However, the MOS
Device may choose to execute this list out of sequence without changing the
list itself.
·
As the content
list is changed in the NCS, messages are dynamically sent from the NCS to the
Media Object Server to insert, replace, delete, or otherwise resequence the
contextual list of objects. This is a dynamic process and is not static.
·
As objects
identified by Item References are rendered or played to air, the status of
these objects is sent from the MOS to the NCS via the <roItemStat>
message.
·
Finally, when
the production of content within the NCS is complete, the NCS issues a final
command to delete the RO/Content List.
Important
Implementation Notes:
1) Both NCS and MOS device operation are expected to
operate continuously without routine interruption.
2) Connectivity between NCS and MOS device is expected
to operate continuously and without routine interruption.
3) Brief unplanned discontinuities in operation of
either NCS or MOS, or connectivity between them, will be viewed as an error
condition.
4) Discontinuities which result in un-ACK’d messages
will be handled by buffering messages in the transmitter until they are ACK’d
by the receiver.
5) Devices will not attempt to transmit further messages
until the current message is acknowledged.
6) Message transmissions which do not receive a response
will be retried at intervals until a response is received.
7) Message “ACK”s signify the message was received and
was parsed correctly – and nothing more.
These ACKs will be sent as soon as possible and without delay. They will be sent independent of and before
any internal checks an application might make to, for example, check status of
media objects, etc. If there is a
problem with media object status, this will be communicated via the <roItemStat>
message.
Very
Important Note:
Changes to the list sequence are made
relative to existing elements in the list.
This allows a system to transmit only the changes to a list without
sending the entire list, top to bottom.
Thus, it is absolutely critical that all messages be applied in the
order they are received. If a message in
a sequence is not applied or “missed” then it is guaranteed that all subsequent
messages will cause the sequence in the MOS to be even further out of
sequence.
Recommended Work Practice: It is
recommended that after an object is inserted into a playlist by the NCS, either
as a result of RO creation or RO modification, that the MOS system, in addition
to providing the ACK, send a following <roItemStat>
message to the NCS.
Exchanging
Messages between MOS devices
To
send one of the “roConstruction” messages from an NCS to a MOS:
1) The NCS device will open a socket on the upper port
to the MOS if it is not already open
2) The NCS will send the roConstruction message
3) The NCS will hold the socket open
4) The NCS will wait for a roAck message to be returned
on the same socket before either dropping the socket or transmitting the next
message.
5) The NCS can optionally send <heartbeat>
messages at regular intervals to the remote machine and look for a response.
Recommended Work Practice: It is not
necessary to disconnect the socket once the ACK has been received. It may be more efficient and require less
overhead to simply leave the socket open until the next message is transmitted,
even if this is not immediate. If the
socket is dropped the application should re-establish the socket before the
next message is transmitted. It is a
good idea to establish and maintain the socket connection continuously as this
gives the other application the opportunity to monitor continuity.
Important Application Note: When a socket is closed, either locally or
remotely, care should be taken to ensure the socket is completely
disconnected. This is a 4 step process
involving communication between both machines.
It is normally taken care of at a
level below application development.
However, if problems are experienced establishing a socket between
machines after at least one socket connection has been established and then
dropped, this may be a sign the first socket was not properly closed. Check the status of all network connections
on both machines. Indications of
“FIN_WAIT_2” or “CLOSE_WAIT” on ports used for MOS communications are a
sign of a problem.
MOS message
flow is strictly sequential
The
Media Object Server will not send the next upper port message until the last
message is acknowledged.
Flow
of message traffic on the lower port is unrelated to acknowledgements on the
upper port and vice versa.
If
the value of <status> in the roAck message is “NACK”
then a more verbose error message is contained in <statusDescription>.
Recommended Work Practice: Some devices
wait only a finite time for a response.
If this response is not received they will transmit an unacknowledged message again. It is recommended that all devices provide
acknowledgement of messages within a maximum of 60 seconds of receipt. The faster ACK messages are received the more
efficient integrated systems will function.
Please keep in mind the adverse effects unnecessary cumulative delayed
responses will have in high message environment.
If
a MOS device receives a message from the NCS which references an <roID>
or <storyID>
which is not known to the MOS within the context of the application of the
message, then the MOS device will assume there has been a prior error in
communication with the NCS. The MOS will
then request a full list of the Running Order/Content List from the NCS via the
<roReq>
message to the NCS and the <roList> response to the MOS.
For
instance, if a MOS device receives an <roElementAction>
message which references an unknown <roID>, <storyID> or <itemID>,
the MOS device will send an <roReq> message to the NCS which
includes the <roID>.
The NCS will then respond with an <roList> message
which includes the entire current context of the RO/Content List.
Recommended Work Practice: “ro”
messages allow the NCS to dynamically transmit a sequence of objects to a MOS
device. The MOS device then determines
what to do with this list. In the case
of video and audio equipment, this list from the NCS often represents the
sequence to be played on air. Just
because content is presented in an ordered list does not imply an absolute need
to actually execute the list in order.
Specific applications may allow users to “hop around” and execute the
list out of order without actually changing the list.
Important Note: If for any
reason the sequence of the Running Order/Content List on the MOS device is
intentionally changed such that it no longer represents the sequence as
transmitted from the NCS, the MOS device will immediately send a series of <roItemStat>
messages to the NCS with a <status> of “DISCONNECTED” and ACK all
subsequent “ro” messages with a <status> of “DISCONNECTED”.
The
MOS device can recover synchronization with the NCS by sending an <roReq>
message to the NCS and receiving a full <roList> message in
return. Information in the <roList>
message will be used to replace the list previously modified through user input
in the MOS device.
The
MOS device can optionally send an <roStat> message to the NCS indicating
the RO/Content List is under manual or NCS control.
The
<roElementAction> message in MOS v2.8 functionally
replaces the following messages used in older versions of the protocol:
Important
Note:
In future versions of the MOS Protocol
support for these messages will be dropped.
At present, applications and
devices claiming support for MOS v2.8 Profile 2 must support all of these
messages for backwards compatibility plus the functionally equivalent <roElementAction>
which will be forward compatible.
The
<roReadyToAir>
message, sent from the NCS to the MOS device, is used to indicate that a
specified RO/Content List is editorially approved or not approved for
output. This message has no direct
impact on MOS message flow or sequencing.
It is up to individual vendors and customers to determine what work
practices and functionality may be linked to this message.
This
Profile allows an NCS to request a Media Object Server create a new object with
specific properties, attributes and metadata description. It also allows a Media Object Server to
replace an Item Reference embedded within a specific Story/Running Order.
In addition to support for Profiles 0,
1 and 2, these additional MOS Protocol Messages must be supported for Profile
3:
General
Work Flow for Profile 3
The <mosObjCreate>
message
·
An NCS or NCS
user wishes to create a new object on a Media Object Server.
·
The NCS sends a
request to the Media Object Server, via the <mosObjCreate>
message, to create a new Object or Place Holder to the Media Object Server.
·
Within the <mosObjCreate>
message the NCS sends a description and metadata for the new object.
·
The Media Object
Server responds with a <mosAck> message, which includes:
o If the object was created, contains a <status>
value of “ACK” and a <statusDescription>
which contains the new <objID> value.
o If the object was not created, contains a <status>
value of “NACK” and a <statusDescription> which contains a
textual error message.
·
If the Object
was created as a result of the request, the Media Object Server also sends a
new <mosObj>
message on the lower port. This message
will contain the full object description, pointer and metadata.
Recommended Work Practice: Media
Objects created with this message may be either real or virtual. What really matters to work flow is that an
<objID>
be returned which will eventually reference the actual media object.
The <mosItemReplace>
message
§
A Media Object
Server wishes to replace all or part of an Item Reference embedded in Story.
§
Story data is
“owned” by the NCS and cannot be changed by the Media Object Server.
§
Item Data that
is copied from Object Data is “owned” by the Media Object Server and can be
changed, even though it is embedded in a Story.
§
Although the
Item Reference can be changed by the Media Object Server, its position within
the Story cannot.
§
The Media Object
Server sends a <mosItemReplace> message, referencing
the <roID>,
<storyID>
and <itemID>
which points to the Item Reference to be changed.
§
The NCS will
replace or merge the data in the <item> structure. (See the protocol
definition for <mosItemReplace> for specifics)
§
The NCS will
respond with an <roAck> message, and if successful:
§
<roAck>
will have a <status> value of “ACK”
§
The NCS will
send a further and independent <roStoryReplace>
message, which the Media Object Server must accept and ACK.
§
If Profile 4 is
supported, the NCS will also send an independent <roStorySend>
message which must also be accepted and ACK’d.
This
profile enables a device to request a full list of all Running Orders/Content
Collections under MOS control in an NCS.
It also allows any device to receive the full context of data associated
with a Running Order/Content List and send contextual “cues” to the parent
Media Object Server.
In addition to support for Profiles 0,
1 and 2, these additional MOS Protocol Messages must be supported for Profile
4:
General
Work Flow for Profile 4
<roReqAll> and
<roListAll>
are functionally similar to <roReq> and <roList>.
<roReqAll>
is a request from the MOS device to the NCS for a list of all MOS Active
Running Orders. <roListAll>
is the response from the NCS. The list
contains the <roID>, <roSlug> and other
metadata. For a full listing of the
contents of the RO the MOS device must issue a subsequent <roReq>
using a <roID>
from the <roListAll> message.
<roStorySend>
is a method by which the NCS can send the complete body of a story to another
device.
This
is useful for prompters and publishing devices which must be aware not only of
the sequence of stories but also the full body of text and metadata for each
story, which is not otherwise sent.
Recommended Work Practice: To send a
complete list of stories associated with a Running Order along with the bodies
of all Stories, the NCS must first construct a playlist in the Media Object
Server using the “roConstruction” messages, taking care to send *all* <story>
structures, not just Stories which contain <item> structures
belonging to a specific device. (
When changing the sequence of an
Running Order/Content List which is linked to a MOS device via “roConstruction”
and <roStorySend> messages, it is important to use the
<roElementAction> message to effect moves in the story sequence, rather
than using options for delete and insert.
Once a story is deleted from the list the receiving device may assume
the body of the story is no longer needed and delete it, thus requiring an
unnecessary and repetitive <roStorySend> message after the <roElementAction>
“insert” command.
This
profile enables applications to send “cue” and control commands to Media Object
Servers
In addition to support for Profiles 0,
1 and 2, these additional MOS Protocol Messages must be supported for Profile
5:
<roItemCue> is a
method used to signal or “cue” a parent MOS device at a specific time.
This
message is for notification only, but can be used by the parent Media Object
Server to allow other applications to trigger rendering, publishing or output
of a specific Item Reference to an Object at a specific time, which can be in
the future. This is not a specific
command to play or take action on an object.
<roCtrl> is a
method used to signal or “cue” a parent MOS device at a specific time.
This
message allows other devices to send specific and unambiguous “PLAY” “EXECUTE”
“PAUSE” “STOP” AND “SIGNAL” commands to a Media Object Server. Though these messages were originally
intended for control of audio and video servers, their application should not
be thought of as limited to these types of output devices.
Application
Note: The use and timing of these
messages is subject to network propagation and application processing
latency. Synchronicity and frame
accuracy can be achieved in the application of the <roItemCue> message if
an event to which it is linked can be anticipated by an amount of time equal to
or greater than total link latency. The
<roEventTime>
can then be set to an appropriate future value which in effect leads system
latency.
This
Profile provides a mechanism for <item> structures containing media
objects from one server to be meaningfully included in messages sent to a
server other than the one on which they are immediately stored. This information enables servers to automate
the transfer of these objects between machines, using methods independent of
the MOS Protocol.
Profile 6 requires full support for
Profiles 0, 1 and 2 and can be applied to Profiles 3, 4 and 5
Fully Qualified MOS ID
Profile
6 does not include any additional MOS messages.
However, it does require that all MOS device compatible with Profile 6
use a specific naming convention for <mosID>’s and <ncsID>’s
of this form:
<family>.<machine>.<location>.<enterprise>.mos
Where <location> and <enterprise> are
optional.
This is called a “Fully Qualified MOS ID”
For
example, these are valid Fully Qualified MOS ID’s:
aveed.server2.camden.cbs.mos
tornado.mach2.wjla.allbritton.mos
Quantuml.VidServ2.mos
Sonny.point77.city.company.mos
Using this naming
convention, it is possible for a machine to determine whether an object is
stored locally or on another machine of the same family or compatible family,
and for that machine to make separate arrangements for the transfer of the
referenced object to the local machine.
This functionality can be
extended to transfer material between machines located in the same building,
different buildings or different cities.
The transfer mechanism is
separate from the MOS Protocol, which only provides the Fully Qualified MOS
ID.
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 will travel.
A scope of “object” implies
this information is generally descriptive of the object and appropriate for
queries. The metadata will 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 will 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, will 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 individual mosObj messages.
Pause of zero indicates that all objects will be sent using the
mosListAll message..
mosAck - which then initiates
one of the following:
mosListAll - if pause = 0
mosObj - if pause > 0
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 messages from the MOS to the NCS. mosListAll is initiated by a properly Ack’d mosReqAll message from the NCS.
mosAck
mos
mosID
ncsID
mosListAll
objTB
objRev
objDur
status
objAir
createdBy
created
changedBy
changed
description
(p | em | tab)*
mosExternalMetadata*
mosScope?
<!ELEMENT mosListAll
(mosObj*)>
<!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)>
Example
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<mosListAll>
<mosObj>
<objID>M000123</objID>
<objSlug>HOTEL FIRE</objSlug>
<objType>VIDEO</objType>
<objGroup>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>
</mosObj>
<mosObj>
<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>
</mosObj>
</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
an 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?
itemUserTimingDur?
itemTrigger?
macroIn?
macroOut?
<!ELEMENT mosItemReplace (roID, storyID, item)>
<!ELEMENT item (itemID, itemSlug?,
objID, mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?,
itemUserTimingDur?, 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>
<itemUserTimingDur>310</itemUserTimingDur>
<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. The
response may contain the status for one or more Items in a Running Order. This
is useful when the roAck is in response to a roCreate or roReplace 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?
itemUserTimingDur?
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?,
itemUserTimingDur?, 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:02:00</roEdStart>
<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>
<itemUserTimingDur>310</itemUserTimingDur>
<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>
<itemUserTimingDur>200</itemUserTimingDur>
<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?
itemUserTimingDur?
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?,
itemUserTimingDur?, 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>
<itemUserTimingDur>310</itemUserTimingDur>
<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>
<itemUserTimingDur>310</itemUserTimingDur>
<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” its 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” its 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?
itemUserTimingDur?
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?,
itemUserTimingDur?, 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>
<itemUserTimingDur>310</itemUserTimingDur>
<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>
<itemUserTimingDur>310</itemUserTimingDur>
<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
ro*
roID
<!ELEMENT roListAll
((ro*)>
<!ELEMENT ro (roID,
roSlug?, roChannel?, roEdStart?, roEdDur?, roTrigger?,
mosExternalMetadata*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<roListAll>
<ro>
<roID>
<roSlug>5PM Rundown</roSlug>
<roChannel></roChannel>
<roEdStart>2003-07-11T17:00:00</roEdStart>
<roEdDur>00:30:00</roEdDur>
<roTrigger>MANUAL</roTrigger>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://ncsA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<mediaTime>0</mediaTime>
<TextTime>278</TextTime>
<ModBy>LJOHNSTON</ModBy>
<Approved>0</Approved>
<Creator>SHOLMES</Creator>
</mosPayload>
</mosExternalMetadata>
</ro>
<ro>
<roID>
<roSlug>6PM Rundown</roSlug>
<roChannel></roChannel>
<roEdStart>2003-07-09T18:00:00</roEdStart>
<roEdDur>00:30:00</roEdDur>
<roTrigger>MANUAL</roTrigger>
<mosExternalMetadata>
<mosScope>PLAYLIST</mosScope>
<mosSchema>http://ncsA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>
<mosPayload>
<Owner>SHOLMES</Owner>
<mediaTime>0</mediaTime>
<TextTime>350</TextTime>
<ModBy>BSMITH</ModBy>
<Approved>1</Approved>
<Creator>SHOLMES</Creator>
</mosPayload>
</mosExternalMetadata>
</ro>
</roListAll>
</mos>
Method for the MOS to update
the NCS on the status of Play List. This allows the NCS 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.
Note: The NCS should use the equivalent
roElementAction message to achieve the same result.
mos
mosID
ncsID
roStoryAppend
roID
story*
storyID
storySlug?
mosExternalMetadata*
item*
itemID
itemSlug?
objID
mosID
mosAbstract?
itemChannel?
itemEdStart?
itemEdDur?
itemUserTimingDur?
itemTrigger?
macroIn?
macroOut?
<!ELEMENT
roStoryAppend (roID, story+)>
<!ELEMENT story (storyID,
storySlug?, storyNum?, mosExternalMetadata*, item*)>
<!ELEMENT item (itemID, itemSlug?,
objID, mosID, mosAbstract?, itemChannel?, itemEdStart?, itemEdDur?,
itemUserTimingDur?, 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>
<itemUserTimingDur>310</itemUserTimingDur>
<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>