Media Object Server (MOStm
Protocol v2.8.4

MOS Protocol version 2.8.4
Document Revision 551

Revision Date: September 10, 2014

Copyright Notice

Copyright 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014. All Rights Reserved.

License

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.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 v2.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.

Abstract

MOS is a ten year old, evolving protocol for communications between Newsroom Computer Systems (NCS) and Media Object Servers (MOS) such as Video Servers, Audio Servers, Still Stores, Character Generators, Automation Servers, and Prompters.  The MOS Protocol development is supported through cooperative collaboration among equipment vendors, software vendors and end users.

Status of this document

This document reflects changes to the MOS protocol discussed during the MOS meetings at NAB 2008, IBC 2008, and IBC NAB 2009 and is referred to as MOS v2.8.4.  This is the final draft.  Changes are summarized here.

How to use this document

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.

 

 

 


Media Object Server Protocol v2.8.4

Table of Contents

 

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.6.  Profile 5 – Item Control

 

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.8.2               roElementStat –Status of a Single Element in a MOS 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.2  Behavior

 

5.3 ActiveX Communication messages

5.3.1.                             ncsAck – Acknowledge Message

5.3.2.                             ncsReqAppInfo – Request Aplication Information and Context  

5.3.3.                             ncsAppInfo – Application Information and Context

5.3.4.                             ncsReqAppMode – Request to Run Plug-in in Different Size Window

5.3.5.                             ncsStoryRequest – Request the NCS Host to Send a Story

 

5.3.6.                             ncsItemRequest – Request the NCS Host or ActiveX Plug-In to Send an Item

5.3.7.                             roStorySend – Allows the NCS Host to Send a Story Body to the ActiveX Plug-In

5.3.8.                             ncsItem – Allows Either the ActiveX Plug-In or NCS Host to Send an Item Reference to the Other Application

5.3.9.                             mosItemReplace – Allows the ActiveX Plug-In to Replace an Existing Item in a Story

5.3.10             ncsReqAppClose – Request to close window for Plug-In

5.3.11             ncsReqStoryAction – ActiveX can create, edit, or replace stories on a NCS

 

 

6.       Field Descriptions

 

 

7.      Recent Changes

 

7.1. Changes from MOS version 2.8.3 to 2.8.4

7.2. Changes from MOS version 2.8.2 to 2.8.3Changes from MOS version 2.8.2 to 2.8.3

7.3.  Changes from MOS version 2.8.1 to 2.8.2

7.4.  Changes from MOS version 2.8 to 2.8.1

7.5.  Changes from MOS version 2.6 to 2.8

7.6. Changes to MOS version 2.6 WD-2001-08-09

7.7.  Changes from MOS version 2.5 to 2.6 WD-2001-06-06

7.8.  Changes from MOS version 2.0 to 2.5 WD-2000-08-01

7.9.  Changes for MOS 2.0 WD-1999-05-12

7.10.  Changes from MOS version 1.52 to 2.0 WD-1999-03-17

 

 

8.      MOS 2.8.4 DTD

 

9.  MOS 2.8.4 XSD

 

10.      References and Resources

 

10.1.  MOS Protocol Web Page

10.2.  XML FAQ

10.3.  Recommended Reading

10.4.  XML Web Sites

 

 

1. Introduction

This document is a working draft of MOS 2.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.

·         MOS 2.8.4 XSD section was added and was updated on September 10, 2014.

·         Fixed a number of typos and added hyperlinks where necessary to improve this document’s readability.

·         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

 

A reminder:  MOS Protocol v2.8.4 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.

 


2. MOS Profiles

 

The purpose of these profiles is to define basic levels of functionality enabled by the MOS Protocol v2.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 5 – Item Control

Profile 6 – MOS Redirection

Profile 7 – MOS RO/Content List Modification

 

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.

 

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 of the seven profiles they support.  For instance "MOS Compatible – Profiles 0,1,2,3,4,5,6,7"

 

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 and 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.

 


2.1 Profile 0 – Basic Communication

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:

 

heartbeat

reqMachInfo

listMachInfo

 

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.4 compliant devices

 

Profile 0 required MOS message support

 

heartbeat

 

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 "Ping" the remote machine hosting the application with which you wish to communicate.

 

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 a <heartbeat> message in response to the <heartbeat> 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.

 

 

reqMachInfo

 

This message is a request for the target machine to respond with a listMachInfo message.

 

 

listMachInfo

 

This message allows the machine to identify itself with manufacturer, model, hardware and software revisions, and MOS profiles supported, etc. 

 

This message identifies which MOS Profiles the application supports, as well as the device type. 

 

Optionally, the machine may also 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.4 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 developers 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 and MOS)

   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 Lower Port (10540) is defined as the default TCP/IP port on which the NCS will accept connections from MOS devices. Multiple simultaneous connections are supported. This socket is referred to as "Media Object Metadata" port in the Message Types section.

 

MOS Upper Port (10541) is defined as the default TCP/IP port on which the MOS will accept connections from the NCS.  Multiple simultaneous connections are supported.  This socket is referred to as "Running Order" port in the Message Types section.

 

MOS uses two ports bi-directionally.  Applications will simultaneously listen for messages on both ports – see Message Exchange below.

 

NOTE:Ports 10520 and 10521 were specified as Lower and Upper Ports in previous versions of the MOS Protocol.  Beginning in version 2.5  these ports are vendor selectable but site specific.   All MOS enabled machines within a site or enterprise should communicate using the same ports.

 

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, a NCS initiated a create running order command and the MOS' associated ACK would take place on MOS Upper Port (10541). Object updates sent from the MOS and the associated NCS ACK would take place on MOS Lower Port (10540).

 

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 an Ack 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 wait 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

 

                    Lower Port (10540)----<

 

                                                            \----Socket2

 

 

 

                                                           /----Socket1

 

                    Upper Port (10541)----<

 

                                                           \----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 port.

 

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.

 

 

 


 

2.2 Profile 1 – Basic Object Workflow

This profile allows a Media Object Server to push messages, which represent objects contained on the Media Object Server, to other machines.

 

In addition to support for Profile 0, these additional messages are required for support of Profile 1:

 

 

            mosAck

            mosObj

            mosReqObj

            mosReqAll

            mosListAll

 

 

 

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 stories as Item References.  Item References are derived from <mosObj> information.

 

·        Optionally, an ActiveX control, provided by the Media Object 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.4 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 Object 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.4 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 within 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 with 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. A socket status of  "FIN_WAIT_2" or "CLOSE_WAIT" on ports used for MOS communications indicates that there may be 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, cannot 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.

 

Users at an NCS workstation can change MOS related data via an ActiveX control should one be provided by the Media Object Server vendor.  The ActiveX can be instantiated within the NCS UI and provide the ability to edit, create, and delete MOS data.  This method is permitted since the vendor’s ActiveX control, not the NCS,  modifies 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.

 

The first method 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 workflow interaction.

 

The second method is advantageous as it has 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..

 

 

 


2.3 Profile 2 – Basic Running Order/Content List Workflow

Profile two gives a NCS the ability 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

 

            roAck

            roCreate

            roReplace

            roDelete

            roReq

            roList

            roMetadataReplace

            roDelete

             roElementStat

            roElementAction

            roReadyToAir

 

 

            Included only for backwards compatibility:

 

