iTX

XM L Sch edule Impo rt

Protocol Document

AUTHOR: Philip Cooper

SOFTWARE VERSION: 2.4+ and 4.x
DOCUMENT REVISION: 1.10
REVISION DATE: 20 August 2015

th
27 January 2015 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION Page 1 of 39
© 2003–15 GRASS VALLEY All rights reserved
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

CHANGE HISTORY
Version Date Revised By Reason for Change
th
1.0 13 Oct 2011 Philip Cooper Initial version

th Updated to include Generic Secondary events (#15780) and Master Control

1.1 24 Sept 2012 Rich Haworth
events

th Mark the Generic Secondary type ChannelGFX as deprecated (on Stu’s

1.2 12 Mar 2013 Rich Haworth
instruction)
th
1.3 4 Jun 2013 Rich Haworth Updated to include Generic Live events (#18469)

th
1.4 13 Aug 2013 Rich Haworth DVE events can now be specified as XG events or non-XG events (#19665)

th
1.5 29 Jan 2014 Rich Haworth Voice over events (TXAudioEvents) now contain AudioGroups (#19067)

th
1.6 30 Apr 2014 John Yang ALCRequired Boolean flag on XmlMediaEvent (ITX4-69)

st Updated list of Summary elements, and added the new EPG properties used
1.7 1 May 2014 Rich Haworth
by Schedule Data Mining (ITX4-98)

th Advice on using Generic Secondary events rather than scheduling CGs,

1.8 5 Dec 2014 Rich Haworth
Logos, VertigoXG events directly
th
1.9 27 Jan 2015 David Ball Rebranded from Miranda to Grass Valley

Added HoldFX to table of MediaEvent properties. Removed comment saying

1.10 29th Jan 2015 Rich Haworth
that you can specify a Pinpoint pre-filter in channel config.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 2 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

TABLE OF CONTENTS

1. INTRODUCTION ................................................................................................................................................ 5
1.1. SCOPE ................................................................................................................................................................5
1.2. ABBREVIATIONS ....................................................................................................................................................5
1.3. OVERVIEW ..........................................................................................................................................................5
1.4. DEVELOPMENT SUPPORT.........................................................................................................................................5
1.5. ENCODING ..........................................................................................................................................................6
1.6. TIMEZONE ...........................................................................................................................................................6
2. BASIC REQUIREMENTS AND HANDLING .......................................................................................................... 7
2.1. SCHEDULE FILES ....................................................................................................................................................7
2.2. GENERAL STRUCTURE OF A SCHEDULE ......................................................................................................................8
2.2.1 Scheduled Events ...........................................................................................................................................8
2.2.2 Parent to Child Relationships .........................................................................................................................8
2.2.3 Simple Ids .....................................................................................................................................................9
2.2.4 Instance Id...................................................................................................................................................10
3. BASIC SCHEDULING ........................................................................................................................................ 11
3.1. SCHEDULING START TIMES ....................................................................................................................................12
3.1.1 Non-Overlay / Primary Items ......................................................................................................................12
3.1.2 Overlay / Secondary Items .........................................................................................................................14
3.2. SUMMARY ELEMENTS ...........................................................................................................................................15
3.2.1 Name ..........................................................................................................................................................15
3.2.2 Title.............................................................................................................................................................15
3.2.3 Start ...........................................................................................................................................................15
3.2.4 SecondaryOffset .........................................................................................................................................15
3.2.5 FixedEndNextStart ......................................................................................................................................15
3.2.6 Duration ......................................................................................................................................................16
3.2.7 EventType ....................................................................................................................................................16
3.2.8 TimeMode ...................................................................................................................................................16
3.2.9 Manual .......................................................................................................................................................17
3.2.10 UserData ................................................................................................................................................17
3.2.11 Notes ......................................................................................................................................................17
3.2.12 ContentType............................................................................................................................................17
3.2.13 OutputSubChannel ..................................................................................................................................17
3.2.14 AutoDuration ..........................................................................................................................................17
3.2.15 EPGName ...............................................................................................................................................17
3.2.16 EPGPart ..................................................................................................................................................17
3.2.17 EPGStart.................................................................................................................................................17
4. DETAILED SCHEDULING .................................................................................................................................. 18
4.1. DETAILS ELEMENT ................................................................................................................................................18
4.1.1 Polymorphism ..............................................................................................................................................18
4.1.2 Simple Event Types ......................................................................................................................................19
4.1.3 Shared Types ..............................................................................................................................................19
4.2. SCHEDULING IN/OUT POINTS ..............................................................................................................................20
4.3. SCHEDULING TRANSITIONS ...................................................................................................................................20
4.4. EVENT TYPES ......................................................................................................................................................22
4.4.1 Video Clips .................................................................................................................................................22
4.4.2 Live Events...................................................................................................................................................22
4.4.3 CG Events ...................................................................................................................................................22
4.4.4 Logo Events .................................................................................................................................................23

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 3 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

4.4.5 GPI Events ...................................................................................................................................................23

4.4.6 VertigoXG Events ........................................................................................................................................23
4.4.7 VizRT Events ................................................................................................................................................25
4.4.8 Clarity Events ..............................................................................................................................................25
4.4.9 Voice Over Events .......................................................................................................................................25
4.4.10 Schedule Events .......................................................................................................................................26
4.4.11 VCHIP Events ..........................................................................................................................................26
4.4.12 Router Events ..........................................................................................................................................26
4.4.13 Master Control Events .............................................................................................................................26
4.4.14 Generic Secondary Events .......................................................................................................................27
5. APPENDIX A: TYPES ....................................................................................................................................... 29
5.1. TIMESPAN ..........................................................................................................................................................29
5.2. FRAMERATE ........................................................................................................................................................29
5.3. EFFECTSTYPE ......................................................................................................................................................30
5.4. EFFECTDETAILSTYPE.............................................................................................................................................30
5.5. AUDIODETAILSTYPE .............................................................................................................................................31
5.6. PIPDETAILSTYPE .................................................................................................................................................31
5.7. MEDIADETAILSTYPE..............................................................................................................................................31
5.8. OTHER TYPES .....................................................................................................................................................32
6. APPENDIX B: EXAMPLES................................................................................................................................. 33
6.1. CLIP WITH TRANSITION ........................................................................................................................................33
6.2. MULTIPLE OUTPUT CHANNELS ...............................................................................................................................34
6.3. CG ..................................................................................................................................................................34
6.4. LOGO ..............................................................................................................................................................36
6.5. SEQUENCE.........................................................................................................................................................37
6.6. CHAINED OR LOOPING SCHEDULES........................................................................................................................38
6.7. GENERIC SECONDARY EVENT ................................................................................................................................39

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 4 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

1. INTRODUCTION
1.1. SCOPE
This document describes how to create XML schedules for the Grass Valley iTX Automation System. An
understanding of XML and associated tools is assumed.

1.2. ABBREVIATIONS
XML - eXtensible Mark-up Language
XSD - XML Schema Definition
ITXML - XML Schedule Format for iTX
UTF - Universal character set Transformation Format (e.g. UTF-8)
SDK - Software Development Kit

1.3. OVERVIEW
iTX supports a number of other manufacturer protocols but where possible encourages the use of the standard
protocol detailed in this document. The Protocol in this document covers the creation of schedules. This document
also contains details of As Run logging which whilst not strictly an ‘Import’ protocol is often part of the interface with
an external traffic system.

iTX also supports a number of legacy protocols. These protocols have evolved out of those used by previous systems
such as Columbus and Colossus but whilst many fields appear the same some may have minor differences due to the
different architecture and scheduling logic of iTX. For information about these legacy protocols, see the document
‘iTX Legacy Import Protocol’.

A single protocol is detailed in this document which is an XML based format. This format was introduced in iTX 2.1
and is the standard schedule format used internally by the iTX system, as well as for schedule import. Schedules may
be created externally using the iTX API and also by using text files with either an ‘itxml’ or ‘xml’ file extension.

Files should always contain well-formed XML. Grass Valley also publishes a schema for the XML format which helps
development of software to generate correctly formatted schedules, and also allows for XML schedules to be
validated. XML that is not well formed or not able to be validated by the schema will not be successfully imported
into iTX.

Files are placed directly into the iTX inbox and will be processed by the iTX Media Watcher. Once files have been
successfully processed by Media Watcher they will be deleted and cannot be retrieved. Files that cannot be correctly
understood by the Media Watcher, e.g. due to protocol syntax errors, will be moved to the configured ‘Rejected’
folder.

Grass Valley reserves the right to alter this protocol at any time without notice.

1.4. DEVELOPMENT SUPPORT

In order to help Traffic system vendors create software that will generate schedules for iTX, Grass Valley publishes a
development kit which includes an XML Schema (xsd) and several simple example schedules. The schema defines
every element and attribute that may be contained within an XML schedule, the data that those elements and
attributes may contain, and the order in which they may appear. The schema may be used to validate XML schedules
for correctness before submission to iTX.

Code may also be generated from the schema that can be directly included within a software project. For instance
Altova XML Spy will generate code from the schema in a variety of languages, or the command line ‘xsd’ tool that
ships with the Microsoft .NET SDK will generate code in C#. Code generated by any of these tools significantly
reduces development time and should guarantee the correctness of the XML created.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 5 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

Since ITXML is the standard format for schedules used in iTX, examples of ITXML can easily be generated by building
a schedule in an offline iTX channel and using the ‘Export to Disk’ function on the iTX Desktop’s Schedule
Management Control to export the schedule to file.

1.5. ENCODING
All ITXML shall be encoded as UTF-8.

1.6. TIMEZONE
Start times for all events in the schedule shall be in the ‘system’ time for the iTX installation. That is, the time zone
before the local time zone or daylight savings offset has been applied.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 6 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

2. BASIC REQUIREMENTS AND HANDLING

2.1. SCHEDULE FILES
A schedule file contains a Schedule document element which contains a list of ScheduledEvent elements.

A schedule may contain any number of items within practical limits.

As a simple guideline, the iTX database is able to process approximately 1000 scheduled events per second.
Therefore a schedule containing 5000 items will take in the region of five seconds to import or export. This should be
considered along with limitations such as connection and application timeouts when deciding how many items to
place in a single schedule.

The name of the schedule is set as an attribute in the Schedule document element. Only if this attribute is not
provided will the name of the file containing the schedule be used to set the schedule name. The file extension may
be either ‘.xml’ or ‘.itxml’. Schedules will always be exported by default with the ‘.itxml’ file extension.

Schedules must be placed into a subfolder of the iTX inbox with a name matching that of a channel which has the
‘Schedule Import’ add-in licensed.

Folders should be created whilst Media Watcher is offline to ensure they are correctly set as permanent folders.
Folders created whilst Media Watcher is active will be deleted once any files contained within them have been
processed.

Upon import the Delivery Manager or Media Watcher applications will delete the original schedule file and the
schedule will be stored in the iTX database. The schedule will appear as an Asset in the iTX system and be searchable
from within PinPoint.

Within the iTX database, the schedule will be ‘shredded’ and an individual record created for each scheduled event.
When the schedule is requested, the schedule is reconstituted into a single block of XML. Although it is possible to
place the scheduled events in any order in the schedule file that is imported (if using the unique schedule event id
feature), when the schedule is exported, a parent event will always be immediately followed by its child events.

Once imported into iTX, schedules can be loaded into any iTX channel.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 7 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

2.2. GENERAL STRUCTURE OF A SCHEDULE

As mentioned in the previous section, a schedule consists of a Schedule document element followed by a sequence
of ScheduledEvent elements. In this section we will drill down further and examine what elements exist inside a
ScheduledEvent element, what their purpose is, and also how parent and child (primary and secondary) relationships
between events are managed.

2.2.1 Scheduled Events

A ScheduledEvent may contain four child elements: Summary, Automation, Details and Extended.

The purpose of these elements is as follows:

• Summary – This is the basic element required by all schedule events. It contains information such as event
name, event type, start time, and duration. Attributes attached to this element manage the parent / child
relationship between scheduled events
• Automation – This is for use by iTX only. It is an area for the TX-Play automation system to store information
that is required to manage backup channels. It is not intended that an imported schedule would ever
contain this element, and as such it is not documented in the schema or any of the examples, nor will it be
mentioned again in this document. Exported schedules, however, may contain this element, in which case it
may be safely ignored by systems external to iTX.
• Details – Information that is specific to the type of the event being scheduled is included in this element. For
basic scheduling, this element is not always required, as we will see later. We will cover the content of the
Details element when we examine each event type.
• Extended – This element is to hold payload information that is not relevant to the scheduling of the event
that it is attached to, but should be included in As Run information. Any large quantities of data should be
placed in this element, as it is the only element not loaded by iTX when the schedule is loaded from the
database. As such the quantity of data in this element does not have an adverse effect on the memory
consumption and performance of the iTX automation system. The format of the XML placed in this element
is not checked by the schema.

2.2.2 Parent to Child Relationships

The default mechanism for identifying scheduled events is to have a GUID identifier for each event. A child
(secondary) event will identify which event is its primary event by also providing the identifier for its parent (primary)
event. The ‘id’ and ‘parentId’ attributes attached to the Summary element are used for this purpose.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 8 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

Schedule import can cope with events placed out of order in the schedule, i.e. child events placed before parent
events, but any schedule exported from the system will be in the order shown above. As such it is recommended that
ITXML is always generated with child events immediately following their parent.

2.2.3 Simple Ids

An alternative to the GUID ids has been provided in the form of simple integer based ids. This is for systems that are
unable to generate GUIDs, or guarantee the uniqueness of them. Systems that are able to create unique GUIDs
should always use the id and parentId attributes, otherwise the simpleId attribute attached to the Summary element
can be used.

Upon schedule import, id and parentId attributes will be generated for the events in the schedule. The simpleId
attribute will be retained (as long as the schedule is not modified within iTX) and will be included with schedules that
are exported from iTX.

The schedule import routine will determine which events are primary and which are secondary by the Time Mode of
the event (this is described in detail in later sections). Secondary events are determined to have any of the following
time-modes; otherwise the event is regarded as being a primary event:
• Start Plus
• Start Minus
• End Plus
• End Minus

There is one other caveat to using simple ids. Child events must always immediately follow their parent event as
there is no way that the out of order feature available for GUID ids can be used. If child events do not immediately
follow their parent (or another child of that parent), there is the possibility of the child attaching to an incorrect
parent.

A final alternative is that no id attributes (id, parentId or simpleId) are attached to the Summary element. Again,
schedule import will create GUID ids for these events, but it is much more difficult for external applications to
identify events in an exported schedule.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 9 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

2.2.4 Instance Id
If an exported schedule is examined you may notice an instanceId attribute on the Summary element. This is used by
iTX to distinguish between events when a schedule is put into the same playlist multiple times. It is not a
requirement that a Traffic System application should ever need to include this element in a schedule.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 10 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

3. BASIC SCHEDULING
Basic scheduling in ITXML is accomplished using only the Summary element of a ScheduledEvent, for example:

This schedule will put the two clips on air back-to-back, with a time mode of ‘Follow’ (or ‘Auto’). In fact, even this
example contains superfluous information. If there was no requirement for a title and it is ok to use the default
duration of the Asset, then the following schedule could be used:

So as can be seen, only the Name and EventType elements are really required to put events on air with all the default
options.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 11 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

3.1. SCHEDULING START TIMES

3.1.1 Non-Overlay / Primary Items

All primary items in an ITXML can include date and time details but the actual date and time the clip plays will
depend on its defined time mode.

The ability to hold the schedule awaiting a manual input from the user (or external trigger) is an additional flag.
Having this as a separate flag allows for items to be scheduled at a fixed time but also require manual triggering.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 12 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

In the above example the first item in the schedule is set to play at a fixed point. The second and third items are set
to ‘Follow’ time mode but with the addition of the manual flag the third item will not play until it has been triggered.
The last item in the schedule is marked as a fixed end item, its in-point will be automatically adjusted (up to its full
duration) and played so that the clip finished at the specified time – this is useful, for example, for clips that count
down to the top of the hour.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 13 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

3.1.2 Overlay / Secondary Items

Secondary items are all scheduled relative to their parent (primary) item. It is therefore not appropriate to include
the SecondaryOffset element in the Summary element. The SecondaryOffset element is used to hold the ‘offset’ time
– the effect of which will depend on the time mode specified.

4 overlay time modes exist:

Parent Item

Start- Start+ End- End+

Time Mode Effect

Start secondary item ‘SecondaryOffset’
Start Plus
after the parent item
End secondary item ‘SecondaryOffset’
End Minus
before the end of the parent item.
Start secondary item ‘SecondaryOffset’
Start Minus
before the parent item.
Start secondary item ‘SecondaryOffset’
End Plus
after the end of the parent item.

Note that ‘End Minus’ is a special case where the start time is automatically adjusted based on the duration of the
item so that it finishes at the specified offset.

It is acceptable to schedule overlay items using ‘Follow’ time mode in which case the secondary item will begin at the
same time as its parent primary item. Care should be taken when using this mode though as the behaviour may not
be what is desired if there are multiple overlay items. Multiple overlay items using ‘Follow’ time mode will play one
after the other, if they are both required to play at the very beginning of the parent primary they should be
scheduled as Start Plus with zero SecondaryOffset.

Clip Clip
VO, Auto VO, Start+ 00:00:00:00
CG, Auto CG, Start+ 00:00:00:00

Clip Clip

VO VO

CG CG

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 14 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

3.2. SUMMARY ELEMENTS

We shall now look at the elements that are children of the Summary element, which should provide an overview of
what is possible with basic scheduling. They are listed here in the same order as they would be expected to be
encountered in the XML schedule.

3.2.1 Name
Name of the Asset if the Event Type is asset based, otherwise simply the name of the event. Asset based events will
use this value to find, check the status of, and cache media in the system prior to play-out. This element is required.

3.2.2 Title
This element simply provides text to give more detail about an event. This text is not processed by iTX, it’s only
purpose is to supply more information to the operator. This element is optional.

3.2.3 Start
There are two options for defining when an event can start: Start, or StartDate and StartTimecode. If the Start
element is used, the format of the date and time follows the standard XML dateTime format, for example:

However if timecodes are to be used to specify the start time, then the separate StartDate and StartTimecode
elements may be used, as follows:

Note that the StartTimecode element also requires that the frame rate of the timecode is specified using the
timecodeFormat attribute. This attribute is a FrameRate type, see Appendix A.

All of these elements are optional.

3.2.4 SecondaryOffset
Intended for secondary events only, the SecondaryOffset element defines the offset from the start or end of the
parent event that the secondary event will start from. This SecondaryOffset is a TimeSpan type, see Appendix A. This
element is optional.

3.2.5 FixedEndNextStart
This element supplies the end time for an event where the Fixed End time mode is specified. As with the Start time,
there are two choices: FixedEndNextStart, or FixedEndNextStartDate and FixedEndNextStartTimecode. Please see
section 3.1.3 for how these two choices work, they are not repeated here since the only difference is the element
names. All of these elements are optional.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 15 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

3.2.6 Duration
The Duration element specifies the duration of the event. If the event type is asset based then this will override the
default duration of the asset. The Duration is a TimeSpan type, see Appendix A. This event is optional, if omitted
either the default duration of the asset will be used or the default duration of the event type.

3.2.7 EventType
The EventType element is an enumeration that specifies what type of event will be created when the iTX automation
system loads the schedule. The element is always required, and may have any of the following values:
• TXMediaEvent - Video clip
• TXAudioEvent - Voice over
• TXGraphicEvent - A full screen graphic
• TXLogoEvent - iTX generated logo
• TXSegmentEvent - Inserts or loads a pre-built sequence
• TXMusicEvent - Music clip
• TXCaptionEvent - iTX generated caption
• TXLiveEvent - Routes a live source
• TXSubtitleEvent - iTX generated subtitle
• TXExternalCaptionEvent - Externally generated caption
• TXGPIEvent - GPI output control
• TXVChipEvent - VCHIP control
• TXDataEvent - Conditional Access
• TXClockEvent - Countdown clock
• TXVANCEvent - VANC control
• TXCommentEvent - Playlist comment
• TXSlideShowEvent - Displays a sequence of slides
• TXSplitBreakEvent - Multi-region split
• TXExternalSubtitleEvent - Externally generated subtitle
• TXClarityEvent - External Clarity generated caption
• TXVertigoXGEvent - External Vertigo generated caption
• TXVizRTEvent - External Viz generated caption
• TXScheduleEvent - Loads a pre-built schedule
• TXStudioEvent - Studio
• NewsStory - MOS protocol news story
• RouterEvent - Router switch
• TXAfterEffectsEvent - After effects
• TXMasterControlEvent - Master Control
• TXGenericSecondaryEvent - Used by schedule import

3.2.8 TimeMode
This element defines the time mode of the event. This element is optional, and if omitted then the Follow time mode
will be used. The element is an enumeration and may have one of the following values:
• Manual - Manual trigger start
• Follow - Follow on (known as Auto within iTX)
• Fixed - Fixed start time
• StartMinus - Secondary event, see 3.1
• StartPlus - Secondary event, see 3.1
• EndMinus - Secondary event, see 3.1
• EndPlus - Secondary event, see 3.1
• FixedEnd - Fixed end time

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 16 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

3.2.9 Manual
This element is simply a Boolean (true / false) value that specifies whether an event should require a manual trigger
in addition to another time mode. This element is optional and the default value is false.

3.2.10 UserData
This element provides a text field into which the Traffic System may insert data that will appear in the As Run log. For
large amounts of data (guideline is anything greater than 128 characters), the Extended element of the
ScheduledEvent should be used. This element is optional.

3.2.11 Notes
This element provides a text field to store notes about the event. The Notes may be added as a column to the iTX
grid for the operator to see. This element is optional.

3.2.12 ContentType
This element provides a text field to store the content type of the event. The Notes may be added as a column to the
iTX grid for the operator to see. This element is optional.

3.2.13 OutputSubChannel
This element controls which output channel this items is going to. This element is optional.

3.2.14 AutoDuration
This element forces the item to track the duration of its parent if it has one. This element is optional.

3.2.15 EPGName
This element is used as the display name in schedule data mining. This element is optional.

3.2.16 EPGPart
This element is used in schedule data mining to tell if a multi-part live or Master Control is the same program. This
element is optional.

3.2.17 EPGStart
This element is used in schedule data mining to tell what the original intended time for an event is. This element is
optional.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 17 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

4. DETAILED SCHEDULING
4.1. DETAILS ELEMENT
For scheduling details of events beyond the functionality provided by the Summary element, the Details element
needs to be used. The content of the Details element varies between event types, and relies on the polymorphism
features available in XML to match schema definitions to event types.

4.1.1 Polymorphism
Here is a sample of a ScheduledEvent containing a Details element with all of the required attributes:

The Details element has two attributes on it:

• xmlns:p2 - Defines the namespace in the schema where the type is stored and assigns it to the
variable ‘p2’
• p2:type - Defines the name of the type stored in the namespace defined by ‘p2’

These attributes allow the content of the Details element to be mapped on to a type found in the schema. In this
example the type is ‘XmlMediaEvent’. The general convention (with some exceptions) is that the type defined in the
Details element uses the ‘Xml’ prefix, which corresponds to the EventType element (section 3.2.7) which uses the
‘TX’ prefix, as follows:

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 18 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

Summary\EventType Details\@p2:type
TXMediaEvent XmlMediaEvent
TXAudioEvent XmlAudioEvent
TXGraphicEvent XmlGraphicEvent
TXLogoEvent XmlLogoEvent
TXSegmentEvent XmlSegmentEvent
TXMusicEvent XmlMusicEvent
TXCaptionEvent XmlCaptionEvent
TXLiveEvent XmlLiveEvent
TXSubtitleEvent XmlSubtitleEvent
TXExternalCaptionEvent XmlExternalCaptionEvent
TXExternalLogoEvent XmlExternalLogoEvent
TXGPIEvent XmlGPIEvent
TXVChipEvent XmlVCHIPEvent
TXDataEvent XmlDataEvent
TXClockEvent XmlClockEvent
TXVANCEvent XmlVancEvent
TXCommentEvent XmlCommentEvent
TXSlideShowEvent XmlSlideShowEvent
TXSplitBreakEvent XmlSplitBreakEvent
TXExternalSubtitleEvent XmlExternalSubtitleEvent
TXClarityEvent XmlClarityEvent
TXVertigoXGEvent XmlVertigoXGEvent
TXVizRTEvent XmlVizRTEvent
TXScheduleEvent XmlScheduleEvent
TXStudioEvent XmlStudioEvent
NewsStory XmlNewsStoryEvent
RouterEvent XmlRouterEvent
TXAfterEffectsEvent XmlAfterEffectsEvent
TXMasterControlEvent XmlMasterControlEvent
TXGenericSecondaryEvent XMLGenericSecondaryEvent

4.1.2 Simple Event Types

Some event types are inherently quite simple and have no purpose for any information to be added to a Details
element. These are:
• TXCommentEvent
• DataEvent
• TXScheduleEvent
• TXClockEvent

4.1.3 Shared Types

Many of the event types used shared schema types to place information in their respective Details elements in a
consistent way. Where types are shared across multiple event types they will be documented in Appendix A,
otherwise they will be documented with the event type that owns them.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 19 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

4.2. SCHEDULING IN/OUT POINTS

When points are specified both the in and out-points should ideally be specified to avoid error. If only the out point is
specified the in-point will be set as 00:00:00:00.

The ‘MediaDetailsType’ (see Appendix A) is used to specify in and out points. All event types that support scheduling
of in and out points will include an element of this type with their Details section.

In this example, a video clip, the Media element is of type MediaDetailsType and is used to set the in and out points:

Note that in order to prevent the points from being overridden upon successful asset load, the value of the
HoldPoints element should be set to true (default is false).

The points may be specified either as an XML time (shown) or as a timecode.

4.3. SCHEDULING TRANSITIONS

Primary events (Video Clip, Live Event, Stills) can all have their IN transition scheduled via ITXML (the OUT transition
is determined by the IN transition of the next event).

By default the transmission mode will be loaded from the Video Clip asset or default to ‘Cut’. If it is defined in the
OSC item record it is important to add the line ‘hold_fx’ in order for the parameters to be used.

Cut

Mix

CutCut

CutFade

FadeCut

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 20 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

FadeFade

The effect type and duration are part of the ‘EffectDetailsType’ (see Appendix A). In this example a 30 second Still
(TXGraphicEvent) is used to demonstrate a cut through black (CutCut) transition:

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 21 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

4.4. EVENT TYPES

4.4.1 Video Clips

The XmlMediaEvent type contains the following elements:

Name Type Comments

Effects EffectsType See appendix A
Subtitles SubtitlesType See appendix A
Media MediaDetailsExType Extends MediaDetailsType (See Appendix A)
ALCRequired Bool Whether Audio Loudness Control needs to be applied to the
media

The MediaDetailsExType extends MediaDetailsType adding the following elements:

Name Type Comments

Stereoscopic xs:boolean
Protection CopyGuardType See appendix A
HoldPoints xs:boolean Prevents in and out points from being overridden by the asset.
HoldFX xs:boolean Prevents transition from being overridden by the asset.

4.4.2 Live Events

The XmlLiveEvent contains the following elements:

Name Type Comments

Effects EffectsType See appendix A
LiveRecording Complex Type Records the event to a clip.

Name Type Comments

RecordClip\@enabled xs:boolean Enabled flag
RecordClip xs:string Clip name

Device xs:string ChannelLive, Live, MasterControl or StudioSwitcher.

If set to ‘Live’ then a Live event will be generated. If set to
‘MasterControl’ then a MasterControl event will be generated.
If set to ‘StudioSwitcher’ then a StudioSwitcher event will be
generated. If set to ‘ChannelLive’ then the type of event
generated will depend on what is specified in the channel
config (in the Colossus plugin config).

Note that when Device is set such that a MasterControl or

StudioSwitcher event will be generated, only the Effects
element can be set within XmlLiveEvent (if LiveRecording is set
then it will be ignored).

The GPI, Input and Source elements (in the schema) are all configured using the Live Event Plugin configuration panel
on the Desktop. See iTX System Administration Guide.

4.4.3 CG Events
Note that the simplest way to schedule CG events is by using Generic Secondary events (see section 4.4.14 for full
details).

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 22 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

4.4.4 Logo Events

Note that the simplest way to schedule Logo events is by using Generic Secondary events (see section 4.4.14 for full
details). Below are the details for scheduling them directly.

The XmlLogoEvent contains the following elements:

Name Type Comments

LogoDetails LogoDetailsType See appendix A
Mode xs:string Duration, On, Off, AllOn, AllOff

The LogoDetails may be loaded from the event name (Summary\Name) if the logo is saved as an asset in the system.

4.4.5 GPI Events

An XmlGPIEvent contains the following elements:

Name Type Comments

Matrix xs:string The name of the GPI matrix
OutputID xs:integer The output index of the GPI

4.4.6 VertigoXG Events

Note that the simplest way to schedule VertigoXG events is by using Generic Secondary events (see section 4.4.14 for
full details). Below are the details for scheduling them directly.

The XmlVertigoXGEvent contains the following elements:

Name Type Comments

Template xs:string The full name of the template required on-air.
Mode xs:string Defines if the caption is duration based or a trigger, defaults to
Duration if not present. Value is Duration or Trigger (case
sensitive).
DSKLayer xs:integer Defines which one of the virtual layers to use on the VertigoXG,
defaults to Layer 1 if not present.
Options xs:anyType Further XML tags required to specific fields to be populated in
the template. This could be fixed text values or values derived
from macros.

An example of the XML required in the Options element is as follows:

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 23 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

4.4.6.1. Template Fields

A repeating list of field names and field values which are used to populate text elements on the recalled template:

4.4.6.2. Simple Macros

A simple macro system allows automatic population of text fields with ‘now’ and ‘next’ type information, with data
from the locally loaded schedule. The macros can be used find a clip in the loaded iTX schedule and then use the clips
details to populate text fields on the recalled template. e.g.

The above example populates field 3 on the recalled page with the title of the next primary event in the schedule.
This is a simple way to auto-populate page fields with dynamic information from the currently playing schedule.

Currently the field ‘MacroParameter’ is a numeric value which contains a 0 based offset of the primary item required.

To obtain the title of the current primary item would use:

The Macro entry is actually using reflection on the retrieved schedule item, so any valid property of that item can be
returned and used to populate text fields. Examples of useful item properties include:
Title

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 24 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

Name
Notes
LocalStartTimeStr
LocalEndTimeStr

4.4.7 VizRT Events

An XmlVizRTEvent contains the following elements:

Name Type Comments

Template xs:string The full name of the page required on-air.
Options xs:anyType Further XML tags required to specific fields to be populated in
the template. This could be fixed text values or values derived
from macros.

See VertigoXG Events for information on the content of the Options element.

4.4.8 Clarity Events

Note that the simplest way to schedule Clarity events is by using Generic Secondary events (see section 4.4.14 for full
details). Below are the details for scheduling them directly.

An XmlClarityEvent contains the following elements:

Name Type Comments

TemplatePage xs:integer Page number required on-air.
RenderPage xs:integer Render page number
TextData Name/Value Pairs Array of Name/Value pairs which supplies data to the template.

4.4.9 Voice Over Events

The XmlAudioEvent contains the following elements:

Name Type Comments

Media MediaDetailsType See appendix A.
AudioEffect AudioDetailsType See appendix A.
AudioGroups complex An array of AudioGroup objects. Each AudioGroup object contains:

Name Type Comments

Type AudioType DolbyD, DolbyE or PCM
OutputChannels xs:string Number of decoded
channels
Channels Complex Array of type xs:string.
This reflects the channels to
use from source media

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 25 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

4.4.10 Schedule Events

It is possible to schedule other schedules as individual items. When loaded into a channel the schedule item will be
loaded and expanded when its start time falls within the configured look-ahead period.

The inclusion of schedule items in an ITXML is commonly used for two purposes:
• Nested Schedules: Different sections of the day’s schedule may come from different parties and so separate
schedules may be produced for separate programming blocks or commercial breaks. A master schedule will
hold all the items and each sub-schedule will appear as a daughter of the previous one. Nested schedules
can themselves contain nested schedules but it is important to realise that the top most schedule and all its
daughter items will stay loaded until all items have been played out or have been skipped.
• Auto-loading the next schedule: If the very last item record in an ITXML is a schedule item the schedule will
be appended separate from the rest of the schedule. i.e. it will not be a daughter of the main schedule but
will appear separate (not nested).

All schedule items will take their time mode behaviour from the properties of the first item in the schedule when it is
loaded and expanded. If the schedule asset referred to by the schedule item doesn’t exist, or doesn’t include any
duration information, it will appear with zero duration in the schedule in a live channel until the point that it is
subsequently loaded and expanded and the duration will be updated.

4.4.11 VCHIP Events

The XmlVChipEvent contains the following elements:

Name Type Comments

ID VchipRatingType TPG_None, TPG_TV_Y, TPG_TV_Y7, TPG_TV_G, TPG_TV_PG,
TPG_TV_14, TPG_TV_MA,
MPAA_G, MPAA_PG, MPAA_PG_13, MPAA_R, MPAA_NC_17,
MPAA_X, MPAA_NR,
CE_E, CE_G, CE_8_PLUS, CE_G, CE_PG, CE_14_PLUS,
CE_18_PLUS.
CF_E, CF_G, CF_8_PLUS, CF_13_PLUS, CF_16_PLUS,
CF_18_PLUS
AdvisoryFlags AdvisoryFlagsType TPG_Dialog, TPG_Language, TPG_Sex, TPG_Violence

4.4.12 Router Events

The XmlRouterEvent contains the following elements:

Name Type Comments

SourceID xs:integer Route source
DestinationID xs:integer Route destination
MatrixID xs:integer Router matrix
SourceAlias xs:string Alias for the source
Destination xs:string Alias for the destination
Details xs:string Description

4.4.13 Master Control Events

The XmlMasterControl contains the following elements:

Name Type Comments

Effects EffectsType See appendix A.
IsManualInsert Bool Whether the event was created by the Manual Insert process.
IsRollUnder Bool Whether the event was created by the RollUnder process.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 26 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

4.4.14 Generic Secondary Events

The XmlGenericSecondaryEvent contains the following elements:

Name Type Comments

Device String The type of GenericSecondaryEvent
e.g. CHANNELGPI, CHANNELLOGO, LOGO, CHANNELCG,
CHANNELGFX, VERTIGOXG, CLARITY
Data GenericSecondaryDataType The data specific to the event. This will be of a type that
inherits from GenericSecondaryDataType e.g.
GenericLogoDataType, GenericGraphicsDataType

GenericLogoDataType is defined as follows:

Name Type Comments

Mode LogoModeType Duration, On, Off, AllOn, AllOff
MediaOverride String The name of the asset for media only (not positioning, etc)
Layer string Layer

GenericGraphicsDataType is defined as follows:

Name Type Comments

Layer string Layer
CaptionFields complex A list of either:
FieldID and Text pairs
FieldID and Macro pairs (where a Macro contains a Macro
name and Macro parameter)
InTransition TransitionType Contains the name of the transition and the duration
OutTransition TransitionType Contains the name of the transition and the duration
Note that when scheduling a VertigoXG event this field is used
to specify the Mode. If no OutTransition is present then the
mode is set to Trigger, if an empty OutTransition is present
then the mode it set to Duration.

Generic Secondary events do not require the TX-Play item type to be specified at the point of scheduling. These
items are resolved by TX-Play at run time when the schedule is loaded.

The example itxml in section 6.7 shows a Generic Secondary event where the Device is set to CHANNELLOGO. The
Data element contains data based on the type GenericLogoDataType (i.e. the Mode, MediaOverride and Layer are
specified). The name of the event specified in the Summary data is Logo:0. When this event is loaded by TXPlay the
channel config for the channel on which it is being loaded will be checked. If Logo:0 has been defined in the Colossus
config then the corresponding Logo data will be loaded. If Logo:0 has been configured as an external logo then a
TXExternalLogoEvent will be added to the schedule in place of the Generic Secondary event. If Logo:0 has been
configured as a normal logo then a TXLogoEvent will be added to the schedule in place of the Generic Secondary
event. The Mode, MediaOverride and Layer for the event will be set accordingly.
Note that it is also possible when using the Device type of CHANNELLOGO to create an asset in the system called
Logo:0 (for example). In this situation TXPlay will first check the channel config to see if Logo:0 is configured. If it is
then this data will be used to create the event but if it is not then the asset Logo:0 will be scheduled.

Device Type used in Data element Resulting plugin created

CHANNELGPI (none) TXGPIEvent
CHANNELLOGO GenericLogoDataType TXLogoEvent or TXExternalLogoEvent
(depending on channel config)

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 27 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

LOGO GenericLogoDataType TXLogoEvent

CHANNELCG GenericGraphicsDataType TXCaptionEvent
CHANNELGFX GenericGraphicsDataType TXExternalCaptionEvent
(RT 3D. Deprecated)
VERTIGOXG GenericGraphicsDataType TXVertigoXGEvent
CLARITY GenericGraphicsDataType TXClarityEvent

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 28 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

5. APPENDIX A: TYPES
5.1. TIMESPAN
The TimeSpan type provides information about the difference between two times. This will most commonly be used
to specify the duration of events. The TimeSpan separates the number of days in the time span (default is zero days)
from the specification of time, because the XML time type does not allow for times greater than 24 hours. Also with
timecodes we run into ambiguity with regards to wrap around midnight so this is best avoided.

Using ScheduledEvent Duration as an example, here are the options for specifying a time span:

1) Using a timecode:

2) Using XML time:

In both examples, the number of days is zero so the Days element can safely be omitted. If the event was longer than
24 hours then the Days element would need to be included to define the number of whole days, and the Time or
Timecode elements included to define the remainder.

5.2. FRAMERATE
The FrameRate type is an enumeration representing all of the frame rates supported by iTX and requires that one of
the following values is used:
• FPS24
• FPS25
• FPS30
• FPS50
• FPS60
• FPS24DF
• FPS30DF
• FPS60DF

The ‘DF’ suffix clearly implies that the frame rate is of the Drop Frame type.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 29 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

5.3. EFFECTSTYPE
EffectsType encompasses audio, video and picture in picture effects.

Name Type Comments

Effect EffectDetailsType Video effects
AudioEffect AudioDetailsType Audio effects
PIP PIPDetailsType Picture in picture effects

5.4. EFFECTDETAILSTYPE
Used by several event types, the EffectDetailsType contains all of the information supported by iTX for scheduling
audio and visual effects.

Name Type Comments

AudioSplit Complex type Audio Split information

Name Type Comments

Lag TimeSpanType Time the audio lags the video
Lead TimeSpanType Time the audio leads the video
Split xs:boolean Flags whether to split the
audio and video
Border Complex type Border details

Name Type Comments

Colour xs:integer ARGB colour
Width xs:integer Width in pixels

Effect Complex type The effect

Name Type Comments

Direction xs:string Up, Down, Left, Right
Duration TimeSpanType
or
TransitionRate TransitionRate Slow, Medium or Fast
InDuration TimeSpanType In effect duration
OutDuration TimeSpanType Out effect duration
Delay TimeSpanType Effect delay
Effect xs:string Cut, Mix, FadeFade,
FadeCut, CutFade, CutCut,
Wipe, Slide, Squeeze, Crawl
UseXGInside xs:boolean Flags whether the DVE will
be performed by XG Inside
or not
XGInsideInput XGInsideInputType Determines which input will
be used on the XG.
BlackHold TimeSpanType Black hold duration

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 30 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

5.5. AUDIODETAILSTYPE
The AudioDetailsType contains information about audio.

Name Type Comments

BackgroundLevel xs:integer The background audio level (0 – 100)
Duration TimeSpanType Audio duration
FadeDownDuration TimeSpanType Fade down duration
FadeUpDuration TimeSpanType Fade up duration
InDuration TimeSpanType Audio in duration
OutDuration TimeSpanType Audio out duration
SDIOutputChannel xs:integer Output channel index
Time xs:dateTime

5.6. PIPDETAILSTYPE
The PIPDetails type contains information about picture in picture effects.

Name Type Comments

Background RectangleType Background rectangle
Destination RectangleType Destination rectangle
Duration TimeSpanType PIP duration
File xs:string Picture in picture file
HoldAtEnd xs:boolean Hold at end flag
Smooth xs:boolean Smooth flag
Squeezeback xs:boolean Squeezeback flag

5.7. MEDIADETAILSTYPE
MediaDetailsType contains information about media to be played.

Name Type Comments

ActiveRegion ActiveRegionType Active Region enumeration:

AR_PassThrough, AR_16x9, AR_4x3, AR_14x9_Pillarbox,

AR_4x3_Protect_14x9, AR_16x9_Protect_14x9,
AR_16x9_Protect_4x3
ArcMode ArcModeType Aspect Ratio Conversion enumeration:

ARC_DISABLED, ARC_PB_4x3, ARC_LB_16x9, ARC_LB_14x9,

ARC_PB_14x9, ARC_4x3, ARC_16x9
AudioLevel xs:integer Audio volume level (0 - 100)
AudioPinsToConnect xs:integer SDI Output Channel
Duration TimeSpanType Scheduled duration
InPoint TimeSpanType Scheduled in point
OutPoint TimeSpanType Scheduled out point
OutputChannel xs:integer Output channel index (1 – 8)
PreserveAspectRatio xs:boolean Preserve aspect ratio flag
ReverseFieldOrder xs:boolean Reverse field order flag
SourceFormat SourceFormatType Aspect ratio enumeration:

SF_Unknown, SF_4x3, SF_16x9

TargetRectangle RectangleType Target rectangle for video
UseArcMode xs:boolean Use aspect ratio conversion flag

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 31 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

WideScreen xs:boolean Widescreen flag

Loop xs:boolean Loop flag

5.8. OTHER TYPES

For in depth coverage of all types, please consult the schema.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 32 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

6. APPENDIX B: EXAMPLES
6.1. CLIP WITH TRANSITION
A typical media event with a transition and non-default points would be as follows:

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 33 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

6.2. MULTIPLE OUTPUT CHANNELS

Media may be played on multiple output channels as follows:

6.3. CG
CG events can be described totally by the schedule; however this is a complex undertaking so typically a pre-
configured CG is recalled by name, as follows:

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 34 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 35 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

6.4. LOGO
Here is an example of a primary event with a secondary logo that has a non-default position (optional).

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 36 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

6.5. SEQUENCE
Creating a sequence involves adding a TXSegmentEvent as a primary event to the schedule and adding the content of
the segment, e.g. video clips, as children of that event:

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 37 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

6.6. CHAINED OR LOOPING SCHEDULES

To create a chained or looping schedule, add a TXScheduleEvent as the last primary event in the schedule. For a
looping schedule, the name of the TXScheduleEvent should be the same as the name of the schedule that contains it
(see example). For chained schedules, the schedule name should be the name of the next schedule to be added to
the playlist.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 38 of 39
 GRASS VALLEY CONFIDENTIAL AND PROPRIETARY INFORMATION

6.7. GENERIC SECONDARY EVENT

The following shows a TXGenericSecondaryEvent of type CHANNELLOGO. See section 4.4.14 for full details of how
this would be interpreted by TXPlay.

20 August 2015 iTXML Schedule Import Protocol – Document Revision 1.9 Page 39 of 39