MOS Protocol version 2.8.3
Document Revision 548
Revision Date:
Friday, August 11, 2006
Copyright 2000, 2001, 2002,
2003, 2004, 2005, 2006 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.3 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.3 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 v2.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.
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
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 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
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. 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. roElementStat – Status of a Single Element in a MOS
Running Order
3.7.3. roItemCue – Notification of an Item Event
3.7.4. 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. 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.2 to 2.8.3
7.2. Changes from MOS version 2.8.1 to
2.8.2
7.3. Changes
from MOS version 2.8 to 2.8.1
7.4. Changes
from MOS version 2.6 to 2.8
7.5. Changes to MOS version 2.6
WD-2001-08-09
7.6. Changes from MOS version 2.5 to 2.6 WD-2001-06-06
7.7. Changes
from MOS version 2.0 to 2.5 WD-2000-08-01
7.8. Changes
for MOS 2.0 WD-1999-05-12
7.9. 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 2006 and IBC 2005.
The roStorySend message has been modified to allow for transmission of agency/wire protocol data. This has been implemented by adding an optional attribute, Read1stMEMasBody, to the storyBody tag that indicates an agency/wire transmission is in use. The Read1stMEMasBody tag will allow the first MEM block to substitute the story body. Users should look for the body of the story in the first MEM block. Examples of agency/wire data are newsML, IPC, NAA, and other custom formats.
RoElementStat is a new method for the MOS to
update the NCS on the status of any Item, Story, or a RO. This allows the NCS to reflect the status of
any element in the MOS Running Order in the NCS Running Order display.
RoElementStat now makes roStat and roItemStat legacy commands. RoElementStat
will be used in profile 2 as a means of the MOS
updating the NCS on the status of items as well as ROs. Additionally, roElementStat will be used in profile 4 as a means for the MOS to update a NCS on the
status of a story.
An
attribute has been added to the mosReqObjList family of messages and the
roReqStoryAction messages which identifies a username.
A reminder: MOS Protocol
v2.8.3 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.3.
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 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.3 compliant 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 versions 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.3 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
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
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 “FIN_WAIT_2” or “CLOSE_WAIT” 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.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 v2.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”.
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 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. 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
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 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 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
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:
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.3 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 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
·
An NCS Server or NCS Client,
communicating with the MOS on the new port 10542, wishes to receive a list of
mosObj messages which meet certain search criteria.
·
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. (
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
the status of the Story changes in the MOS device the MOS device should send
roElementStat messages for that story to the NCS.
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.
MOS Lower Port (10540) - Media Object Metadata
mos
mosID
ncsID
messageID
mosAck
objID
objRev
status
statusDescription
<!ELEMENT mosAck
(objID, objRev, status, statusDescription)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<messageID>99</messageID>
<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 <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.
mos
mosID
ncsID
messageID
mosObj
objTB
objRev
objDur
status
objAir
objProxyPath*
createdBy
created
changedBy
changed
description
(p | em | tab)*
mosExternalMetadata*
mosScope?
<!ELEMENT mosObj (objID, objSlug, mosAbstract?, objGroup?, objType,
objTB, objRev, objDur, status, objAir, objPaths?, createdBy, created,
changedBy, changed, description, mosExternalMetadata*)>
<!ELEMENT
description (#PCDATA | p | em | tab)*>
<!ELEMENT
p (#PCDATA | em | tab)*>
<!ELEMENT mosExternalMetadata (mosScope?, mosSchema, mosPayload)>
<!ELEMENT mosScope (#PCDATA)>
<!ELEMENT objPaths (objPath*, objProxyPath*)>
<!ELEMENT mosSchema
(#PCDATA)>
<!ELEMENT mosPayload
ANY>
<!ELEMENT messageID
(#PCDATA)>
<!ELEMENT objPath
(#PCDATA)>
<!ELEMENT objProxyPath
(#PCDATA)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<messageID>34</messageID>
<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>
<objPaths>
<objPath
techDescription="MPEG2
Video">\\server\media\clip392028cd2320s0d.mxf</objPath>
<objProxyPath
techDescription="WM9
750Kbps">http://server/proxy/clipe.wmv</objProxyPath>
</objPaths>
<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 the NCS to
request the description of an object.
mosObj
- if objID is found
mosAck - otherwise
MOS Lower Port (10540) - Media Object Metadata
mos
mosID
ncsID
messageID
mosReqObj
<!ELEMENT mosReqObj
(objID)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<messageID>654</messageID>
<mosReqObj>
<objID>M000123</objID>
</mosReqObj>
</mos>
Method for the NCS to
request the MOS to send it a mosObj message 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 Lower Port (10540) - Media Object Metadata
mos
mosID
ncsID
messageID
mosReqAll
<!ELEMENT mosReqAll (pause)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<messageID>234</messageID>
<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
mosObj*
objTB
objRev
objDur
status
objAir
objProxyPath*
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, objPaths?, 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 ANY>
<!ELEMENT
messageID (#PCDATA)>
<!ELEMENT
objPaths (objPath*, objProxyPath*)>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<messageID>2010</messageID>
<mosListAll>
<mosObj>
<objID>M000123</objID>
<objSlug>HOTEL FIRE</objSlug>
<objPaths>
<objPath
techDescription="MPEG2
Video">\\server\media\clip392028cd2320s0d.mxf</objPath>
<objProxyPath
techDescription="WM9
750Kbps">http://server/proxy/clipe.wmv</objProxyPath>
</objPaths>
<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>
<objPaths>
<objPath
techDescription="MPEG2
Video">\\server\media\clip392028cd2320s0d.mxf</objPath>
<objProxyPath
techDescription="WM9 750Kbps">http://server/proxy/clipe.wmv</objProxyPath>
</objPaths>
<createdBy>Phil</createdBy>
<created>1998-11-01T15:19:01</created>
<changedBy>Chris</changedBy>
<changed>1998-11-01T15:21:15</changed>
<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>
mosReqObjList family of
messages
To retrieve only selected
object descriptions from a MOS.
10542
NCS SERVER to MOS and NCS
CLIENT to MOS
mosReqSearchableSchema
mosListSearchableSchema
mosReqObjList
mosObjList
1)
NCS sends a mosReqSearchableSchema
message to the MOS.
2)
MOS responds with a
mosListSearchableSchema message.
3)
NCS can then perform a query by sending
a mosReqObjList message, using one or both of the Search Options below
a)
Search Method #1 (Simple): Perform
a general search based on the textual content of the <generalSearch>
field. The following six examples illustrate valid values for this field.
<generalSearch>man</generalSearch>
<generalSearch>man dog</generalSearch>
<generalSearch>man and
dog</generalSearch>
<generalSearch>man not
dog</generalSearch>
<generalSearch>man or
dog</generalSearch>
<generalSearch>man and
dog not poodle</generalSearch>
Note: only one <generalSearch> tag is allowed per message
The
simple method will search all default fields in the MOS database, as defined by
the MOS vendor. Only one <generalSearch> field may be present.
b)
Search Method #2 (Complex): Perform
a specific query based on the value of selected external metadata (MEM)
fields. These queries are wrapped in the <searchGroup> tag.
The <searchGroup> structure can be used with or without
<generalSearch>, as in Method #1. The following is a valid example:
<searchGroup>
<searchField XPath="/Presenter
[. =’Bob’]" sortByOrder="1"/>
<searchField XPath="/Slug
[.=’Dog Abuse’]"/>
<searchField XPath="/Video/Length
[.>60 AND <120]" sortByOrder="2" sortType="DESCENDING"/>
<searchField XPath="Producer
[.!=’Susan’]" sortByOrder="3"/>
</searchGroup>
<searchGroup>
<searchField XPath="/Presenter
[. =’Jennifer’]" sortByOrder="1"/>
<searchField XPath="/Slug
[.=’Big Mice in City’]"/>
<searchField XPath="/Video/Length
[.>60 AND <120]" sortByOrder="2" sortType="DESCENDING"/>
<searchField XPath="Producer
[.!=’Susan’]" sortByOrder="3"/>
</searchGroup>
Multiple <searchGroup> structures are
logically “OR”ed with each other.
The attributes
included in each <searchField> tag were derived from the schema returned
in the initial mosListSearchableSchema message.
mosSchema must be an HTTP
pointer to a valid schema. This schema is passed to the NCS by the MOS via
the mosListSearchableSchema message.
Note: The schema must be valid XML.
searchField must contain
an XPath statement which conforms to a subset of the W3C XPath 1.0
specification. The specification can be found here: http://www.w3.org/TR/xpath
Minimum implementations must support Basic XPath Expressions
needed to process Abbreviated Syntax for Location Paths with Location Steps that
may contain Predicates with Operators “and”, “or”, “<”, ”>”, “>=”,
“<=”, “=”, “!=”, and the following functions:
1. String
Functions
|
Function |
Parameters |
Return Type |
Description |
|
String |
object? |
String |
Converts to string |
2. Number
Functions
|
Function |
Parameters |
Return Type |
Description |
|
Number |
object? |
Number |
Converts to a number |
3. Boolean
Functions
|
Function |
Parameters |
Return Type |
Description |
|
Boolean |
object |
Boolean |
Converts to a boolean value |
|
False |
|
Boolean |
Returns false |
|
Not |
boolean |
Boolean |
Inverts a boolean value |
|
True |
|
Boolean |
Returns true |
XPath search requests are assumed to be case
sensitive.
Rules on Sorting are as follows:
·
All fields of the same name have to have
the same sortByOrder and sortType attributes for the same fieldname. This
is why, for example, /Presenter is the same in the first searchGroup as it is
in the second.
·
No two unlike fields can share the same
sort order. Presenter can’t be sortByOrder = 1 in the same request as
Producer has a sortByOrder of 1.
·
The MOS determines sorting rules
according to the natural language of the MOS System Environment
<searchField>’s within the same <searchGroup>
are logically joined (AND’ed).
Multiple <searchGroup>’s are allowed.
Each <searchGroup> is logically “OR”ed with the others.
A maximum of six <searchGroup> structures is
recommended.
4)
The MOS returns a list of mosObj messages,
encapsulated in the mosObjList message, to the NCS. The number and
sequence of these messages is specified by the NCS.
5)
The NCS can handle the returned mosObj
messages as normal, meaning the objIDs they hold can be validly used with ActiveX
controls, within item references, with playlist construction, etc.
Note: Use of the mosReqObjList group of messages
between NCS SERVER and MOS and NCS CLIENT and MOS should
take place on port 10542. Because of the potential for this family of messages
to generate large amounts of network traffic and consume application bandwidth,
this message has been assigned a separate and specific port in order to
minimize potential impact on mission critical operations taking place on ports
10540 and 10541. Other future messages may also share port 10542.
General notes
Both Search Methods can be
used together, in which case the <generalSearch> is logically joined
(AND’ed) with the <searchGroup> results. The Simple and Complex
methods may also be used separately and independent of each other.
The <generalSearch>
tag must always be present, even if Null.
For both methods the NCS can
specify the number of search results to return, which is the difference between
the integer values of <listReturnStart> and <listReturnEnd>.
The <listReturnStart>
tag must always be present and must always have a value of 1 or greater.
The <ListReturnEnd>
tag must always be present, but a value is optional. If a value is
present, it must be greater than or equal to <listReturnStart>.
Omission of a value for
<listReturnEnd> implies that *all* possible search results should be
returned. Care should be taken when implementing this option to avoid returning
more pointers than is necessary which may overwhelm network or application
bandwidth.
Paging is supported by
supplying chained values for <listReturnStart>
and <listReturnEnd>, e.g. 1-20, 21-40,
41-80. These values represent requests in the mosReqObjList
message. In the mosObjList message these values indicate the actual
number of objects returned.
<listReturnTotal>applies only to the mosObjList
message and this tag is required. If the value is null, this indicates
generally more than one object has been found. A non zero value indicates
the total number of objects which meet the search criteria and can be returned.
A zero value of
<listReturnTotal> indicates no objects were located which meet the search
criteria. In this case the values of <listReturnStart> and
<listReturnEnd> would also be zero.
<listReturnStatus> should contain a human
readable status message, of 128 max characters, which indicates the reason for
a zero value in <listReturnTotal>. <listReturnStatus> can
optionally be used to return additional human readable status information when
<listReturnTotal> is a non-zero value.
Cached searching is enabled
by the mandatory use of the <queryID> field, which
is defined as a 128 character ID unique within the scope of the NCS
system. Though the full values of <generalSearch> and/or
<searchGroup>’s must still be supplied in each and every
<mosReqObjList> message, the <queryID> value provides a short cut
for the MOS device, which may choose to buffer the results of first query and
then return additional paged requests for the same query from a buffer.
A mechanism for the NCS to request the MOS send a
pointer to a schema in which searchable fields are defined by the MOS device.
10542
NCS SERVER to MOS and NCS
CLIENT to MOS
mosListSearchableSchema
mos
mosID
ncsID
messageID
mosReqSearchableSchema
(username)
<!ELEMENT
mosReqSearchableSchema EMPTY>
<!ATTLIST
mosReqSearchableSchema username CDATA #IMPLIED>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<messageID>9012</messageID>
<mosReqSearchableSchema username=”jbob”/>
</mos>
A mechanism for the MOS to send
a pointer to a schema in which searchable fields are defined for the NCS
device.
10542
Communication Type
MOS to NCS SERVER
and MOS to NCS CLIENT
None – this is a response to
mosReqSearchableSchema.
mos
mosID
ncsID
messageID
mosListSearchableSchema
(username)
mosSchema
<!ELEMENT mosListSearchableSchema (mosSchema)>
<!ATTLIST
mosListSearchableSchema username CDATA #IMPLIED>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<messageID>2782</messageID>
<mosListSearchableSchema username=”jbob”>
<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>
</mosListSearchableSchema>
</mos>
To retrieve only selected
object descriptions from a MOS.
10542
NCS SERVER to MOS and NCS
CLIENT to MOS
mosObjList
mos
mosID
ncsID
messageID
mosReqObjList
(username)
listReturnStart
listReturnEnd
mosSchema
searchGroup*
searchField+
(XPath,
sortByOrder, sortType)
<!ELEMENT
mosReqObjList (queryID, listReturnStart, listReturnEnd, generalSearch,
mosSchema, searchGroup*)>
<!ATTLIST
mosReqObjList username CDATA #IMPLIED>
<!ELEMENT
queryID (#PCDATA)>
<!ELEMENT
generalSearch (#PCDATA)>
<!ELEMENT
listReturnStart (#PCDATA)>
<!ELEMENT
listReturnEnd (#PCDATA)>
<!ELEMENT
searchGroup (searchField+)>
<!ELEMENT
searchField EMPTY>
<!ATTLIST
searchField
XPath CDATA #REQUIRED
sortByOrder CDATA #IMPLIED
sortType CDATA #IMPLIED
>
<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<messageID>6666</messageID>
<mosReqObjList username=”jbob”>
<queryID>123439392039393ade0393zdkdls</queryID>
<listReturnStart>1</listReturnStart>
<listReturnEnd/>
<generalSearch>man bites dog</generalSearch>