roStoryAppend

roStoryInsert

roStoryReplace

roStoryMove

roStoryMoveMultiple

roStorySwap

roStoryDelete

roItemInsert

roItemReplace

roItemMoveMultiple

roItemDelete

           roStat

                       roItemStat

 


General Work Flow for Profile 2

 

·        NCS Stories containing Item References can be placed into Running Orders (RO’s are also referred to as Content Lists). 

 

·        The NCS 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 construction messages.  MEM blocks with a <mosScope> of "STORY" are stripped and not sent.

 

·        The NCS provides the Parent Media Object Server a list pointing to Objects that are in the same order as they are used in the Play List/Content List. 

 

·        The Media Object Server must always keep track of the list sequence 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)     Connectivity between NCS and MOS device is expected to operate continuously and without routine interruption.

 

2)     Brief unplanned discontinuities in operation of either NCS or MOS, or connectivity between them, will be viewed as an error condition.

 

3)    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.

 

4)     Devices will not attempt to transmit further messages until the current message is acknowledged.

 

5)     Message transmissions which do not receive a response will be retried at intervals until a response is received. 

 

6)     An ACK message signifies that:

·         The message was received and parsed correctly

·         The data contained in the message was saved or does not need be saved by the receiver

·         Metadata objects (rundowns, stories, items, and objects as metadata) within sent messages are assumed and 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 is more efficient and requires 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 unnecessary cumulative delayed responses will have an adverse effect in high message environments.

 

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 order of 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: 

 

roStoryAppend

roStoryInsert

roStoryReplace

roStoryMove

roStoryMoveMultiple

roStorySwap

roStoryDelete

roItemInsert

roItemReplace

roItemMoveMultiple

roItemDelete

 

 

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.4 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.

 

 

 

 


2.4 Profile 3 – Advanced Object Based Workflow

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:

 

            mosObjCreate

 

            mosItemReplace

 

            mosReqObjList family of messages

 

           mosReqSearchableSchema

mosListSearchableSchema

mosReqObjList

mosObjList

   

            mosReqObjAction

 

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.  When an <objID> is returned it will eventually reference an 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, may 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.

  

 


2.5 Profile 4 – Advanced  RO/Content List Workflow

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:

 

 

           roReqAll

           roListAll

           roStorySend

 

 

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.  This 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 the status of the Story changes in the MOS device the MOS device should send roElementStat messages for that story to the NCS.

 

 

 

 

 

 

 

 


2.6 Profile 5 – Item Control

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

            roCtrl

 

 

<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.

 

 

 

 


2.7 Profile 6 – MOS Redirection

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.  Furthermore, this naming convention allows a server tomake 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.


 2.8 Profile 7 – MOS RO/Content List Modification

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:

 

            roReqStoryAction

 


3. Media Object Server Protocol Message Definition

In the Structural Outline sections below use of

 

·         "?" specifies optional element

·         "+" specifies one or more of the element

·         "*"  specifies zero or more of the element

 

Note: 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.

 


3.1 Basic Object Communication

3.1.1 mosAck - Acknowledge MOS Object Description

Purpose

mosAck is the acknowledgement response to various types of messages.

Response

None – this is a response to various messages.

Port

MOS Lower Port (10540) - Media Object Metadata

Structural Outline

mos
    mosID
    ncsID
 
   messageID
      mosAck

      objID
       objRev
       status
       statusDescription

Syntax

<!ELEMENT mosAck (objID, objRev, status, statusDescription)>

Example

<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>

 


3.1.2 mosObj - MOS Object Description

Purpose

Contains information that describes a unique MOS Object to the NCS. The NCS uses this information to search for and reference the MOS Object.

<objGroup> tag

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.

External Metadata Block

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.

External Metadata <mosScope> tag

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.

Response

mosAck

Port

MOS Lower Port (10540) - Media Object Metadata

Structural Outline

            mos
               
mosID
               
ncsID
               
messageID
               
mosObj

                   objID
                  
objSlug

                   mosAbstract?
                  
objGroup?

                   objType

                   objTB
                  
objRev
                  
objDur
                  
status
                  
objAir

                    objpaths?

            objPath*

            objProxyPath*

                       objMetadataPath
                  
createdBy
                  
created
                  
changedBy
                  
changed
                  
description
                        (
p | em | tab)*

                   mosExternalMetadata*
                      
mosScope?

                      mosSchema

mosPayload

Syntax

<!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*, objMetadataPath*)>

