MOS Protocol version 2.8.1
Document Revision 5.22
Revision Date:
Copyright 2000, 2001, 2002,
2003, 2004, 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:
1. You must use and implement all messages defined
by the MOS protocol MOS 2.8.1 Profiles listed below per the profiles
supported by your device.
2. You may not modify message names, order of defined
tags within a message, tag structure, defined values, standards and constants.
3. You may not process messages in a means that is dependent
on non-standard messages, tags or structures.
4. You may add additional tags to messages, but the
modified messages must contain the defined minimum required tags for each
message, in the order defined by this document.
5. Implementations of the MOS Protocol following the
above guidelines may claim to be “MOSä Compatible” or “MOSä v2.8.1 Compatible”
6. If You add additional tags, it is strongly
recommended these be included and encapsulated only within the provided
<mosExternalMetadata> structure and not inserted into the pre-defined
body of the message.
7. It is inappropriate to make representations of MOS
Compatibility unless you have followed these guidelines.
MOS is a six 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 2004 and
IBC 2003 and is referred to as MOS v2.8.1. 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
mosReqObjList family of messages
3.2.3 mosReqSearchableSchema
3.2.4 mosListSearchableSchema
3.2.5 mosReqObjList
3.2.6 mosObjList
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
4.1.6.
messageID - Unique
Identifier for Requests
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
7.1. Changes from MOS version 2.8 to 2.8.1
7.2. Changes
from MOS version 2.6 to 2.8
7.3. Changes from MOS version 2.5 to
2.6 WD-2001-06-06
7.4. Changes
from MOS version 2.0 to 2.5 WD-2000-08-01
7.5. Changes for
MOS 2.0 WD-1999-05-12
7.6. Changes
from MOS version 1.52 to 2.0 WD-1999-03-17
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 2004 and IBC 2003.
A new family of messages has
been added to allow the NCS to query the MOS for object metadata meeting
certain criteria. The mosReqObjList message supports a subset of the XPath
query language for mosObj message retrieval. They have been added to Profile 3
– Advanced Object-Based Workflow.
A new messageID element has
been added to all the MOS device messages to support intelligent retry if a
connection times out before a response to a message has been received. Three
ActiveX messages also had the messageID tag added:
ncsAppInfo
mosItemReplace
roStorySend
The ActiveX messages do not
require a value for the tag, as the communication happens within a single
process.
A new ActiveX message
ncsReqAppClose has been added. A hosted ActiveX Plugin can send this message to
the NCS Host when it wants to shut itself down.
The roElementAction message
description has been rewritten to make its use clearer. More examples have also
been added. The message syntax and functionality have not changed.
All messages are now
included in the DTD in Section 8. All the example messages have been validated
by the DTD.
A reminder: MOS
Protocol v2.8.1 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.1.
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.1 complaint devices