MOS Protocol
version 3.8.4
Document Revision 11
Revision
Date: March 22, 2013
Copyright
2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 , 2011, 2012, 2013, 2014. 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 3.8.4
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 v3.8.4 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.
You are not allowed to
make representations of MOS Compatibility unless you have followed these
guidelines.
MOS is
a seven 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 2006
and IBC 2005 and is referred to as MOS v3.8.3. 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.
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
2.8. Profile 7 – MOS RO/Content List Modification
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
3.2.3
mosReqSearchableSchema
3.2.4
3.2.4 mosListSearchableSchema
3.2.5 3.2.5 mosReqObjList
3.2.6
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
3.3.3 mosReqObjAction – NCS requests action on MOS
object
“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.
roReadyToAir - Identify
a Running Order as Ready to Air
3.6. ro Story and Item Sequence
Modification
3.6.1. roElementAction
– Performs specific Action on a Running Order
3.7. ro Control and Status
feedback
3.7.1.
roElementStat – Status of a Single Element 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
3.9. MOS
RO/Content List Modification
3.9.1.
roReqStoryAction – MOS requests
action on NCS story
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
4.1.7.
objPaths
– Unambiguous
pointers to media files
5. ActiveX
Control Specification
5.1 Methods, Events and Data Types
5.3 ActiveX Communication messages
5.3.1.
5.3.1 ncsAck - Acknowledge message
5.3.2.
5.3.2 ncsReqAppInfo – Request Application information and
context
5.3.3.
5.3.3 ncsAppInfo – Application information and context
5.3.4.
5.3.4 ncsReqAppMode – Request to run Plug-In in different
size window
5.3.5.
ncsStoryRequest
5.3.6.
5.3.6 ncsItemRequest – Request the NCS Host or ActiveX
Plug-In to send an Item
5.3.7.
roStorySend
5.3.9.
mosItemReplace
5.3.10 ncsReqStoryAction – ActiveX can create, edit, or replace stories on a NCS
7.1. Changes
from MOS version 3.8.3 to 3.8.4
8. MOS 3.8.4 WSDL
9.2. WSDL FAQ
9.3. Recommended
Reading
9.4. WSDL Web Sites
This document
is a working draft of MOS 3.8.4. The
following changes have been made to this document:
·
objTB
examples and explanation have been made clearer by using the specific time base
codes for NTSC. Previous versions of MOS
used the objTB of 30 for NTSC time base this would result in a objTB of 60 for
NTSC. MOS 2.8.4 uses the exact time base
value of 29.97 for NTSC this results in NTSC having a objTB of 59.94.
·
The
listMachInfo
message has been modified to allow a device to define itself as a NCS or a
MOS. Additionally, the message requires
the definition of supported MOS Profiles.
·
ncsReqStoryAction is a new method for ActiveX Plug-Ins
to create, edit, or replace stories on a NCS
·
roReqStoryAction
has been modified to give the MOS the ability to MOVE story(s) and CREATE more
than one story.
·
The
attribute techDescription
was previously defined as not being required, this has been corrected. techDescription is a required attribute of objPath
and objProxyPaths.
·
objMetadataPath
has been added to the objPaths structure.
objMetadataPath is a path that resolves to the MOS object xml file.
·
Updated
definitions for mosItemReplace and MOS Object “UPDATED” messages
The purpose of
these profiles is to define basic levels of functionality enabled by the MOS
Protocol v3.8.4.
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
Profile 7 – MOS RO/Content List
Modification
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 Web Services via HTTP.
Messages
required for support of Profile 0:
General
Work Flow for Profile 0
·
Establish communication
to another MOS device
·
Call a heartBeat
method from another application and receive a heartbeat datatype
in response
·
Call a reqMachInfo
method from another application and receive a listMachInfo
datatype in response.
Implementation
Notes
This
Profile encompasses the most basic requirements and functions to support MOS
Protocol message transfer. The three basic methods included in this
profile, heartBeat,
reqMachInfo
and listMachInfo
can be exchanged between any MOS v3.8.3 compliant devices
Profile
0 required MOS method 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 a heartbeat
datatype.
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 data exchange:
1) Network Connectivity: You must
be able to “Ping” the remote machine hosting the application with which you
wish to communicate.
2)
HTTP
Connectivity: You must be able to connection with the remote application
via HTTP.
3)
Application
Response: You must be able to receive an ACK datatype in response to the
method you have called.
If
you can call a heartBeat method and receive a heartbeat
datatype in response you have verified the continuity at all three levels.
Each
heartbeat datatype 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
datatype.
This
datatype is a response to the reqMachinfo and allows the machine to identify itself
with manufacturer ID, model, hardware and software revisions, MOS version
supported, etc.
This
datatype also identifies which MOS Profiles it supports, as well as the device
type.
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 datatype 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 UTF-8, as defined in The
Unicode Standard, version 4.0.
MOS
Message Format
The
MOS Protocol Web Service uses XML as the Interface description language (IDL).
In versions 3.x, the protocol bindings and message formats required to interact
with the web service are defined in the MOS Web Services WSDL (Web Services
Description Language) .
Web
Services Description Language (WSDL)
WSDL
describes the interface to the web service.
It is an XML-based services description on how to communicate using the
web service. A client application
connecting to a web service can read the WSDL to learn the methods available on
the server. All special datatypes used
are embedded in the WSDL file in the form of an XML Schema. SOAP is used to to actually call one of the
methods listed in the WSDL.
All
tags are case sensitive. All MOS methods and datatypes must be well formed XML,
and are required to be valid.
Simple
Object Access Protocol (SOAP )
SOAP is a protocol for exchanging
XML-based messages over a computer network using HTTP. SOAP forms the foundation layer of the Web
services stack, providing a basic messaging framework that more abstract layers
can build on. It is an XML based protocol that
consists of three parts: an envelope that defines a framework for describing
what is in a message and how to process it, a set of encoding rules for
expressing instances of application-defined datatypes, and a convention for
representing remote procedure calls and responses.
MOS Header
Each
MOS web service method contains the mosHeader complex datatype. The
mosHeader_type encapsulates the mosID, ncsID, and messageID. To prevent naming conflics each method
contains a complex type for each MOS method and is named like so:
“methodName_type”. For example,
heartbeat_type.
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
The
following rules apply:
·
Data
tags and meaningful constants (like UPDATE) are formatted as English
·
Data
Fields containing string values (like title etc.) can contain other languages.
·
Data
Fields containing datatime, time or number values are formatted as English and
have the formats defined in the Section 6 “Field Descriptions”
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 intended 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
Web
services use XML as the Interface description language (IDL) and SOAP over HTTP
as the network protocol.
MOS
Protocol v3.X will only use one TCP/IP port, but servers can optionally provide
the same set of messages on a separate port.
The default port is 10543 and the optional port is 10544. The use of an optional port will allow MOS
and NCS servers to set different priorites between the two ports. For example, port 10543 can have the highest
priority to handle all RO and mosObj create messages and port 10544 can have a
lower priority of handling federated searches via mosReqObjList family of
messages.
If
a MOS message request 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.2 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
v3.8.3 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”.
In regards to the <mosObj> “UPDATED” message; if metadata tags exist in the target MOS Object and are not
present in the <mosObj> “UPDATED” message, the
metadata tags in the target Item Reference should be left intact.
Also, if the intention
is to remove a tag from the target MOS Object, It should be included in the
<mosObj> “UPDATED” message with
a null value.
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 many 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 send
the mosObj message
2)
The MOS device will wait for
a mosAck message to be returned before transmitting the next message.
3)
The MOS device can
optionally send <heartbeat> messages at regular
intervals to the remote machine
MOS
message flow is strictly sequential
The
Media Object Server will not send the message until the last message is
acknowledged.
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. There is one
exception: MOS metadata that was created by the NCS can be modified by the NCS.
The mosReqObjAction message provides this
capability.
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 zero.
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
General
Work Flow for Profile 2
·
Within the NCS Stories
containing Item References can be placed into Running Orders (RO’s are 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 <roElementStat>
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)
An
ACK message signifies that:
·
the message was received and parsed correctly, and
·
the data contained in the message was saved or does
not need be saved by the receiver, and
·
metadata objects (rundowns,stories,items,object as
metadata) which in sent messages are assumed to exist in the receiver, actually
do exist in the receiver.
However any existence checks or status checks
regarding material / essences are typically not performed at this time, but
when further operation requires it.
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 <roElementStat>
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 will send the roConstruction
message
2)
The NCS will wait for a
roAck message to be returned before transmitting the next message.
3)
The NCS can optionally
send <heartbeat>
messages at regular intervals to the remote machine.
MOS
message flow is strictly sequential
The
Media Object Server will not send the next message until the last message is
acknowledged.
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 efficiently 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 <roElementStat> 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 <roElementStat> 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:
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 to 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, and request that a MOS device return a list of
mosObj descriptions which meet certain search criteria..
In
addition to support for Profiles 0, 1 and 2, these additional MOS Protocol
Messages must be supported for Profile 3:
mosReqObjList family of messages
General
Work Flow for Profile 3
The
<mosObjCreate>
and <mosReqObjAction>
messages
·
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, a <status> value of “ACK” and a <statusDescription>
which contains the new <objID> value.
o
If the object was not
created, 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.
·
The
NCS may also modify or delete the Object or Placeholder that it created, using
the mosReqObjAction message.
· 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 a 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>, <roItemReplace>, or <roElementAction> 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.
The
<mosReqObjList> family of messages
·
For a general search, the
NCS or NCS Client sends a mosReqObjList message with a simple search string as
the value of the <generalSearch> tag.
o
Logical operators are
allowed in this string.
o
The MOS devices will
search its database for this general search term. The internal data
fields to which the MOS applies this search term is determined by the MOS.
·
For a field specific
search, the NCS or NCS client must first ask the MOS device for a list of field
definitions, in the form of a schema
o
The NCS or NCS client
sends a mosReqSearchableSchema message to the MOS.
o
The MOS returns a list of
schema pointers, in the form of URI’s, to the NCS or NCS client in the
mosListSearchableSchema message.
o
If the
mosListSearchableSchema message contains no URI’s, then the NCS should
recognize that the MOS device does not support field specific searching.
o
The NCS or NCS client
then retrieves the schema and specifies field(s) to search with the value
of the <searchField> tag(s) in the mosReqObjList message.
o
Multiple
<searchField> tags can be included in within a single <searchGroup>
structure. All <searchField> tags will be logically “AND”ed.
o
Multiple
<searchGroup> structures can be included. These will be logically
“OR”ed.
·
The MOS device then
returns a sequence of mosObj messages which meet the search criteria.
o
These messages are
encapsulated in the mosObjList message.
o
The information in the
mosObj messages, including objIDs can be used as normal by the NCS or NCS
Client.
It is recommended that this family of messages be used to re-synchronize the NCS and MOS devices instead of the older mosReqAll message.
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. (Normal practice is to use “roConstruction”
messages to send only <story> structures that contain <items>
belonging to the parent Media Object Server.) This is followed by an <roStorySend>
message for each of the Stories in the NCS Running Order/Content
Collection. In this way changes to the order of the Stories can be
communicated without retransmitting Story objects. Likewise, a Story can
be updated without making a change to the Story Sequence.
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.
As
“roConstruction” and roStorySend messages are processed the status of these
stories are sent from the MOS to the NCS via the <roElementStat> message.
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.
Vendors
claiming compatibility with Profile 6 must support, at a minimum, automated
transfer of objects between machines of the same family within the vendor’s
product line.
This
profile enables a Media Object Server to make changes to the running order in a
Newsroom Computer System.
In
addition to support for Profiles 0, 1 and 2, these additional MOS Protocol
Messages must be supported for Profile 7:
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
acknowledgement for the <mosObj> message.
None – this
is a response to various MOS-initiated messages.
objID
objRev
status
statusDescription
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body> <mosObjResponse xmlns="http://mosprotocol.com/webservices/"> <mosObjResult> <objID>M000123</objID> <objRev>1</objRev> <status>ACK</status> <statusDescription> </statusDescription> </mosObjResult> </mosObjResponse> </soap:Body>
</soap:Envelope>
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 <mosExternalMetadata> 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 <mosScope> 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.
objTB
objRev
objDur
status
objAir
objMetadataPath
createdBy
created
changedBy
changed
description
(p | em | tab)*
mosExternalMetadata*
mosScope?
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body> <mosObj xmlns="http://mosprotocol.com/webservices/"> <mosHeader_input> <mosID>string</mosID> <ncsID>string</ncsID><messageID>int</messageID>
</mosHeader_input> <mosObj_input> <objID>string</objID> <objSlug>string</objSlug> <mosAbstract>string</mosAbstract> <objGroup>string</objGroup> <objType>string</objType> <objTB>string</objTB> <objRev>string</objRev> <objDur>string</objDur> <status>string</status> <objAir>string</objAir> <objPaths> <objPath>string</objPath> <objProxyPath>string</objProxyPath> <objMetadataPath>string</objMetadataPath> </objPaths> <createdBy>string</createdBy> <created>string</created> <changedBy>string</changedBy> <changed>string</changed> <description>string</description> <mosExternalMetadata> <mosExternalMetadata_type> <mosScope>string</mosScope> <mosSchema>string</mosSchema> <mosPayload xsi:nil="true" /></mosExternalMetadata_type>
<mosExternalMetadata_type> <mosScope>string</mosScope><mosSchema>string</mosSchema>
<mosPayload xsi:nil="true" /></mosExternalMetadata_type>
</mosExternalMetadata> </mosObj_input> </mosObj> </soap:Body></soap:Envelope>