<!ELEMENT mosSchema (#PCDATA)>

<!ELEMENT mosPayload ANY>

<!ELEMENT messageID (#PCDATA)>

<!ELEMENT objPath (#PCDATA)>

<!ELEMENT objProxyPath (#PCDATA)>

<!ELEMENT objMetadataPath (#PCDATA)>

Example

<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>59.94</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>

<objMetadataPath techDescription="MOS Object">http://server/proxy/clipe.xml</objMetadataPath>

</objPaths>

      <createdBy>Chris</createdBy>

      <created>2009-10-31T23:39:12</created>

      <changedBy>Chris</changedBy>

      <changed>2009-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>

 


3.1.3 mosReqObj - Request Object Description

Purpose

Message used by the NCS to request the description of an object.

Response

mosObj - if objID is found
mosAck - otherwise

Port

MOS Lower Port (10540) - Media Object Metadata

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
mosReqObj

       objID

Syntax

<!ELEMENT mosReqObj (objID)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>654</messageID>

   <mosReqObj>

      <objID>M000123</objID>

   </mosReqObj>

</mos>

 

 


3.2 Object Resynchronization/Rediscovery

3.2.1 mosReqAll - Request All Object Data from MOS

Purpose

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..

Response

mosAck - which then initiates one of the following:

 

mosListAll - if pause = 0
mosObj - if pause > 0

 

 

Port

MOS Lower Port (10540) - Media Object Metadata

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
mosReqAll

       pause

Syntax

<!ELEMENT mosReqAll (pause)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>234</messageID>

   <mosReqAll>

<pause>0</pause>

   </mosReqAll>

</mos>

 


3.2.2 mosListAll - Listing of All Object Data from MOS

Purpose

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.

Response

mosAck

Port

MOS Lower Port (10540) - Media Object Metadata

Structural Outline

mos
   
mosID
   
ncsID
   
messageID

    mosListAll

      mosObj*

                   objID
                  
objSlug

                   mosAbstract?
                  
objGroup?

                   objType

       objTB
                  
objRev
                  
objDur
                  
status
                  
objAir

                   objPaths?

             objPath*

             objProxyPath*

             objMetadataPath
                  
createdBy
                  
created
                  
changedBy
                  
changed
                  
description
                        (
p | em | tab)*

                   mosExternalMetadata*
                      
mosScope?

                      mosSchema

mosPayload 

 

Syntax

<!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*, objMetadataPath)> 

Example

<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>

<objMetadataPath techDescription="MOS Object">http://server/proxy/clipe.xml</objMetadataPath>

</objPaths>

      <createdBy>Chris</createdBy>

      <created>2009-10-31T23:39:12</created>

      <changedBy>Chris</changedBy>

      <changed>2009-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>59.94<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>

<objMetadataPath techDescription="MOS Object">http://server/proxy/clipe.xml</objMetadataPath>

</objPaths>

      <createdBy>Phil</createdBy>

      <created>2009-11-01T15:19:01</created>

      <changedBy>Chris</changedBy>

      <changed>2009-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

Purpose 

To retrieve only selected object descriptions from a MOS.

Port 

10542

Communication Type 

NCS SERVER to MOS and NCS CLIENT to MOS

 

Messages in this family

mosReqSearchableSchema

mosListSearchableSchema

mosReqObjList

mosObjList

 

Workflow

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 [.&gt;60 AND &lt;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 [.&gt;60 AND &lt;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 /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 not be sortByOrder = 1 in the same request as Producer having a sortByOrder = 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 <objID>s they hold can be validly used with ActiveX controls, within item references, and with playlist construction, etc.

 

 

Note:  Use of the <mosReqObjList> group of messages between NCS SERVER  à MOS and NCS CLIENT à 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.


3.2.3 mosReqSearchableSchema

Purpose 

mosReqSearchable Schema is a mechanism used by the NCS to request the MOS to send a pointer to a schema in which searchable fields are defined by the MOS device.

Port 

10542

Communication Type 

NCS SERVER to MOS and NCS CLIENT to MOS

Response

mosListSearchableSchema

Structural Outline

mos

mosID

   ncsID

   messageID

   mosReqSearchableSchema (username)

Syntax

<!ELEMENT mosReqSearchableSchema EMPTY>

<!ATTLIST mosReqSearchableSchema username CDATA #IMPLIED>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>9012</messageID>

   <mosReqSearchableSchema username="jbob"/>

</mos>

 

3.2.4  mosListSearchableSchema

Purpose 

mosListSearchableSchema is a mechanism used by the MOS to send a pointer to a schema in which searchable fields are defined for the NCS device.

Port 

10542

 

Communication Type 

 

 MOS to NCS SERVER and MOS to NCS CLIENT

Response

None – this is a response to mosReqSearchableSchema.

 

Structural Outline

mos

mosID

   ncsID

   messageID

   mosListSearchableSchema (username)

       mosSchema

 

Syntax

<!ELEMENT mosListSearchableSchema (mosSchema)>

<!ATTLIST mosListSearchableSchema username CDATA #IMPLIED>

 

Example

<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>


3.2.5  mosReqObjList

Purpose 

mosReqObjList is a mechanism used by a NCS to retrieve only selected object descriptions from a MOS.

Port 

10542

 

Communication Type 

NCS SERVER to MOS and NCS CLIENT to MOS

Response

mosObjList

 

Structural Outline

mos

   mosID

   ncsID

   messageID

   mosReqObjList (username)

        queryID

        listReturnStart

        listReturnEnd

        generalSearch

       mosSchema

       searchGroup*

            searchField+

                       (XPath, sortByOrder, sortType) 


Syntax

<!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

> 

Example

 

<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>

             <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

      <searchGroup>

         <searchField XPath="/Presenter [. =’Bob’]" sortByOrder="1"/>

         <searchField XPath="/Slug [.=’Dog Abuse’]"/>

   <searchField XPath="/Video/Length [.&gt;60 AND &lt;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 [.&gt;60 AND &lt;120]" sortByOrder="2" sortType="DESCENDING"/>

         <searchField XPath="Producer [.!=’Susan’]" sortByOrder="3"/>

      </searchGroup>

   </mosReqObjList>

</mos>


3.2.6  mosObjList

Purpose 

Returns selected object descriptions from a MOS.

Port 

10542

Communication Type 

MOS to NCS SERVER and MOS to NCS CLIENT

Response

        None – this is a response to mosReqObjList.

Structural Outline

mos

mosID

   ncsID

               messageID

               mosObjList (username)

                   queryID

 listReturnStart

                      listReturnEnd

                      listReturnTotal

 listReturnStatus?

                    list?

                        mosObj+

Syntax

<!ELEMENT mosObjList (queryID, listReturnStart, listReturnEnd, listReturnTotal, listReturnStatus?, list?)>

<!ATTLIST mosObjList username CDATA #IMPLIED>

<!ELEMENT listReturnTotal (#PCDATA)>

<!ELEMENT listReturnStatus (#PCDATA)>

<!ELEMENT list (mosObj+)>

 


Example

 

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>321</messageID>

   <mosObjList username="jbob">

      <queryID>A392938329kdakd2039300d0s9l3l9d0bzAQ</queryID>

      <listReturnStart>1</listReturnStart>

      <listReturnEnd>20</listReturnEnd>

      <listReturnTotal>128</listReturnTotal>

      <list>

         <mosObj>

            <objID>M000121</objID>

            <objSlug>Hotel Fire</objSlug>

            <mosAbstract>

               <b>Hotel Fire</b>

               <em>vo</em>

      </mosAbstract>

            <objGroup>Show 7</objGroup>

            <objType>VIDEO</objType>

            <objTB>59.94<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>

<objMetadataPath techDescription="MOS Object">http://server/proxy/clipe.xml</objMetadataPath>

       </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>

         <mosObj>

            <objID>M000122</objID>

            <objSlug>Another Hotel Fire</objSlug>

            <mosAbstract>

               <b>Hotel Fire</b>

               <em>vo</em>

      </mosAbstract>

            <objGroup>Show 7</objGroup>

            <objType>VIDEO</objType>

            <objTB>59.94<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>

<objMetadataPath techDescription="MOS Object">http://server/proxy/clipe.xml</objMetadataPath>

</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>

         <mosObj>

            <objID>M000123</objID>

            <objSlug>Yet Another Hotel Fire</objSlug>

            <mosAbstract>

               <b>Hotel Fire</b>

               <em>vo</em>

      </mosAbstract>

            <objGroup>Show 7</objGroup>

            <objType>VIDEO</objType>

            <objTB>59.94<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>

<objMetadataPath techDescription="MOS Object">http://server/proxy/clipe.xml</objMetadataPath>

</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>

      </list>

   </mosObjList>

</mos>

 


3.3 Object and Item management

3.3.1 mosObjCreate – MOS Object Create

Purpose

mosObjCreate allows an NCS to request the Media Object Server to create a Media Object with specific metadata associated with it.

Response

mosAck          (if object can be created then status description = objID)
           
mosAck          (if object CANNOT be created,  status = NACK and status description =  reason for error)
           
mosObj

Port

MOS Lower Port (10540) – MOS Object

Structural Outline

           mos
               
mosID
                
ncsID
               
messageID
                
mosObjCreate

                   objSlug

                  objGroup?
                   
objType
                   
objTB
                   
objDur?
                   
time?
                   
createdBy?
                   
description?

                   mosExternalMetadata*

Syntax

<!ELEMENT mosObjCreate (objSlug, objGroup?, objType, objTB, objDur?, time?, createdBy?, description?, mosExternalMetadata*)>
<!ELEMENT description (#PCDATA | p | em | tab)*>

<!ELEMENT p (#PCDATA | em | tab)*> 

Example 

<mos>

   <mosID>videoserver.station.com</mosID>

   <ncsID>ncs.station.com</ncsID>

   <messageID>724</messageID>

   <mosObjCreate>

<objSlug>Hotel Fire</objSlug>

      <objGroup>Show 7</objGroup>

      <objType>VIDEO</objType>

      <objTB>59.94<objTB>

      <objDur>1800</objDur>

      <createdBy>Chris</createdBy>

      <description>

         <p>

            Exterior footage of

            <em>Baley Park Hotel</em>

             on fire with natural sound. Trucks are

        visible for the first portion of the clip.

            <em>CG locator at 0:04 and duration 0:05, 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://NCSA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>

         <mosPayload>

            <Owner>SHOLMES</Owner>

            <ModTime>20010308142001</ModTime>

            <mediaTime>0</mediaTime>

            <TextTime>278</TextTime>

            <ModBy>LJOHNSTON</ModBy>

            <Approved>0</Approved>

            <Creator>SHOLMES</Creator>

         </mosPayload>

      </mosExternalMetadata>

   </mosObjCreate>

</mos>

 


3.3.2 mosItemReplace – Replace one Item Reference with another

Purpose

This message allows a Media Object Server to replace an Item Reference in a Story with new metadata values and/or additional tags.  The Story must be in a MOS Active PlayList.  Thus, this message is in the "ro" family of messages rather than the "mos," or lower port, family.  However, this message is initiated by the Media Object Server, rather than the NCS.

Behavior

This message must reference an existing unique Item Reference in a MOS Active PlayList through the values of ncsID, roID, storyID, and itemID.

 

If metadata tags in the mosItemReplace message already exist in the target Item Reference, values within the Item Reference will be replaced by the values in the mosItemReplace message. 

 

If the metadata tags do not already exist in the target Item Reference they will be added.

 

If metadata tags exist in the target Item Reference and are not present in the mosItemReplace message, the metadata tags in the target Item Reference should be left intact.

 

If the intention of the Media Object Server is to remove metadata tag(s) from the target Item Reference, those metadata tag(s) should be included in the mosItemReplace message with a null value.

   

If a mosExternalMetadata block is included in the mosItemReplace message, it will replace an existing mosExternalMetadata block only if the values of <mosSchema> in the two blocks match, and only for the first occurrence of a block with a matching <mosSchema> tag.  Otherwise the mosExternalMetadata  block will be added to the target Item Reference.

 

If the itemID in the mosItemReplace message does not match an existing itemID in the specified Story then no action will be taken and the mosItemReplace message will be replied to with an roAck message specifying the Item values in the mosItemReplace message and carrying a status value of "NACK."

Response

roAck

Subsequent messages

roStoryReplace, roItemReplace, roElementAction – A successful mosItemReplace operation will result in a change to an Item reference embedded in a Story.  This new information must now be placed in associated MOS Playlists.  Any one of the three messages listed will replace the old item reference in the playlist with the newly updated item reference from this Story.

roStorySend – A successful mosItemReplace operation will result in a change in the body of a Story.  This change must be sent back out if an roStorySend target has been defined for the RO.

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
  
mosID
  
ncsID
  
messageID
   mosItemReplace
      
roID
      
storyID
       
item
           
itemID
           
itemSlug?
           
objID
            mosID

            mosPlugInID?

            mosAbstract?

 objPaths?

            objPath*        

            objProxyPath*

           objMetadataPath
           
itemChannel?
           
itemEdStart?
           
itemEdDur?

           itemUserTimingDur?
           
itemTrigger?
           
macroIn?
           
macroOut?

            mosExternalMetadata*

Syntax

<!ELEMENT mosItemReplace (roID, storyID, item)>
<!ELEMENT item (itemID, itemSlug?, objID, mosID, mosPluginID?, mosAbstract?, objPaths?, itemChannel?, itemEdStart?, itemEdDur?, itemUserTimingDur?, itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*>

<!ELEMENT mosExternalMetadata (mosScope?, mosSchema, mosPayload)>


Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>9088</messageID>

   <mosItemReplace>

<roID>5PM</roID>

      <storyID>HOTEL FIRE</storyID>

      <item>

         <itemID>30848</itemID>

         <objID>M000627</objID>

         <mosID>testmos.enps.com</mosID>

    <objPaths>

<objPath techDescription="MPEG2 Video">\\server\media\clip392028cd2320s0d.mxf</objPath>

<objProxyPath techDescription="WM9 750Kbps">http://server/proxy/clipe.wmv</objProxyPath>

<objMetadataPath techDescription="MOS Object">http://server/proxy/clipe.xml</objMetadataPath>

    </objPaths>

         <itemEdStart>0</itemEdStart>

         <itemEdDur>815</itemEdDur>
         <itemUserTimingDur>310</itemUserTimingDur>

         <macroIn>c01/l04/dve07</macroIn>

         <macroOut>r00</macroOut>

         <mosExternalMetadata>

            <mosScope>PLAYLIST</mosScope>

            <mosSchema>HTTP://VENDOR/MOS/supportedSchemas/vvend280</mosSchema>

            <mosPayload>

               <trigger>837</trigger>

               <key>110</key>

               <fade>17</fade>

               <efxTime>15</efxTime>

            </mosPayload>

         </mosExternalMetadata>

      </item>

   </mosItemReplace>

</mos>


3.3.3 mosReqObjAction - NCS requests action on MOS object

Purpose

mosReqObjAction allows an NCS to request the Media Object Server to create, modify or delete a media object.  This is a request only.  A NACK response is perfectly valid and must be anticipated.  It is possible that an ACK may never be returned to the MOS.

Action

"operation" attribute

"objID" attribute

Create an Object

"NEW"

Attribute not used (should be omitted)

Modify an Object

"UPDATE"

objID of the referenced Object

Delete an Object

"DELETE"

objID of the referenced Object

 

 

A "NEW" operation creates a "placeholder" Object that has no media.

 

An "UPDATE" operation provides new metadata values for an existing Object. The intent is that the specified values will replace the corresponding Object values. The Media Object Server will merge in any mosExternalMetadata blocks as described in the mosItemReplace message.

 

A "DELETE" operation will delete an existing Object from the Media Object Server inventory.

 

The NCS must not expect an "UPDATE" operation to succeed if it contains new values for objType, objTB, or objDur and the Object already has actual media.

 

A Media Object Server may choose to report an action as successful even when it does not fulfil the entire request. For instance, the NCS might send an "UPDATE" operation containing new objSlug and objType values. If the Object already has media, the Media Object Server may change its objSlug value but leave its objType value unchanged. In that case, the Media Object Server may respond with an ACK whose status description indicates that some but not all values changed.

Response

mosAck

 

If the specified action cannot be completed, the status is NACK and the status description will define the error.

 

If the specified action is successfully completed, the message will take one of three forms: 

  1. If the action is "NEW," the status description will be the objID.
  2. If the action is "UPDATE," the status decription may be any additional information the Media Object Server wants to send. See the example above.
  3. If the action is "DELETE," the status description may include any additional information the Media Object Server wants to send.

Subsequent messages

If the specified action is successfully completed, the MOS will subsequently send a mosObj message. It will take one of three forms: 

  1. If the action is "NEW," the status will be "NEW."
  2. If the action is "UPDATE," the status will be "UPDATED."
  3. If the action is "DELETE," the status will be "DELETED."

Port

MOS Lower Port (10540) – MOS Object

Structural Outline

           mos
               
mosID
                
ncsID
               
messageID
                mosReqObjAction  (operation = {NEW, UPDATE, DELETE} objID={x})

                   objSlug?

                   mosAbstract?

                   objGroup?
                   
objType?
                   
objTB?
                   
objDur?
                   
 time?
                   
createdBy?

                   changedBy?

                   changed?
                   
descriptiondescription?

                   mosExternalMetadata*

Syntax

<!ELEMENT mosReqObjAction (objSlug?, mosAbstract?, objGroup?, objType?, objTB?, objDur?, time?, createdBy?, changedBy?, changed?, description?, mosExternalMetadata*)>
<!ELEMENT description (#PCDATA | p | em | tab)*>

<!ELEMENT p (#PCDATA | em | tab)*> 

<!ATTLIST mosReqObjAction

            operation CDATA #REQUIRED

            objID CDATA #IMPLIED

 


Example  - Create

<mos>

   <mosID>videoserver.station.com</mosID>

   <ncsID>ncs.station.com</ncsID>

   <messageID>724</messageID>

   <mosReqObjAction operation="NEW" >

<objSlug>Hotel Fire</objSlug>

      <objGroup>Show 7</objGroup>

      <objType>VIDEO</objType>

      <objTB>59.94<objTB>

      <objDur>1800</objDur>

      <createdBy>Chris</createdBy>

      <description>

         <p>

            Exterior footage of

            <em>Baley Park Hotel</em>

             on fire with natural sound. Trucks are

        visible for the first portion of the clip.

            <em>CG locator at 0:04 and duration 0:05, 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://NCSA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>

         <mosPayload>

            <Owner>SHOLMES</Owner>

            <ModTime>20010308142001</ModTime>

            <mediaTime>0</mediaTime>

            <TextTime>278</TextTime>

            <ModBy>LJOHNSTON</ModBy>

            <Approved>0</Approved>

            <Creator>SHOLMES</Creator>

         </mosPayload>

      </mosExternalMetadata>

   </mosReqObjAction>

</mos>

 


Example - Modify

<mos>

   <mosID>videoserver.station.com</mosID>

   <ncsID>ncs.station.com</ncsID>

   <messageID>724</messageID>

   <mosReqObjAction operation="UPDATE" objID="1EFA3009233F8329C1">

<objSlug>Hotel Fire</objSlug>

      <objGroup>Show 7</objGroup>

      <objType>VIDEO</objType>

      <objTB>59.94<objTB>

      <objDur>1800</objDur>

      <createdBy>Chris</createdBy>

      <description>

         <p>

            Exterior footage of

            <em>Baley Park Hotel</em>

             on fire with natural sound. Trucks are

        visible for the first portion of the clip.

            <em>CG locator at 0:04 and duration 0:05, 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://NCSA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>

         <mosPayload>

            <Owner>SHOLMES</Owner>

            <ModTime>20010308142001</ModTime>

            <mediaTime>0</mediaTime>

            <TextTime>278</TextTime>

            <ModBy>LJOHNSTON</ModBy>

            <Approved>0</Approved>

            <Creator>SHOLMES</Creator>

         </mosPayload>

      </mosExternalMetadata>

   </mosReqObjAction>

</mos>

 


Example - Delete

<mos>

   <mosID>videoserver.station.com</mosID>

   <ncsID>ncs.station.com</ncsID>

   <messageID>724</messageID>

   <mosReqObjAction operation="DELETE" objID="1EFA3009233F8329C1">

   </mosReqObjAction>

</mos>

 


ro (Running Order) family of messages

3.4 ro Playlist Construction

3.4.1 roAck - Acknowledge Running Order

Purpose

roAck is the MOS response to receipt of any Running Order command. The response may contain the status for one or more Items in a Running Order. This is useful when the roAck is in response to a roCreate or roReplace command.

Response

None

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
    messageID 
    roAck

       roID
      
roStatus
        (
storyID, itemID, objID, itemChannel?, status)*

Syntax

<!ELEMENT roAck (roID, roStatus, (storyID, itemID, objID, itemChannel?, status)*)>


Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>23569</messageID>

   <roAck>

<roID>96857485</roID>

      <roStatus>Unknown object M000133</roStatus>

      <storyID>5983A501:0049B924:8390EF2B</storyID>

      <itemID>0</itemID>

      <objID>M000224</objID>

      <status>LOADED</status>

      <storyID>3854737F:0003A34D:983A0B28</storyID>

      <itemID>0</itemID>

      <objID>M000133</objID>

      <itemChannel>A</itemChannel>

      <status>UNKNOWN</status>

   </roAck>

</mos>

 


3.4.2 roCreate - Create Running Order

Purpose

Message from the NCS to the MOS that defines a new Running Order.

Response

roAck

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
roCreate

       roID
      
roSlug
      
roChannel?
      
roEdStart?
      
roEdDur?
      
roTrigger?

       macroIn?

       macroOut?

       mosExternalMetadata*
      
story*
        
storyID
        
storySlug?

         storyNum?

         mosExternalMetadata*
        
item*
            
itemID
            
itemSlug?
            
objID
            
mosID

  mosAbstract?

  objPaths?

       objPath*

       objProxyPath*

       objMetadataPath

             itemChannel?
            
itemEdStart?
            
itemEdDur?

  itemUserTimingDur?
            
itemTrigger?
            
macroIn?
            
macroOut?

             mosExternalMetadata*

Syntax

<!ELEMENT roCreate (roID, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroIn?, macroOut?, mosExternalMetadata*, story*)>
<!ELEMENT story (storyID, storySlug?, storyNum?, mosExternalMetadata*,  item*)>
<!ELEMENT item (itemID, itemSlug?, objID, mosID, mosAbstract?, objPaths?, itemChannel?, itemEdStart?, itemEdDur?, itemUserTimingDur?, itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>30334</messageID>

   <roCreate>

<roID>96857485</roID>

      <roSlug>5PM RUNDOWN</roSlug>

      <roEdStart>2009-04-17T17:02:00</roEdStart>

      <roEdDur>00:58:25</roEdDur>

      <story>

         <storyID>5983A501:0049B924:8390EF2B</storyID>

         <storySlug>COLSTAT MURDER</storySlug>

         <storyNum>A5</storyNum>

         <item>

            <itemID>0</itemID>

            <itemSlug>COLSTAT MURDER:VO</itemSlug>

            <objID>M000224</objID>

            <mosID>testmos.enps.com</mosID>

       <objPaths>

     <objPath techDescription="MPEG2 Video">\\server\media\clip392028cd2320s0d.mxf</objPath>

     <objProxyPath techDescription="WM9 750Kbps">http://server/proxy/clipe.wmv</objProxyPath>

     <objMetadataPath techDescription="MOS Object">http://server/proxy/clipe.xml</objMetadataPath>

       </objPaths>

            <itemEdDur>645</itemEdDur>
            <itemUserTimingDur>310</itemUserTimingDur>

            <itemTrigger>CHAINED</itemTrigger>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

               <mosPayload>

                  <Owner>SHOLMES</Owner>

                  <transitionMode>2</transitionMode>

                  <transitionPoint>463</transitionPoint>

                  <source>a</source>

                  <destination>b</destination>

               </mosPayload>

            </mosExternalMetadata>

         </item>

      </story>

      <story>

         <storyID>3854737F:0003A34D:983A0B28</storyID>

         <storySlug>AIRLINE INSPECTIONS</storySlug>

         <storyNum>A6</storyNum>

         <item>

            <itemID>0</itemID>

            <objID>M000133</objID>

            <mosID>testmos.enps.com</mosID>

            <itemEdStart>55</itemEdStart>

            <itemEdDur>310</itemEdDur>
             <itemUserTimingDur>200</itemUserTimingDur>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

               <mosPayload>

                  <Owner>SHOLMES</Owner>

                  <transitionMode>2</transitionMode>

                  <transitionPoint>463</transitionPoint>

                  <source>a</source>

                  <destination>b</destination>

               </mosPayload>

            </mosExternalMetadata>

         </item>

      </story>

   </roCreate>

</mos>

 


3.4.3 roReplace - Replace Running Order

Purpose

Replaces an existing Running Order definition in the MOS with another one sent from the NCS.

Response

roAck

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
roReplace

       roID
      
roSlug
      
roChannel?
      
roEdStart?
      
roEdDur?
      
roTrigger?

       macroIn?

       macroOut?

       mosExternalMetadata*
      
story*
        
storyID
        
storySlug?

         storyNum?

         mosExternalMetadata*
        
item*
            
itemID
            
itemSlug?
            
objID
            
mosID

  mosAbstract?

  objPaths?

       objPath*

      objProxyPath*

     objMetadataPath
            
itemChannel?
            
itemEdStart?
            
itemEdDur?
             
itemUserTimingDur?
            
itemTrigger?
            
macroIn?
            
macroOut?

             mosExternalMetadata*

Syntax

<!ELEMENT roReplace (roID, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroIn?, macroOut?, mosExternalMetadata*, story*)>
<!ELEMENT story (storyID, storySlug?, storyNum?, mosExternalMetadata*,  item*)>
<!ELEMENT item (itemID, itemSlug?, objID, mosID, mosAbstract?, objPaths?, itemChannel?, itemEdStart?, itemEdDur?, itemUserTimingDur?, itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>2345</messageID>

   <roReplace>

      <roID>96857485</roID>

      <roSlug>5PM RUNDOWN</roSlug>

      <story>

         <storyID>5983A501:0049B924:8390EF2B</storyID>

         <storySlug>COLSTAT MURDER</storySlug>

         <storyNum>A1</storyNum>

         <item>

            <itemID>0</itemID>

            <itemSlug>COLSTAT MURDER:VO</itemSlug>

            <objID>M000224</objID>

            <mosID>testmos.enps.com</mosID>

<objPaths>

<objPath techDescription="MPEG2 Video">\\server\media\clip392028cd2320s0d.mxf</objPath>

<objProxyPath techDescription="WM9 750Kbps">http://server/proxy/clipe.wmv</objProxyPath>

      <objMetadataPath techDescription="MOS Object">http://server/proxy/clipe.xml</objMetadataPath>

</objPaths>

            <itemEdDur>645</itemEdDur>
            <itemUserTimingDur>310</itemUserTimingDur>

            <itemTrigger>CHAINED</itemTrigger>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

               <mosPayload>

                  <Owner>SHOLMES</Owner>

                  <transitionMode>2</transitionMode>

                  <transitionPoint>463</transitionPoint>

                  <source>a</source>

                  <destination>b</destination>

               </mosPayload>

            </mosExternalMetadata>

         </item>

      </story>

      <story>

         <storyID>3852737F:0013A64D:923A0B28</storyID>

         <storySlug>AIRLINE SAFETY</storySlug>

         <storyNum>A2</storyNum>

         <item>

            <itemID>0</itemID>

            <objID>M000295</objID>

            <mosID>testmos.enps.com</mosID>

            <itemEdStart>500</itemEdStart>

            <itemEdDur>600</itemEdDur>

            <itemUserTimingDur>310</itemUserTimingDur>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

               <mosPayload>

                  <Owner>SHOLMES</Owner>

                  <transitionMode>2</transitionMode>

                  <transitionPoint>463</transitionPoint>

                  <source>a</source>

                  <destination>b</destination>

               </mosPayload>

            </mosExternalMetadata>

         </item>

      </story>

   </roReplace>

</mos>

 


3.4.4 roMetadataReplace – Replace RO metadata without deleting the RO structure

Purpose

The roMetadataReplace message allows metadata associated with a running order to be replaced without deleting the running order and sending the entire running order again.

Behavior

This message must reference an existing running order

 

If metadata tags in the roMetadataReplace message already exist in the target
RO, values within the RO will be replaced by the values in the
roMetadataReplace message. 

 

If the metadata tags do not already exist in the target RO they will be added. 

 

If a mosExternalMetadata block is included in the roMetadataReplace message, it will replace an existing mosExternalMetadata block only if the values of mosSchema in the two blocks match.   Otherwise the mosExternalMetadata block will be added to the target RO.

 

If the roID in the roMetadataReplace message does not match an existing roID then no action will be taken and the roMetadataReplace message will be replied to with an roAck message which carrying a status value of "NACK."

Response

roAck

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
roMetadataReplace

       roID
      
roSlug
      
roChannel?
      
roEdStart?
      
roEdDur?
      
roTrigger?

       macroIn?

       macroOut?

       mosExternalMetadata?

Syntax

<!ELEMENT roMetadataReplace (roID, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroIn?, macroOut?, mosExternalMetadata?)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>654033</messageID>

   <roMetadataReplace>

<roID>96857485</roID>

      <roSlug>5PM RUNDOWN</roSlug>

      <roEdStart>2009-04-17T17:02:00</roEdStart>

      <roEdDur>00:58:25</roEdDur>

      <mosExternalMetadata>

         <mosScope>PLAYLIST</mosScope><mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

         <mosPayload>

            <Owner>SHOLMES</Owner>

            <transitionMode>2</transitionMode>

            <transitionPoint>463</transitionPoint>

            <source>a</source>

            <destination>b</destination>

         </mosPayload>

      </mosExternalMetadata>

   </roMetadataReplace>

</mos>

 

 


3.4.5 roDelete - Delete Running Order

Purpose

Deletes a Running order in the MOS.

Response

roAck

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
roDelete

       roID

Syntax

<!ELEMENT roDelete (roID)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>544</messageID>

   <roDelete>

      <roID>49478285</roID>

   </roDelete>

</mos>

 


3.5 ro Synchronization, Discovery and Status

3.5.1 roReq - Request Running Order

Purpose

Request for a complete build of a Running Order Playlist.

NOTE:  This message can be used by either NCS or MOS.

A MOS can use this to "resync" its Playlist with the NCS Running Order or to obtain a full description of the Playlist at any time.

An NCS can use this as a diagnostic tool to check the order of the Playlist constructed in the MOS versus the sequence of Items in the Running Order.

Response

roList or roAck (roAck is sent with the status value of NACK if the roID is not valid,  or if the Running Order is not available). 

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
roReq

       roID

Syntax

<!ELEMENT roReq (roID)>


 

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>30761</messageID>

   <roReq>

<roID>96857485</roID>

   </roReq>

</mos>

 


3.5.2 roList - List Running Order

Purpose

A complete build or rebuild of a Running Order Playlist in response to an roReq message.

NOTE:  This message can be sent by either the NCS or MOS

A MOS can use this to "resync" its Playlist with the NCS Running Order or to obtain a full description of the Playlist at any time.

An NCS can use this as a diagnostic tool to check the order of the Playlist constructed in the MOS versus the sequence of Items in the Running Order.

Response

None

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
roList

       roID
      
roSlug
      
roChannel?
      
roEdStart?
      
roEdDur?
      
roTrigger?

       macroIn?

       macroOut?

       mosExternalMetadata*
      
story*
        
storyID
        
storySlug?

         storyNum?

         mosExternalMetadata*
        
item*
            
itemID
            
itemSlug?
            
objID
            
mosID

 mosAbstract?

  objPaths?

       objPath*

       objProxyPath*

       objMetadataPath
            
itemChannel?
            
itemEdStart?
            
itemEdDur?

  itemUserTimingDur?
            
itemTrigger?
            
macroIn?
            
macroOut?

             mosExternalMetadata*

Syntax

<!ELEMENT roList (roID, roSlug, roChannel?, roEdStart?, roEdDur?, roTrigger?, macroIn?, macroOut?, mosExternalMetadata*, story*)>
<!ELEMENT story (storyID, storySlug?, storyNum?, mosExternalMetadata*,  item*)>
<!ELEMENT item (itemID, itemSlug?, objID, mosID, mosAbstract?, objPaths?, itemChannel?, itemEdStart?, itemEdDur?, itemUserTimingDur?, itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>111</messageID>

   <roList>

<roID>96857485</roID>

      <roSlug>5PM RUNDOWN</roSlug>

      <story>

         <storyID>5983A501:0049B924:8390EF2B</storyID>

         <storySlug>Colstat Murder</storySlug>

         <storyNum>B10</storyNum>

         <item>

            <itemID>0</itemID>

            <itemSlug>COLSTAT MURDER:VO</itemSlug>

            <objID>M000224</objID>

            <mosID>testmos.enps.com</mosID>

<objPaths>

<objPath techDescription="MPEG2 Video">\\server\media\clip392028cd2320s0d.mxf</objPath>

<objProxyPath techDescription="WM9 750Kbps">http://server/proxy/clipe.wmv</objProxyPath>

<objMetadataPath techDescription="MOS Object">http://server/proxy/clipe.wmv</objMetadataPath>

</objPaths>

            <itemEdDur>645</itemEdDur>
             <itemUserTimingDur>310</itemUserTimingDur>

            <itemTrigger>CHAINED</itemTrigger>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

               <mosPayload>

                  <Owner>SHOLMES</Owner>

                  <transitionMode>2</transitionMode>

                  <transitionPoint>463</transitionPoint>

                  <source>a</source>

                  <destination>b</destination>

               </mosPayload>

            </mosExternalMetadata>

         </item>

      </story>

      <story>

         <storyID>3854737F:0003A34D:983A0B28</storyID>

         <storySlug>Test MOS</storySlug>

         <storyNum>B11</storyNum>

         <item>

            <itemID>0</itemID>

            <objID>M000133</objID>

            <mosID>testmos.enps.com</mosID>

            <itemEdStart>55</itemEdStart>

            <itemEdDur>310</itemEdDur>

             <itemUserTimingDur>310</itemUserTimingDur>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

               <mosPayload>

                  <Owner>SHOLMES</Owner>

                  <transitionMode>2</transitionMode>

                  <transitionPoint>463</transitionPoint>

                  <source>a</source>

                  <destination>b</destination>

               </mosPayload>

            </mosExternalMetadata>

         </item>

      </story>

   </roList>

</mos>

 


3.5.3 roReqAll - Request All Running Order Descriptions

Purpose

roReqAll is a request for a description of all Running Orders known by a NCS from a MOS.

Response

roListAll

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID

    roReqAll

Syntax

<!ELEMENT roReqAll EMPTY>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>60543</messageID>

   <roReqAll/>

</mos>

 


3.5.4 roListAll - List All Running Order Descriptions

Purpose

The roListAll message provides a description of all Running Orders known by a NCS to a MOS.

Response

None

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID

    roListAll

      ro*
       
roID

       roSlug?

       roChannel?

       roEdStart?

       roEdDur?

       roTrigger?

       mosExternalMetadata*

Syntax

<!ELEMENT roListAll (ro*)>

<!ELEMENT ro (roID, roSlug?, roChannel?, roEdStart?, roEdDur?, roTrigger?, mosExternalMetadata*)>


Example

<mos>

 <mosID>aircache.newscenter.com</mosID>

 <ncsID>ncs.newscenter.com</ncsID>

   <messageID>300045</messageID>   

   <roListAll>

     <ro>

       <roID>5PM</roID>

       <roSlug>5PM Rundown</roSlug>

       <roChannel></roChannel>

       <roEdStart>2009-07-11T17:00:00</roEdStart>

       <roEdDur>00:30:00</roEdDur>

       <roTrigger>MANUAL</roTrigger>

       <mosExternalMetadata>

         <mosScope>PLAYLIST</mosScope>

         <mosSchema>http://ncsA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>

         <mosPayload>

            <Owner>SHOLMES</Owner>

            <mediaTime>0</mediaTime>

            <TextTime>278</TextTime>

            <ModBy>LJOHNSTON</ModBy>

            <Approved>0</Approved>

            <Creator>SHOLMES</Creator>

         </mosPayload>

      </mosExternalMetadata>

     </ro>

     <ro>

       <roID>6PM</roID>

       <roSlug>6PM Rundown</roSlug>

       <roChannel></roChannel>

       <roEdStart>2009-07-09T18:00:00</roEdStart>

       <roEdDur>00:30:00</roEdDur>

       <roTrigger>MANUAL</roTrigger>

       <mosExternalMetadata>

         <mosScope>PLAYLIST</mosScope>

         <mosSchema>http://ncsA4.com/mos/supported_schemas/NCSAXML2.08</mosSchema>

         <mosPayload>

            <Owner>SHOLMES</Owner>

            <mediaTime>0</mediaTime>

            <TextTime>350</TextTime>

            <ModBy>BSMITH</ModBy>

            <Approved>1</Approved>

            <Creator>SHOLMES</Creator>

         </mosPayload>

      </mosExternalMetadata>

      </ro>

   </roListAll>

</mos>


3.5.5 roStat - Status of a MOS Running Order

Purpose

The roStat provides a method for the MOS to update the NCS on the status of a Play List.  This allows the NCS to reflect the status of the Play List in the NCS Running Order Display.

Response

roAck

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
roStat

       roID
      
status
      
time

Syntax

<!ELEMENT roStat (roID, status, time)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>27</messageID>

   <roStat>

<roID>5PM</roID>

      <status>MANUAL CTRL</status>

      <time>2009-04-11T14:22:07</time>

   </roStat>

</mos>

 


3.5.6 roReadyToAir - Identify a Running Order as Ready to Air

Purpose

The roReadyToAir message allows the NCS to signal the MOS that a Running Order has been editorially approved ready for air.

Response

roAck

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
roReadyToAir

       roID
      
roAir

Syntax

<!ELEMENT roReadyToAir (roID, roAir)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>30467</messageID>

   <roReadyToAir>

<roID>5PM</roID>

      <roAir>READY</roAir>

   </roReadyToAir>

</mos>

 


3.6 ro Story and Item Sequence Modification

3.6.1 roStoryAppend - Append Stories to Running Order

Purpose

The roStoryAppend message appends stories and all of their defined items at the end of a running order.

 

Note:  The NCS should use the equivalent roElementAction message to achieve the same result.

Response

roAck

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
roStoryAppend

       roID
      
story+
        
storyID
        
storySlug?

         storyNum?

         mosExternalMetadata*
        
item*
           
itemID
           
itemSlug?
           
objID
            mosID

            mosAbstract?

 objPaths?

      objPath*

      objProxyPath*
           
itemChannel?
           
itemEdStart?
           
itemEdDur?

            itemUserTimingDur?
           
itemTrigger?
           
macroIn?
           
macroOut?

            mosExternalMetadata*


Syntax

<!ELEMENT roStoryAppend (roID, story+)>
<!ELEMENT story (storyID, storySlug?, storyNum?, mosExternalMetadata*, item*)>
<!ELEMENT item (itemID, itemSlug?, objID, mosID, mosAbstract?, objPaths?, itemChannel?, itemEdStart?, itemEdDur?, itemUserTimingDur?, itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>12055</messageID>

   <roStoryAppend>

<roID>5PM</roID>

      <story>

         <storyID>V: BRIDGE COLLAPSE</storyID>

         <storySlug>Bridge Collapse</storySlug>

         <storyNum>B7</storyNum>

         <item>

            <itemID>30848</itemID>

            <objID>M000627</objID>

            <mosID>testmos.enps.com</mosID>

<objPaths>

<objPath techDescription="MPEG2 Video">\\server\media\clip392028cd2320s0d.mxf</objPath>

<objProxyPath techDescription="WM9 750Kbps">http://server/proxy/clipe.wmv</objProxyPath>

</objPaths>

 

            <itemEdStart>0</itemEdStart>

            <itemEdDur>815</itemEdDur>

            <itemUserTimingDur>310</itemUserTimingDur>

            <macroIn>c01/l04/dve07</macroIn>

            <macroOut>r00</macroOut>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

               <mosPayload>

                  <Owner>SHOLMES</Owner>

                  <transitionMode>2</transitionMode>

                  <transitionPoint>463</transitionPoint>

                  <source>a</source>

                  <destination>b</destination>

               </mosPayload>

            </mosExternalMetadata>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSBXML2.08</mosSchema>

               <mosPayload>

                  <rate>52</rate>

                  <background>2</background>

                  <overlay>463</overlay>

               </mosPayload>

            </mosExternalMetadata>

         </item>

         <item>

            <itemID>30849</itemID>

            <objID>M000628</objID>

            <mosID>testmos</mosID>

            <itemEdStart>0</itemEdStart>

            <itemEdDur>815</itemEdDur>

            <itemUserTimingDur>310</itemUserTimingDur>

            <macroIn>c01/l04/dve07</macroIn>

            <macroOut>r00</macroOut>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

               <mosPayload>

                  <Owner>SHOLMES</Owner>

                  <transitionMode>2</transitionMode>

                  <transitionPoint>463</transitionPoint>

                  <source>a</source>

                  <destination>b</destination>

               </mosPayload>

            </mosExternalMetadata>

         </item>

      </story>

   </roStoryAppend>

</mos>

 


3.6.2 roStoryInsert - Insert Stories in Running Order

Purpose

This message inserts stories and all of their defined items before the referenced story in a Running Order..

Note:  The NCS should use the equivalent <roElementAction> message to achieve the same result.

Response

roAck

Port

MOS Upper Port (10541) - Running Order

Structural Outline

mos
   
mosID
   
ncsID
   
messageID
   
roStoryInsert

       roID

       storyID
      
story+
        
storyID
        
storySlug?

         storyNum?

         mosExternalMetadata*
        
item*
           
itemID
           
itemSlug?
           
objID
            mosID

            mosAbstract?

            objPaths?

       objPath*

       objProxyPath*
           
itemChannel?
           
itemEdStart?
           
itemEdDur?

            itemUserTimingDur?
           
itemTrigger?
           
macroIn?
           
macroOut?

            mosExternalMetadata*

Syntax

<!ELEMENT roStoryInsert (roID, storyID, story+)>
<!ELEMENT story (storyID, storySlug?, storyNum?, mosExternalMetadata*, item*)>
<!ELEMENT item (itemID, itemSlug?, objID, mosID, mosAbstract?, objPaths?, itemChannel?, itemEdStart?, itemEdDur?, itemUserTimingDur?, itemTrigger?, macroIn?, macroOut?, mosExternalMetadata*)>

Example

<mos>

   <mosID>aircache.newscenter.com</mosID>

   <ncsID>ncs.newscenter.com</ncsID>

   <messageID>2000340</messageID>

   <roStoryInsert>

<roID>5PM</roID>

      <storyID>HOTEL FIRE</storyID>

      <story>

         <storyID>V: BRIDGE COLLAPSE</storyID>

         <storySlug>Bridge Collapse</storySlug>

         <storyNum>B7</storyNum>

         <item>

            <itemID>30848</itemID>

            <objID>M000627</objID>

            <mosID>testmos.enps.com</mosID>

<objPaths>

<objPath techDescription="MPEG2 Video">\\server\media\clip392028cd2320s0d.mxf</objPath>

<objProxyPath techDescription="WM9 750Kbps">http://server/proxy/clipe.wmv</objProxyPath>

</objPaths>

 

            <itemEdStart>0</itemEdStart>

            <itemEdDur>815</itemEdDur>
            <itemUserTimingDur>310</itemUserTimingDur>

            <macroIn>c01/l04/dve07</macroIn>

            <macroOut>r00</macroOut>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

               <mosPayload>

                  <Owner>SHOLMES</Owner>

                  <transitionMode>2</transitionMode>

                  <transitionPoint>463</transitionPoint>

                  <source>a</source>

                  <destination>b</destination>

               </mosPayload>

            </mosExternalMetadata>

            <mosExternalMetadata>

               <mosScope>PLAYLIST</mosScope>

               <mosSchema>http://MOSA4.com/mos/supported_schemas/MOSBXML2.08</mosSchema>

               <mosPayload>

                  <rate>52</rate>

                  <background>2</background>

                  <overlay>463</overlay>

               </mosPayload>

            </mosExternalMetadata>

         </item>

         <item>

            <itemID>30849</itemID>

            <objID>M000628</objID>

            <mosID>testmos</mosID>

            <itemEdStart>0</itemEdStart>

            <itemEdDur>815</itemEdDur>
            <itemUserTimingDur>310</itemUserTimingDur>

            <macroIn>c0