The document accompanying this license and the information contained therein (the Document), whether in a paper or electronic format, is made available to you subject to the terms stated below. By using and/or copying all or part of the Document, you (the licensee) agree that you will comply with the following terms and conditions.

1. You may, on a non-exclusive basis, use the Document only on the condition that you abide by the terms of this license. Subject to this condition and other terms and restrictions contained herein, the Document and the information contained therein may be used (i) to further develop the standards described in the Document for use in relation with the Olympic and Paralympic Games and/or (ii) to develop similar standards for other events than the Olympic and Paralympic Games (both (i) and (ii) are hereinafter designated as the Permitted Use, and works further developing these standards for the Olympic and Paralympic Games or developing similar standards for other events are hereinafter referred to as Derivative Works), and copies of the Document or of Derivative Works may be made and distributed for the purpose of the Permitted Use, PROVIDED THAT the COPYRIGHT and references to the IOC appearing in the Document and the TERMS OF THIS LICENSE are included on ALL such COPIES, and further PROVIDED THAT you do not charge any fee or any other monetary compensation for the distribution of the Document to others. The copyright and other intellectual property rights in the Document remain vested in the IOC and the IOC remains entitled to assert his copyright or other intellectual property rights in the Document against any person or entity who does not comply with the terms of this License.

2. A copy of any Derivative Work shall be provided to the IOC free of charge. Moreover, the IOC is granted a worldwide, perpetual, unrestricted, royalty-free non-exclusive license to use any Derivative Work for the further development of the standards made by or for the IOC in relation to the Olympic and Paralympic Games (these standards and the documents describing them are hereinafter referred to as Further Standards) and to make or have made all kinds of exploitation of the Further Standards, with the right to grant sub-licenses.

3. Except if reproduced in the Document, the use of the name and trademarks of the IOC is strictly prohibited, including, without limitation, for advertising, publicity, or in relation to products or services and their names. Any use of the name or trademarks of the IOC, whether registered or not, shall require the specific written prior permission of the IOC.

4. NO WARRANTY, EXPRESSED OR IMPLIED, IS MADE REGARDING THE ACCURACY, ADEQUACY, COMPLETENESS, RELIABILITY OR USEFULNESS OF ANY INFORMATION CONTAINED IN THE DOCUMENT. The Document and the information contained herein are provided on an "as is" basis. THE IOC DISCLAIMS ALL WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF NON-INFRINGEMENT OF PROPRIETARY RIGHTS, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL THE IOC BE LIABLE TO ANYONE FOR DAMAGES OF ANY KIND ARISING FROM OR RELATING TO YOUR ACQUISITION, USE, DUPLICATION, DISTRIBUTION, OR EXPLOITATION OF THE DOCUMENT OR ANY PORTION THEREOF, INCLUDING BUT NOT LIMITED TO, COMPENSATORY DAMAGES, LOST PROFITS, LOST DATA OR ANY FORM OF SPECIAL, INCIDENTAL, DIRECT, INDIRECT, CONSEQUENTIAL OR PUNITIVE DAMAGES, WHETHER BASED ON BREACH OF CONTRACT OR WARRANTY, TORT OR OTHERWISE. THE IOC FURTHER DISCLAIMS ANY LIABILITY FOR ANY DAMAGE CAUSED WHEN THE DOCUMENT IS USED IN A DERIVATIVE WORK. The IOC further disclaims any liability regarding the existence or inexistence of any intellectual property or other rights that might be claimed by third parties with respect to the implementation or use of the technology or information described in the Document.

The same conditions as those described in this Section shall apply mutatis mutandis to the license granted to the IOC on the Derivative Works in Section 2 above.

5. This License is perpetual subject to your conformance to its terms and conditions. The IOC may terminate this License immediately upon your breach of any of its terms and, upon such termination you will cease all use, duplication, distribution, and/or exploitation in any manner of the Document.

6. This License is governed by the laws of Switzerland. You agree that any disputes arising from or relating to this License will be resolved in the courts of Lausanne, Switzerland.

IF YOU DO NOT AGREE TO THESE TERMS YOU MUST CEASE ALL USE OF THE DOCUMENT NOW.

Table of Contents

1 Introduction 6

1.1.. About ODF. 6

1.2.. Development of ODF. 6

1.3.. Scope. 7

1.4.. Objective. 7

1.5.. Main Audience. 7

1.6.. Project Governance. 7

1.7.. Background. 7

1.8.. What ODF isn’t 8

1.9.. Change Management 8

1.10 Programme of the Olympic Games (excerpt from the Olympic Charter) 8

1.11 Glossary. 9

1.12 Documentation. 10

1.13 Language and Translation. 10

2 Understanding Sports Competitions 11

2.1.. Understanding Competitions. 11

2.2.. Messages and Data available. 13

3 Message Definition 14

3.1.. Introduction. 14

3.2.. Encoding. 14

3.3.. ODF Message Structure. 15

3.4.. ODF Data Types and Formats. 22

4 Message Operation and Use 27

4.1.. Message generation systems. 27

4.2.. Competition Day, Start and Stop Transmission. 27

4.3.. Message Invalidation. 28

4.4.. Message Frequency and Triggers. 28

5 Key Data Messages 29

5.1.. Participants. 29

5.2.. Teams. 30

5.3.. Horses. 30

5.4.. Schedule. 31

5.5.. Configuration. 32

5.6.. Results. 32

5.7.. Phase Results. 32

5.8.. Cumulative Results. 33

5.9.. Pools. 33

5.10 Brackets. 33

5.11 Event Ranking. 34

5.12 Medals. 34

5.13 Statistics. 34

5.14 Play by Play. 34

5.15 Current Data. 35

5.16 Official Communications. 35

6 Principles Used 36

6.1.. Codes. 36

6.2.. RSC Level 36

6.3.. ExtendedInfos. 36

6.4.. Competitor unique identifiers. 37

6.5.. Participant Names. 37

6.6.. Mandatory and Optional Elements/Attributes. 38

6.7.. Empty values and updates. 38

6.8.. Ordering and Timing of messages. 39

6.9.. Sorting within Messages. 39

6.10 Which messages to process?. 40

6.11 Message Source in the Header 40

6.12 Use of an Explanatory Information Element 41

6.13 Results Status. 41

6.14 Extensions. 42

6.15 Cumulative Messages, not all athletes progress. 45

6.16 Positive and Negative Tags. 45

6.17 Single athlete competing multiple times. 45

6.18 Teams of Teams. 45

6.19 ODF Message Overwrite. 46

6.20 Guides, Pilots and Directors in the Paralympic Games. 47

7 Message Transmission 48

7.1.. Options for Transmission. 48

7.2.. Online HTTP Message Transmission. 48

7.3.. Backup and Recovery. 50

7.4.. Alternate Transmission Methods. 52

8 Sequence of Messages 53

9 Appendices 54

9.1.. Schedule and Results Status. 54

9.2.. Information for providers wanting to extend ODF. 60

10 Document Control 67

10.1 File Reference. 67

10.2 Version History. 67

10.3 Change Log. 67

1 Introduction

1.1 About ODF

The Olympic Data Feed (“ODF”) is a unique set of messages which can be delivered in real time or point-in-time and containing point in time, live or archive sports related data, including Schedules, Biographies, Start Lists, Results, Statistics, Records, Medallists, Historical Results, Weather Data, etc. as further described in this document.

ODF is used for exchanging such data between Results and IT Providers, Organising Committees, and without limitation other users including the International Sports Federations, National Olympic Committees, media organisations (Broadcasters, News Agencies, Newspapers, etc.) and Sports Website Providers.

The ODF specifications define a generic format to represent the results of sport competitions. ODF uses a generic structure to provide a common data format for any sport or competition whilst including the ability to include sport-specific extensions.

ODF is intended as a standard interface valid for all sports and all ODF users. ODF standardises all data provided to users during sporting events by defining data structures that are the ODF messages. The ODF describes the following:

· messages that are not sport dependent (e.g. weather)

· sport messages shared between all the sports (e.g. schedules)

· sport messages that follow general rules for all sports, but that need to be extended to incorporate sport-specific requirements (e.g. results)

The ODF data layer is designed to be independent of the transport mechanism as well as the way the content could be rendered on various platforms (web sites, mobile applications etc.).

1.2 Development of ODF

During the 1990s a standard was developed for providing Olympic results data to news agencies. This was a text based solution distributed over serial lines known as the WNPA Feed. From early 2000s a further series of interfaces was created at the Olympic Games for exchanging data between central and local (venue) based results systems using XML. While this new XML based system was provided to external users for their own use, the multiplication of feeds was becoming difficult to produce, test and monitor.

In 2007 the IOC began working with its technology partners to develop an XML based messaging system to replace the previous WNPA and internal XML systems with a single XML interface solution which took into consideration the needs of all users.

This system was introduced at the 2010 Winter Games in Vancouver as it replaced the WNPA Feed and was also tested internally in two sports as a replacement for the internal messaging system. The London Games in 2012 saw the full introduction of ODF for both internal and external messaging systems and was the sole solution for external data users.

After the experience of 2012 the IOC began working on an enhanced version, ODF2, due for introduction at the 2016 Games.

1.3 Scope

All ODF documentation follows the general messages and rules established in this document, including summer and winter sports for the:

· Olympic Games;

· Youth Olympic Games;

· Paralympic Games.

For other sports competitions the competition owner follows these Foundation Principles as well as the General Messages documents though may provide its own sport specific documentation and codes covering specific requirements.

1.4 Objective

The objective of the document is to describe the ODF technical standards which are built according to the following design principles:

· Sport independent: generic across sports with the aim to use the definitions between sports whenever possible;

· Consistent: data structures are consistent for a wide range of sports and systems;

· Adaptable to future evolutions since the ODF design is based on XML extensions to manage all situations;

· Scalable in terms of:

o Number of messages

o Granularity (number of intermediates results or intermediate points…)

· Data oriented: the ODF data structures are independent from any presentation layer ODF users need to implement; and

· Simple: easy to process and render as desired.

1.5 Main Audience

The main audience of this document is:

· Information Technology suppliers of the systems generating and/or distributing ODF messages (e.g. Timing & Scoring / Results Application Providers);

· Sport data consumers, including Press Agencies, Broadcasters, Sports Federations, National Olympic Committees, Major Sports Event Organisers and others; and

· Technology Results Integrators

1.6 Project Governance

ODF is in constant development and managed by a small group of organisations facilitated by the IOC to ensure it is always up-to-date and adapting to meet the needs of its target audience.

The ODF documentation is maintained by the IOC.

1.7 Background

Results management is a quite complex environment, as it involves a significant number of sport disciplines, including numerous sport events, each with varied competition formats and rules, and specific sport presentation requirements.

Many sport organisers are faced with a “visibility challenge” when news and results of their events are not always picked-up by media organisations.

In certain cases, this is due to the profile of the event itself or the countless number of events scheduled simultaneously among which media organisations need to select the most relevant ones for their audience.

In some other cases, it is simply because these organisers do not have an easy way to distribute to the media the information which could give their event better visibility.

In the area of results management and distribution, there are also numerous IT companies that provide their services to sport organisers. These companies range from very small (one person providing services to local clubs) to very large (multinationals providing services to major events worldwide including the Olympic Games). The level of sophistication of the services provided varies from one end of the spectrum to the other.

The purpose of ODF is to provide to the whole sport results ecosystem (organisers, IT providers, and media) a way to streamline the distribution of sport related information among the different stakeholders. It is our hope and objective that a broad use of ODF will make results distribution as easy as plug-and-play.

1.8 What ODF isn’t

ODF is not intended to display or print results in itself nor is it to manage all aspects of a competition, it is a data feed of the competition information only. Nor is ODF a repository of results data from past competitions.

1.9 Change Management

For the Olympic Games and the Paralympics, the IOC manages the constant ODF evolution under strict change control.

The IOC encourages all ODF users to report issues and provide feedback on potential areas for improvement. All suggestions will be analysed with due care and implemented globally as appropriate. When certain suggestions cannot be implemented because of their too-specific nature, it will always be possible to implement them for individual use through the use of XML extensions.

All feedback should be provided using the ODF contact details available on the documentation site.

1.10Programme of the Olympic Games (excerpt from the Olympic Charter)

The Programme of the Olympic Games is the programme of all competitions of the Olympic Games established for each edition of the Olympic Games by the IOC.

The components of the programme are sports, disciplines and events.

The sports are those sports governed by the IFs.

A discipline is a branch of a sport comprising one or several events.

An event is a competition in a sport or in one of its disciplines, resulting in a ranking and giving rise to the award of medals and diplomas.

1.11Glossary

The following abbreviations are used in this document

Acronym	Description
CC @CodeEntity	This is a reference to a code set, where CodeEntity is the name of the entity that identifies a particular set of codes, for example CC @Discipline is the discipline code set.
Competition	An overall sporting meeting including one or more sports. For example the 2016 Olympic Games.
IF	International Federation, the international governing body of a sport
IDS	Info Diffusion System, central technology system which manages many disciplines.
IOC	International Olympic Committee
IPC	International Paralympic Committee
IRM	Invalid Results Mark, which is a generic term used to describe results such as, without limitation: DNS: Did Not Start DNF: Did Not Finish DSQ: DiSQualified The list of IRMs is sport discipline specific.
NOC	National Olympic Committee recognized as such by the IOC
NPC	National Paralympic Committee as recognized by the IPC
ODF	Olympic Data Feed
ONS	Olympic News Service
ORIS	Olympic Results and Information Services
OVR	On-Venue Results system
RSC	Results System Codes, identify uniquely one unit of any competition, specifying the discipline, gender, event, phase and unit.
Gender	Gender has two meanings, gender of a person (man/women) or gender of an event (for men, women, mixed, any)
Phase	A group of units at the same level in an event, for example heats in Swimming, pool matches in Basketball or quarterfinals in tennis.
Unit	An individual part of an event, for example a single heat in Swimming, a match in Tennis or a bout in Boxing.
WNPA	World News Press Agencies

1.12Documentation

The following documentation is available for ODF. The documents are listed in order in which they should be read:

Document Title	Document Reference	Document Description
ODF Foundation Principles	This document	This document lays the foundation for creating and using ODF.
ODF General Messages Interface Document	ODF/INT401	This document describes the ODF messages
ODF Data Dictionaries (One per discipline)	ODF/INTXXX	This document details and extends the ODF messages described in ODF/INT184 for each sport
ODF Language Guidelines and Participant Names	ODF/INT403	This documents details the policies related to participant names.
ODF Codes Document	ODF/COD404	This document describes the ODF codes used across the ODF documents
ODF Schema	ODF/SCH	The ODF schema is the tool that helps with the syntactical message validation when developing or testing ODF messages.
ODF samples	ODF samples	The ODF samples are a collection of sport messages.

Some of these documents may vary from competition to competition.

1.13Language and Translation

The majority of information related to sports competitions and results is language independent, that is, it deals with participants and numbers (participant names in different languages are managed in a different way, see ODF Language Guidelines and Participant Names [ODF/INT403]).

The default language for all ODF messages is English.

When multiple languages are used:

· The ‘Language Code’ in the header indicates the language in which the ODF message is written;

· Textual information within the body of the message is written in the language indicated by the language code.

When only English is used:

· The ‘Language’ Code may not be included in the header. Where there is no language code then English is assumed.

For the results messages most sports terms (like event names, functions) are fixed so automatic translation is possible and provided in the codes for supported languages as applicable.

Some terms may appear to be non-English but these are usually sport specific as in Judo or Taekwondo.

2 Understanding Sports Competitions

2.1 Understanding Competitions

To manage data distribution for sports competitions each competition is broken down into its component parts so that is easier to manage and understand.

Usually the component parts of an event are a series of competition units which each have a “winner”, and by various means, progress to find an overall winner. In some cases there may be only one “unit” like in a marathon.

Although sports are very different from one another, ODF users who deal with multiple and diverse sports will gain in efficiency by using common terms and data structures.

The following explains how sport competition results are broken down for the purposes of ODF and the distribution of data.

2.1.1 Basic Competition Hierarchy

From the data point of view a sport competition is a set of data container units. These units are intended to store the information of each sport activity (in general an activity done by a group of athletes in a field of play during a certain period of time leading to a classification / winners).

An event is a group of units that lead to a medal set (gold, silver and bronze). Usually the units are sub-grouped into phases that determine the progress within the event.

Each gender (male, female, mixed or open) has a set of events. A discipline is composed by a set of events of each of its genders; a sport is a set of disciplines. See the representation below.

The basic competition hierarchy is seen here with a series of examples (there are of course many others with different formats, this only shows some common examples):

Level	Team Sports	Timed and Judged Sports	Head to Head
Sport	Football / Ice Hockey	Aquatics / Skiing	Tennis
Discipline	Football / Ice Hockey	Swimming / Alpine Skiing	Tennis
Gender	Men	Women	Women
Event	Men’s Tournament	200m Freestyle	Women’s Singles
Phase	Quarterfinals	Heats	Semifinals
Unit	Quarterfinal 1	Heat 5	Semifinal 2

Notes:

· There are sports that have only one discipline (e.g. Basketball)

· There are disciplines that have only one gender (e.g. Synch Swimming)

· There are events that have only one unit (e.g. Men’s Marathon)

· Normally there is a one to one correspondence between the physical sport activity units and its corresponding data containers, but there are some special cases where a physical sport activity produces data for more than one data container (e.g. in artistic gymnastic an athlete participation may produce score for the apparatus and for the all-around).

2.2 Messages and Data available

The ODF messages are data messages and may include encapsulated images, PDFs etc.

To meet the needs of managing a competition and distributing the associated competition information, the following messages are defined in ODF:

· Control Messages (not managing data, only controlling the feed)

· News and informational messages

· Biographies

o Athletes

o Coaches

o …

· Records

· Weather

· Participant Lists

· Schedules

· Results

o Units

o Phases

o PDF

· Extended Results

o Results Analysis

o Current Information

o Images

o Records

o Statistics

o Play-by-Play

· Medal information

o By Event

o By Sport

o …

This list is not exhaustive but simply illustrates the possible information types that may be available at certain sports competitions. Each sports competition organiser must determine what is appropriate, with ‘unit results’ being the most fundamental. The related documents (see section 1.12) provide the details for the Olympic Games and may be adapted for other competitions.

3 Message Definition

3.1 Introduction

The objective of this section is to present the general XML structure of the ODF Messages based on which each ODF Sport Data Dictionary is further developed.

Some important considerations for the ODF messages:

· ODF messages are generally full messages and as such replace the previous version of the same message (same unit etc.).

o There are some other messages which only update part of the information from previous messages, for example _UPDATE (Schedule and Participants) and the DT_RECORD message depending on the header values.

o The DT_CURRENT message is different again and is a stand-alone message which provides information on the current situation in a unit or event.

· Mandatory attributes must always be sent. If they do not have any value then they must be sent empty (Attribute =”“)

· Known optional attributes must always be sent (e.g. Place of Birth) unless in special circumstances.

· Empty optional attributes must be sent either empty (Attribute = ““) or not sent. However to reduce implementation variations and message size it is expected that empty optional elements are not sent. It is expected that ODF clients will be able to process messages either way without any restriction.

· In addition to not sending optional empty values (="") the messages also should not contain zeros unless they zeros have meaning. For example, at the start of a match in a team sport the scores are sent as ="0" as is the first period score. However the statistics for all players are not sent unless there is valid statistic data captured as zero has meaning and this just increases the size of messages without adding information. Some data should be sent as zero when it has meaning (like if a player misses a shot after taking a shot (1 shot, 0 made). The same rule applies for percentages. The same principle applies in other messages like pool standings, do not send all zeros if a team has not played. These are general principles and may be overridden by specific rules in specific sports.

· ODF messages contain elements further refined by one or more attributes used to provide additional information about the element. A one-attribute element could for instance be Code for a Competitor element; a multiple-attribute element could for instance add the name of the competitor.

· Elements must be listed in the order stated in the corresponding ODF message definition. The XML structure should be defined according to a schema (XSD) to ensure full conformance to XML (not more, not less). Any order or other constraints is represented in the schema to ensure a maximum of automatic validation. A schema reference containing all those constraints is provided concurrently with the dictionary.

· The order of attributes is not important.

· ODF is designed in such way that elements and attributes are organized to minimize redundancy and dependency. However, to reduce re-processing data and simplify its rendering, information may be repeated in different messages.

3.2 Encoding

The character set to be used in all information exchange is the standard Unicode UTF-8 which is declared in each message.

<?xml version="1.0" encoding="utf-8"?>

3.3 ODF Message Structure

The ODF General Messages Interface Document defines the structure of the ODF messages in details.

ODF messages are data structures based on standard XML:

<?xml version="1.0" encoding="UTF-8"?>     ODF Declaration
<OdfBody DocumentType=… DocumentCode=… > ODF Header
   <Competition …                             )Message Body
   [body]                                   )
</OdfBody>

3.3.1 ODF Declaration

The start of an ODF message is the XML declaration. It defines the XML version and the encoding used, UTF-8.

3.3.2 ODF Header

The ODF header is the root element of the message and it always has the element name OdfBody.

Header attributes identify ODF messages uniquely and provide standard information about each message. The header can be used to easily apply filtering of messages.

The message unique identifier is the aggregation of the following attributes:

· CompetitionCode

· DocumentCode

· DocumentSubcode

· DocumentType

· DocumentSubtype

· Source

· Version

The following table describes the ODF header attributes. “M” indicates mandatory attributes that must appear in all ODF messages. “O” indicates optional attributes. Optional attributes may be required depending on other attributes in the header.

Attribute	M/O	Value	Comment
CompetitionCode	M	CC @Competition [max. char(15)]	Unique ID for competition
DocumentCode	M	S(34)	DocumentCode can have different values depending on the nature of the message. RSC is used for Results messages and is structured to include the discipline, discipline gender, event phase and unit. The other possible values include (depending on the message) the ID of an athlete (for biographies), sequential numbers (for background imports) etc. Full details are documented in the ODF General Data Dictionary.
DocumentSubcode	O	S(34)	Extension for the DocumentCode Used when the RSC is not sufficient to uniquely identify the content of the XML message.
DocumentType	M	S(30)	Message Type (e.g. DT_RESULT)
DocumentSubtype	O	S(20)	Attribute used to extend DocumentType for some messages.
Version	M	1..V	Version of the message, sequential number with the highest indicating the most recent version. Increments when the unique identifier fields without version are the same. (Positive integer)
ResultStatus	O	CC @ResultStatus	Defines the status of the result included in the message.
Language	O	CC @Language	Language used for message content. If the message is distributed in multiple languages then this attribute should always be included. Where a message is not defined in multiple languages, this attribute must not be included. In this case of a single language then the language of the message is English.
FeedFlag	M	“P”-Production “T”-Test	Test message or production message.
Date	M	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	M	Time	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	M	Date	Logical Date of events. This is the same as the physical day except when the unit or message transmission extends after midnight. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the message will all be dated Aug 2). The end of the logical day is defined by default at 03:00 a.m. For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the day of the correction. Logical Date is expressed in the local time zone where the message was produced.
Source	O	CC @Source	Code indicating the system which generated the message.

Sample

<?xml version="1.0" encoding="utf-8"?>
<OdfBody CompetitionCode="OG2020" DocumentCode="ATHM100M--------------FNL-0001----" DocumentType="DT_RESULT" Version="3" ResultStatus="OFFICIAL" FeedFlag="P" Date="2012-08-03" Time="162843056" LogicalDate="2012-08-03" Source="ATHOLY1" >
……

3.3.3 Message Body

The message body of ODF messages follows the ODF Header.

<?xml version="1.0" encoding="UTF-8"?>     Declaration
<OdfBody DocumentType=… >                 ODF Header
   <Competition>                            Message Body
     …
   </Competition>
<Note> Athlete nnnn disqualified…</Note>
</OdfBody>

3.3.3.1 <Competition> Element

All valid ODF messages contain the element <Competition>.

3.3.3.2 <Note> Element

Any ODF message can contain an optional element <Note> to include non-formatted free text (to provide additional non-structured information if needed). This is typically used for explaining modifications to results (disqualified etc.)

<Note> element follows the <Competition> element. XML invalid characters < , &, >," and ' are escaped. < as “<” & as “&” > as “>” “ as “"” and ‘ as '. Any other character will not be escaped.

Example:

<Note>PEÑA Jorge (ESP) "reinstated" after protest.</Note>

3.3.3.3 <Competitor> Element

Certain ODF messages contain an optional element <Competitor> to include information about Athletes, Teams or Groups. Group is used when competitors of same or different organisations participate in an event together but are not considered a team and their results are individuals.

Element	Attribute	M/O	Value	Comment
Competitor	Code	M	S(20) with no leading zeroes	Competitor ID
	Type	M	T, A, G	T = Team A = Athlete G = Group
	Organisation	M	CC @Organisation	Competitor’s organisation. (MIXn is used in the case of Type G.)

If Competitor is an Athlete:

· <Competitor> element contains:

o The mandatory attribute Type = ”A”;

o The mandatory attribute Code which contains the AthleteID. This attribute links to an athlete listed in the DT_PARTIC message;

o The attribute Organisation provides the organisation of the athlete;

o The mandatory element <Composition>.

· <Composition> element contains the mandatory element <Athlete>

· <Athlete> element contains:

o The mandatory attribute Code which contains the AthleteID (which is the same as in the <Competitor> element);

o The mandatory attribute Order =”1”;

o The optional attribute Bib;

o Sport specific extensions as defined in the ODF Discipline Data Dictionary;

o In some messages the <Athlete> element contains the mandatory element <Description> which contains description information about the athlete.

· <Description> element contains:

o The optional attribute GivenName which contains the athlete’s given name in mixed case;

o The mandatory attribute FamilyName which contains the athlete’s family name in mixed case;

o The mandatory attribute Gender;

o The mandatory attribute Organisation which contains the athlete’s organisation which will be the same as Organisation in the Competitor element;

o The optional attribute Birthdate which contains the athletes birth date in the format YYYY-MM-DD;

o The optional attribute IFId which contains the international federation id of the athlete and should be the same as listed in DT_PARTIC;

o The optional attribute Class which contains the sport class for athletes in the Paralympic Games.

o The optional attributes Guide, GuideFamilyName and GuideGivenNam which contain the guide information for athletes in the Paralympic Games.

If Competitor is a Team:

· <Competitor> element contains;

o The mandatory attribute Type =”T”;

o The mandatory attribute Code = TeamCode. This attribute links to a team listed in the DT_PARTIC_TEAMS message;

o The optional attribute Bib which is the Bib of the team;

o The attribute Organisation provides the organisation of the team;

o The optional element <Composition>. This element is optional because there are situations where the team members are not known when the message is generated.

o Team sport specific extensions as defined in the ODF Discipline Data Dictionary;

o The optional element <Description> which is mandatory in the case of a team (optional as it is not sent when the competitor is an individual).

· <Description> element contains:

o The optional attribute TeamName which contains the name of the team;

o The optional attribute IFId which contains the international federation id of the team.

· <Composition> element contains the mandatory element <Athlete>.

· <Athlete> element contains:

o The list of athletes that are the team members for the applicable event unit;

o The mandatory attribute Code which contains the AthleteID. This attribute links to an athlete listed in the DT_PARTIC message;

o The mandatory attribute Order with the team members sort order starting at 1;

o The optional attribute Bib;

o Team members’ sport specific extensions as defined in the ODF Discipline Data Dictionary.

o The mandatory element <Description> as described above (when the Competitor is an athlete).

Note: Although team members for the event are listed in the DT_PARTIC_TEAMS message, specific ODF Sport messages will also include the team members for each particular event unit.

If the Competitor is a Group the message is the same as for a Team, except for:

· <Competitor> element contains

o the mandatory attribute Type = ”G”

o the mandatory attribute Code = NOC/NPC when the athletes belong to the same organisation, otherwise MIXn to indicate the participants are from different organisations. (Defined as MIX followed by numeric)

Here is an example of the use of ”G” in Modern Pentathlon. Note the members of the group receive individual results.

……
<Result SortOrder="4" StartOrder="4" StartSortOrder="4">
   <Competitor Code="MIX4" Type="G" Organisation="MIX">
     <Composition>
        <Athlete Code="1065564" Order="1" Bib="227" >
           <Description GivenName="Jane" FamilyName="Smith" Gender="W" Organisation="SUI" BirthDate="1997-07-15" IFId="12345443" />
        </Athlete>
        <Athlete Code="1087051" Order="2" Bib="219" >
           <Description GivenName="Jenny" FamilyName="Jones" Gender="W" Organisation="ESP" BirthDate="1998-06-15" IFId="324522" />
        </Athlete>
     </Composition>
   </Competitor>
</Result>
……

3.4 ODF Data Types and Formats

This chapter describes data types and formats used in ODF messages.

3.4.1 Format Strings

The following table describes the custom numeric format specifiers and displays sample output produced by each format specifier. These specifiers and designators are used in defining specific formats. See the example section for an illustration of their use.

Format specifier or designator	Name	Description	Example
Y	Year	Represents a digit used in the time element “year”. Usually used as fixed number of characters, YYYY or YY	For the year 2016: in YYYY = 2016 in YY = 16
M	Month	Represents a digit used in the time element “month”. In ODF it is always used as MM.	For the month July: in MM = 07 For the month December: in MM = 12
D	Day	Represents a digit used in the time element “day”	For the 5^th of the month: in DD = 05 in D = 5 For the 15^th of the month: in DD = 15 in D = 15
h	hour	Represents a digit used in the time element “hour”	For 5am or 5 hours: in hh = 05 in h = 5 For 3pm or 15 hours: in hh = 15 in h = 15
m	minute	Represents a digit used in the time element “minute”.	For 5 minutes in mm = 05 For 5 minutes in m = 5 For 15 minutes in mm = 15
s	second	Represents a digit used in the time element “second”. In ODF it is always used as ss.	For 5 seconds in ss = 05 For 15 seconds in ss = 15
f	fraction of second	Represents a digit used in the time element “fractions of a second” The final display of time can vary by sport rules and any variations are described in the sport specific data dictionaries.	For 0.5 seconds in ff = 50 in f = 5 For 0.18 seconds in ff = 18
0	Positive integer	Data numeral. Replaces the zero with the corresponding digit if one is present; otherwise, zero appears in the result string	For 1546 in 0000 = 1546 in 00000 = 01546 For 1234.5678 in 00000 = 01235 For 0.45678 in 0.00 = 0.46 (See rounding rules below)
#	Digit placeholder	Data numeral. Replaces the “#” symbol with the corresponding digit if one is present; otherwise, no digit appears in the result string except where it is in the digit to the left of a decimal which must be shown as zero if applicable.	For 1546 in ###0 = 1546 For 1234.5678 in ####0 = 1235 For 0.45678 in 0.## or #.## = 0.46 (see rounding rules below)
.	Decimal point	Determines the location of the decimal separator in the result string.
Z		Is used as UTC designator.
-	Hyphen	to separate the time elements “year”, “month” and “day”.	2016-12-15
:	Colon	to separate the time elements “hour”, “minute” and “second”	12:15

3.4.2 Formats used in ODF

The following is the list of most common formats used in ODF.

Format	Format Description
CC @CodeEntity	This is a reference to a code set, where CodeEntity is the name of the entity that identifies a particular set of codes, for example CC @Discipline is the discipline code set.
String	Text strings without a predetermined length used in attributes without html
S(n)	Text strings with a length of up to n characters
Date	YYYY-MM-DD
Time	hhmmssfff · hh: hour · mm: minutes · ss: seconds · fff: milliseconds All formatted with leading and trailing zeros (example: 090303020, 150712530).
DateTime	YYYY-MM-DDThh:mm:ssTZD (e.g.: 2006-02-06T13:00:00+01:00) · YYYY: year · MM: Month · DD: day · hh: hour · mm: minutes · ss: seconds TZD is the Time Zone Designator (Z or +hh:mm or –hh:mm) where the message was produced and when the message was produced. “Z” is the zone designator for the zero UTC offset
Other Time Formats	Other time formats are also described in the Data Dictionaries. For example h:mm:ss for hour, minutes and seconds. Where such formats are used, unless specifically defined any leading zeros are removed. If the format is h:mm:ss and the data is 5 minutes and 20 seconds it is written 5:20.
Boolean	‘true’ or ‘false’
Numeric	Number with no predetermined length where the full value must be sent and displayed without leading zeros. Where a specific format is known then it is described as below (next row) in specific patterns.
Specific Numeric Pattern	Attributes with a specific pattern not specified in this table. Some examples include: 0000 = Number with length up to 4 digits, all digits displayed including leading zeros ###0 = Number with length up to 4 digits, do not display leading zeros. #0.00 = Number with length up to 2 digits and 2 decimals, do not display leading zeros. #0.## = Number with length up to 2 digits and 2 decimals, do not display leading zeros or trailing zeros after decimal. 0 = Number with a single digit s.ff = time in seconds and hundredths of seconds h:mm:ss = Time in hours, minutes and seconds. Hh:mm:ss = Time in hours, minutes and seconds with leading zero for hours.
Free text	Free text is never used in a message attribute, but it can be used inside the element content. Free text is usually longer and explanatory compared to a string. Example <element>Free text goes here</element>. XML invalid characters < , &, >," and ' are escaped. < as “<” & as “&” > as “>” “ as “"” and ‘ as '. Any other character will not be escaped.

More formats may be defined in the Sport Data Dictionaries using the specifiers defined in section 3.4.1.

3.4.3 Common Number and Time formats

This section describes measurement formats and the conversion rules to use in all messages, unless other formats or rules are specified in the sport documentation.

Measure

Format

Example

Height/Distance

#0.00m

##0cm

#’#0’’

1.83m

183cm

6’0’’

Weight

##0kg

##0lbs

100kg

220lbs

Temperature

#0ºC

##0ºF

35ºC

95ºF

Distance

#0.000km

#0.000mi

1.789km

6.123mi

Speed

#0.000m/s

#0.000mph

#0.000km/h

1.789m/s

6.123mph

3.890km/h

Precipitation

#0mm

#0in

2mm

1in

3.4.4 Rules for measurement conversion

These are the conversion rules to use in all messages, unless other rules are specified in the sport documentation. When using these conversions for athlete heights and weights the rounding rules must also be applied.

Measure	Conversion Rules
Distance	1in = 0.0254m 1ft = 12in = 0.3048m 1yd = 3ft = 36in = 0.9144m 1mi = 1,760yd = 5,280ft = 63360in = 1609.344m 1nmi (nautical mile) = 1,852m 1m = 39.37007874in = 3 ft 3.37007874in = 1 yd 3.37007874in 1 km = 0.62137119224mi = 0.8689762419nmi
Speed	1m/sec = 3.6km/hr 1km/h = 0.27777777778m/sec 1kt = 1nmi/h
Weight	1lbs = 0.453 592 37kg 1kg = 2.2046226218lbs
Temperature	T[°F] = 1.8 × T[°C] + 32 T[°C] = (T[°F] – 32) / 1.8

3.4.5 Rules for rounding numbers

This chapter describes the rules for rounding numbers to use in all messages, unless otherwise specified in the sport documentation or sport specific rules. Note: sport rules are applied before the transmission of the data and always take priority over these rules.

· Last digit in the number decimal part < 5 (0, 1, 2, 3, 4) à rounding down or truncation (i.e. 1.544 = 1.54)

· Last digit in the number decimal part >= 5 (5, 6, 7, 8, 9) à rounding up (i.e. 1.545 = 1.55)

3.4.6 Decimals and separators

Decimal numbers must be indicated using a point (full stop or period).

The use of thousands separators must never be used in messages but if desirable users may insert such separators in display.

For example

· 65.43

· 1003.45

ODF users may choose to translate points to commas for display purposes.

4 Message Operation and Use

4.1 Message generation systems

ODF messages can be produced by different systems which for the Olympic Games are:

· The On-Venue Results (OVR) Systems used by the OVR providers at the competition venues; and

· The Info Diffusion System (IDS) which is centrally located and used to generate all cross-sport and common messages.

4.2 Competition Day, Start and Stop Transmission

To assist in management of messages sent in a single competition day, messages are framed, or enclosed between ‘start’ and ‘end’ messages. Each local or venue system that generates messages during the day must:

· start the transmission with a DT_LOCAL_ON message and;

· end the transmission with a DT_LOCAL_OFF message.

The DT_LOCAL_ON and DT_LOCAL_OFF are the control messages to start and end the keep alive messages (DT_KA) from an OVR system. As some disciplines may be scheduled over multiple sessions on the same day there may be multiple DT_LOCAL_ON / DT_LOCAL_OFF messages for the same system on the same day when long breaks exist between sessions. This will also be the case if multiple disciplines are scheduled at the same venue on the same day.

In cases of multi-sports competitions the DT_GLOBAL_GM message is sent prior to sending the first DT_LOCAL_ON of the day and the DT_GLOBAL_GN message is sent after sending the last DT_LOCAL_OFF of the day and all central operations are complete.

Certain event units may run beyond midnight, hence the need to introduce the concept of a “logical day”. A logical day starts with the first unit of the day after the overnight break and ends after all units and associated activities are completed for the day, which may be after midnight.

All messages produced will be considered as belonging to the same logical day on which the first event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, all ODF messages will have the logical date of Aug 2).

For the Olympic Games, the end of the logical day is defined by default at 03:00 a.m. It may be later if competition and/or news operations are not completed for the day.

“Logical day” and “Competition day” are used interchangeably in the ODF documentation.

4.3 Message Invalidation

In some cases a message is sent in error or with errors. Where this happens during a competition then the usual recovery method is to send the message again correctly. In the case that users must be notified of the errant message and have it removed from their systems (maybe it was sent on the wrong day) then an empty message is sent. The message has the same key header attributes as the original message but without the <Competition> element.

Key header attributes to be the same as original message:

· CompetitionCode

· DocumentCode

· DocumentSubcode

· DocumentType

· DocumentSubtype

· Source

· Version

4.4 Message Frequency and Triggers

A message trigger is a condition that leads to the generation of an ODF message.

Specific message triggering is described in the ODF Data Dictionaries. This section presents a general overview only.

ODF is a real time feed, which means that information is distributed as soon as it becomes available.

Despite the requirement for distributing messages as soon as they become available where there is a series of the same message type / DocumentCode etc. (usually only applicable to DT_RESULT) then the message should be held and data merged to send not more frequently than 0.25sec (variable value).

Operationally this means if there is a gap of more than 0.25sec then send the message immediately then hold the following messages until 0.25sec has passed and then send only the last of the group of messages (as these are overwriting).

There are triggers related to the competition progress (e.g. sending a Result message when the results are getting the unofficial “status” as per the definition of status values for schedule and results) and there are triggers related with data changes (i.e. sending a Results message when there is a goal in football) plus some messages are triggered manually (i.e. weather information, medals).

As most messages are ‘complete’ or ‘full’ and include all necessary information, ODF users are generally free to process only certain messages (like the official results at the end of a unit) and still be able to exploit the messages according to their business needs.

4.4.1 Point-in-Time vs Real-Time

As described earlier ODF can be delivered either as a real time data feed or a point-in-time feed. In cases where it is delivered in real time, as in the Olympic Games, ODF users can use the ResultStatus (as defined in section 6.13) of the ODF header to effectively make it a point-in-time feed by only using messages with particular statuses (ResultStatus). A typical way to make the feed point-in-time might be to use START_LIST, INTERMEDIATE (at each break in play) and OFFICIAL. Alternately users could just ignore all messages with ResultStatus = LIVE. This can either be done by ODF users filtering the messages themselves or requesting providers to only distribute particular messages.

ODF users wishing to render the ODF data “live” must use, without limitation, all messages with ResultStatus = LIVE.

5 Key Data Messages

5.1 Participants

The participants’ message includes all people in a competition within each discipline; including athletes, team officials (coaches etc.) and competition officials. Teams and horses are listed in a separate message. It provides basic information about each person including his or her name, gender, date of birth and the organisation he or she is representing (a coach can one nationality but represent a different NOC).

When the participant is an athlete, the participant message also includes competition related information such as the status of the athlete and the events he or she will participate in.

Participants are included regardless of participant status.

Participant messages are sent at discipline level (i.e. each message contains only the participants of a given discipline).

Teams and horses are listed in a separate message.

The participant message is sent:

· As a full message (DT_PARTIC); and

· As an update message (DT_PARTIC_UPDATE).

As the participant list can be very large the DT_PARTIC message is sent before the competition starts and all changes are sent as DT_PARTIC_UPDATE. As for the DT_PARTIC, the DT_PARTIC_UPDATE is also sent at discipline level, but only includes those participants who have had changes to their data. For each participant, the full details of the participant are included in the message (as in the DT_PARTIC message) and not only details that have changed. For a given participant, a DT_PARTIC_UPDATE therefore totally overrides any information included in the DT_PARTIC message or a previously sent DT_PARTIC_UPDATE.

5.1.1 Participant names

The participant message contains participant names formatted in a variety of ways to cater for the various needs of the ODF users.

Where other messages (e.g. Results) contain participant names, the names are always formatted as Family Name and Given Name in mixed cases. ODF users can:

· Use the name as provided in each message,

· Use one of the formats provided in the participant message (using the AthleteID as a lookup value); or

· Reformat the name according to their needs.

The different formats used for peoples’ names are described in the ODF Language Guidelines and Participant Names document available with the ODF documentation.

5.1.2 Competition Officials

According to certain specific sport rules, certain start lists and results include the names of competition officials. ODF includes these officials in the participant message as well as in the specific start list and results messages where appropriate.

The lists of competition officials included in the ODF messages are usually not exhaustive, but include only those official functions as mandated by the Ifs (e.g. judging panels in judged sports, referees / umpires in team sports).

Officials are listed with a function that describes their role. This function may change depending on the unit of competition. For example a judge may be an Artistic Impression Judge for one unit and a Technical Merit Judge for the next.

Full details of the functions used are included in the Codes document for a particular competition.

5.1.3 Team Officials

As for competition officials, certain team officials are listed in certain ODF messages according to specific sport rules. This is usually true for team sports (e.g. basketball, football etc.)

Team officials’ roles are defined by their function (as for competition officials). The full list of functions is available in the Codes document.

5.2 Teams

In ODF a team is defined as any grouping of two or more athletes participating in a single event usually from the same organisation (always in the case of the Olympic and Paralympic Games). The DT_PARTIC_TEAMS message is defined to include all teams, and all members of each team once the team members are known. When the team members are known, the DT_PARTIC_TEAMS message contains the members for the event (e.g. Men’s Football). Team members participating in a single event unit (i.e. one match) are included in the start list for that unit when the information is available.

Updates are available in the DT_PARTIC_TEAMS_UPDATE message.

There is no group message as groups are a number of athletes who compete together but do not form a team, for example a group in Golf or a mixed pair in Modern Pentathlon Fencing.

5.3 Horses

The DT_PARTIC_HORSES message contains the list of horses. Only one format is available for horse names (all uppercase). Where a name is too long it is truncated and a full stop is used to indicate the truncation. In the Olympic Games DT_PARTIC_HORSES only applies to equestrian (modern pentathlon only uses DT_PARTIC_HORSES_UPDATE).

Updates will be available in the DT_PARTIC_HORSES_UPDATE message for both equestrian and modern pentathlon.

5.4 Schedule

5.4.1 Discipline Schedule

A full schedule per discipline is provided in a single schedule message, DT_SCHEDULE.

The schedule message includes the scheduled dates, times and status information (in progress, official, etc.) for each unit of the discipline.

To simplify the use of the schedule messages, they also include the names of teams / athletes in head-to-head sports (team, individual and pairs) to make the information easier to render.

The initial message DT_SCHEDULE includes all units in a discipline while the updates (DT_SCHEDULE_UPDATE) should only include those units which have changes or additional data.

5.4.2 Unscheduled Units

For some events, some units may or may not take place depending on the number of entries or outcome of other units.

For example, the number of heats for the 100m in Athletics may not be known until the final entries are received. In this case organisers will plan for the maximum number of heats and then reduce it as the number of athletes is confirmed. Similarly, swim-offs in Swimming are not used unless circumstances require it. Such units are identified in the schedule messages with the status of ’Unscheduled‘, meaning that these units may take place but are not yet confirmed. The default status is Scheduled (this unit will take place but has not yet started).

ODF users must be aware of the possibility of unscheduled units and design their systems to allow for them to become ‘Scheduled’ at any time during the competition.

For example, a jump-off in Equestrian or swim-off in Swimming may be in unscheduled status until after the final competitors have competed in the prior unit(s). The need for these optional or dependent units is only known once the results are available and an official announcement is made that a tie must be broken. In these cases, ODF users may get very short notice prior to unscheduled units taking place.

5.4.3 Schedule Status

In a schedule message, the stage of each unit is described using different statuses (ScheduleStatus) e.g.:

· ‘Unscheduled’ which means the unit is not confirmed so should not be displayed (for example alternate formats or a swim-off);

· ‘Scheduled’ indicating that unit is scheduled;

· ‘Getting Ready’ to indicate that the start is imminent;

· various statuses after the start;

· ‘Finished’ after the unit is over and no more action will happen on the field of play (last competitor finished); or

· ‘Cancelled’ should a unit not take place.

The full list of statuses and definitions is available in the codes documentation and not listed here to avoid duplication.

Note that “ScheduleStatus” is different than the “ResultStatus” as further described in section 6.13.

More detail is provided in section 9.1 Schedule and Results Status.

5.5 Configuration

The configuration message, DT_CONFIG, is designed to inform ODF users of the structure and/or configuration of an event. Examples include information such as the number of laps in a Road Race, the number of intermediate points in Alpine Skiing or the number of courts used in Tennis or Badminton. The message is designed more for systems rather than end users and allows ODF users to appropriately adapt the rendering of the ODF message (e.g. one column per lap, one tab per Tennis court).

Information provided in this message is generally restricted to information which is fixed and not expected to change for the discipline/event/unit though ODF users must be prepared for updates should that occur. Other such configuration information which is more likely to change should be sent in the start list message.

The DT_CONFIG should always be sent at the lowest appropriate level (unit, phase, event) depending on the discipline.

5.6 Results

The ‘Results’ message, DT_RESULT is the key message for all competition information and is available for every unit. This message is:

· used to provide the start list before the start of the unit;

· updated continuously throughout the unit with results; and

· sent with the unofficial and official results when the unit is over.

This message includes the majority of information about a single unit, the only exception may be when there is a very large amount of information to be provided, in which case Results Analysis may be used. Regardless of any splitting of data, the Results message will always include the same volume of information about all athletes who participated in the unit.

The results message carries information specific to a particular unit but some sports have results information covering multiple units, for example cumulative points in Decathlon or overall rank across all Swimming heats. This information is sent in Cumulative Results or Phase Results messages.

The DT_RESULT message is always triggered immediately when a unit starts to change from ResultStatus of START_LIST to LIVE even if no other information has changed.

5.7 Phase Results

In certain disciplines, athlete’s progress to the next phase (e.g. quarterfinals to semifinals) according to their individual ranking compared to all other athletes who competed in the same phase. According to each specific discipline rules (e.g. Swimming), the DT_PHASE_RESULT message includes the ranking of all competitors in a phase.

This message also includes qualifying marks where appropriate. If these marks are by time/best performance based then the marks will appear in this message and not DT_RESULT (to avoid resending DT_RESULT when it is OFFICIAL to add the qualifying marks).

The level of detail included in this message will vary by discipline but it should include sufficient detail to avoid the need to merge data with other messages to fully and correctly provide the information.

ODF clients requiring only a summary of results might use only this message (without the need to process the results messages at unit level). Where used, the phase results message is sent after every unit including the first one (for the first one, the phase results will be the same as the unit results).

5.8 Cumulative Results

The results messages apply at unit level and provide complete information for a single event unit. However there are some disciplines where scores are accumulated in individual units either within a phase or across phases to add to an overall score (like Slalom Skiing, Decathlon or Sailing). In this case the DT_CUMULATIVE_RESULT message is used to provide the most accurate representation of the current ranking.

ODF clients requiring only a summary might use only this message (without the need to process the results message at unit level). Where used, the cumulative results message is sent after every unit including the first one (although no accumulated information will exist for the first one).

The cumulative message is used where competitors participate in a number of event units and are ranked according to the results obtained in all these units. This message is also used in cases where a competitor participates over multiple units and only the best performance is used (i.e. not accumulated). Note this is a general principle which does not apply to all competition formats. See specific documentation for the implementation details.

5.9 Pools

Some disciplines structure their events so a number of competitors (usually teams) all participate against one another to determine who will progress to the final phases. This is usually called round robin or pool format. There are usually multiple pools or groups of competitors in these events.

The DT_POOL_STANDING message provides details of the current standing in each pool, according to the appropriate competition format.

5.10Brackets

Head-to-head competitions usually structure the event using a bracket or draw format where the winner of each match progress to the next round and losers are out of the event or relegated to a repêchage phase. Brackets are often used in combination with pools in team sports (like Football and Basketball).

There can often be multiple brackets in a single event, particularly where repêchages are used and the play-off for the bronze medal is often represented by a different bracket to that leading to the overall winner.

The specific message to support the bracket format is DT_BRACKETS which describes the progression of each competitor through to the finals. All brackets within a single event are catered for in a single message.

5.11Event Ranking

At the end of an event (i.e. after the final) the full ranking of competitors is available. The DT_RANKING message provides the overall ranking for all competitors (or as many as possible within the discipline).

In certain cases, according to specific rules, a partial event ranking may be available prior to the completion of the event. For example in some head-to-head or team sports, a competitor’s ranking is available after they are eliminated, so early versions may contain all competitors except those still remaining in competition (e.g. before the semifinals the list includes all athletes or teams ranked 5 and below). This is also possible in long duration mass start events such as Marathon or Cycling Road where a partial ranking will be sent after a first group of athletes have finished the race.

5.12Medals

At the end of an event (i.e. after the final) the full medals information is available. The DT_MEDALLISTS provides this information for the medal winners.

In certain cases, according to specific sport rules, the medals may be available prior to the completion of the event. For example in some head-to-head or team sports, a competitor’s medal is available after they are eliminated, so early versions may include only the bronze medal which has just been awarded (e.g. boxing after the semifinals).

5.13Statistics

The results message includes all statistics within an event unit, both individual and team. For example points scored, penalties etc. within a match are in the DT_RESULT message for that match. However some sports require details of statistics for individuals and teams over more than one match or for the full event or competition. These statistics can be in the form of cumulative data (e.g. total goals) and bests (e.g. leading scorers).

All types of statistics (both individual and team) which are not within a single event unit are included in the DT_STATS message.

5.14Play by Play

The play by play message, DT_PLAY_BY_PLAY is designed to describe each action in a unit. This message is sent after each action and contains, in order, all actions registered so far within a unit, so end users can understand the progress of the unit. The message is also used for incidents in mass start events such as Cycling Road, Mountain Bike or Triathlon.

This message does not apply to all disciplines.

5.15Current Data

The Current message, DT_CURRENT, is used to provide fast real time information which is critical to the provision of instant results well as information with no impact on the results (e.g. speeds, wind speed). It is designed for use by organisations that need sub-second performance.

This message is generally used for:

· Server information;

· Score in team sports;

· Clock information in team sports;

· Speed Information;

· Current and Next competitors inside a single event unit (e.g. Equestrian, Alpine Skiing); and

· Updating score of current competitor inside a single event unit (e.g. Slalom Canoe, Equestrian).

The data within the current messages is intended to be stand-alone and provide the immediate situation in a unit and generally should not be merged with the data provided in the DT_RESULT messages to avoid possible inconsistencies:

· DT_RESULT contains the official results and should be used for official purposes.

· DT_CURRENT is never available with an ‘official’ status.

Unless otherwise specified the DT_CURRENT message must be sent at the same RSC level as DT_RESULT.

Note that running clock information is only contained in the DT_CURRENT message.

5.16Official Communications

The Official Communication message, DT_COMMUNICATION allows competition organisers to transmit important competition related information, mainly for schedule change of an event or event unit or disqualification of an athlete, a team, after completion of an event. An example would be the disqualification of an athlete or changes in the schedule due to unforeseen circumstances.

This message, provided as free text, is intended to alert ODF users of a special situation. A corresponding PDF message with full details is generated simultaneously.

Note that other messages impacted by an Official Communication will be updated in the normal way (by sending a new version of impacted messages).

6 Principles Used

6.1 Codes

Codes are extensively used to simplify and reduce the size of messages as well as easily allow translation into different languages from a unique source. The details of all codes are available in the ODF Codes Document. In data dictionary documents, codes are referenced in the following way:

CC @CodeEntity where CodeEntity is the name of the entity that identifies a particular set of codes, for example CC @Discipline is the discipline codeset.

6.2 RSC Level

Whenever possible, schedules, start lists and results should be at the same RSC level for all disciplines (that is at either phase or unit level). There may however be some situations where results may exist without start lists or even units scheduled (e.g. Gymnastics has one start list for the qualification but there are multiple results (for individual and teams as well as individual apparatus).

6.3 ExtendedInfos

ExtendedInfo appears at the top of most sports’ messages and is used to provide additional information about the unit or data. This includes the venue, sport and event name in full text. It can also be extended for identification of the competition within the sport federation. Sports Federations can use this to uniquely identify data for their own purposes.

A sample for athletics using Sport Federation data and sport/venue details follows:

The section also provides details related to the specific message but do not relate to a specific competitor.

For example the start and end times of a unit of competition are part of the information for a unit.

Qualification rules and progression rules may also be included here.

This information section can be extended to provide detailed information for a particular sport or competition.

A sample for high jump follows:

6.4 Competitor unique identifiers

All competitors (teams and athletes), coaches and judges etc. are identified by a unique ID in each ODF message. This unique ID is defined by each organiser (i.e. the unique ID used for one edition of the Olympic Games will be different at the next edition, and also different than those used for the World Championships).

In addition, when provided by the Ifs, athletes, teams and officials may also be identified by a unique Federation ID, valid across all competitions within the sport.

6.5 Participant Names

Participant names are distributed in the DT_PARTIC messages but are also sent in other messages to reduce processing for some ODF users. For example an athlete’s name is first sent in DT_PARTIC and then again in DT_RESULT when the start list is available.

If for any reason an athlete’s name changes during the course of a competition (for example to correct a misspelling) then a DT_PARTIC_UPDATE is sent to correct it. However, any other messages sent which included the misspelt name are not resent, though all messages in the future will contain the correction. It will therefore be the responsibility of each ODF user to correct the spelling of names as appropriate whenever a DT_PARTIC_UPDATE contains a correction to a name.

In a similar way team and horse names are sent using the DT_PARTIC_TEAMS / DT_PARTIC_TEAMS_UPDATE or DT_PARTIC_HORSES / DT_PARTIC_HORSES_UPDATE messages and then again in the DT_RESULT as well as other related messages.

6.6 Mandatory and Optional Elements/Attributes

The intent of the terms Mandatory and Optional are:

· Mandatory: This element/attribute must always be sent;

· Optional: This element/attribute must be sent when the related information is available. For example the attribute <Bib> is not used in some sports (e.g. swimming) so is optional but must be included in sports where bibs are used. The same applies to IRM; this will be used only when the athlete has an IRM.

The schedule and all participant messages (both full and UPDATE messages) must always contain all available information and providers must send optional items if the data is available.

The rule is that if data is available, it must be included in the messages.

6.7 Empty values and updates

Most ODF2 messages are full messages, i.e. messages contain all applicable data, and each message totally overrides the previous version of the same message. This is true for all messages except those named “…_UPDATE” which update only part of a full message, providing full data for one participant or unit for instance.

As such, when sending full messages, there is no difference between sending an empty attribute and not sending an attribute. Not sending an attribute means that if this attribute was existing within a previous version of the same message, ODF users must remove this attribute from any database or update their own rendering accordingly. The keep the message size to a minimum, providers should not send the attribute when the attribute is empty.

When receiving schedule and participant messages (or any update thereof), ODF users must delete the information received previously (for applicable participants/users) and replace it with the new one, which will contain full relevant data. Important note: for participants, the delete applies only to the current discipline (as specified within the message header), and not to all disciplines.

6.8 Ordering and Timing of messages

The timing of messages is generally out of the control of the technology teams as release of official versions are subject to the approval by the sport’s Technical Delegates. As this process is manual and requires due care in some cases this release may take some time. Some general rules can however be applied when multiple messages need to be sent at the same time (though ODF users must be ready to handle exceptions where message order differs):

· When a status change occurs for an event unit (e.g. unofficial to official) the DT_SCHEDULE_UPDATE message will always precede the associated messages (e.g. DT_RESULT).

· DT_RESULT will be sent before the cumulative/phase result.

· If both DT_MEDALLISTS and DT_RANKING are sent at a particular point in time then DT_MEDALLISTS precedes DT_RANKING.

· The messages produced after the completion of a unit (DT_STATS, DT_BRACKET etc.) will be sent after DT_RESULTS and as intermediate/unconfirmed/unofficial/official as appropriate.

· The usual order of key results messages is, if applicable to the event:

o DT_CURRENT

o DT_RESULT

o DT_PLAY_BY_PLAY

o DT_CUMULATIVE_RESULT

o DT_PHASE_RESULT

Regardless of the order in which messages are sent or received all users must be prepared to process all messages received.

For further information, the cumulative results are sent before the phase results where both apply as the cumulative results usually carry an accumulated rank / score while the phase message usually compares competitors between units.

6.9 Sorting within Messages

The correct and consistent use of SortOrder and IDX fields is critical for correct display of results and can be complex during a competition. The following is intended to clarify the use of the fields so all users have the same understanding.

When any sortorder/index data is sent for any competitor (defined message by message) in a unit then that attribute/field must be filled for every competitor for that sort order/index. This ensures any sorting by that value will place all competitors in the correct order (even if some have not started). For example when the first competitor passes the first intermediate point then he/she receives index=1, all others receive index 2, 3 etc. following the StartSortOrder except those with IRM who receive the highest numbers in the appropriate IRM order. The same process follows as each competitor passes the intermediate.

In mass start events when the first competitor reaches intermediate 2 then again all receive the index, the first crosses receives 1, the remainder are numbered according to their sequence order at the first intermediate from 2 ..3 etc. (same order as intermediate 1, not necessarily the same value) followed by the IRMs in appropriate order.

The same follows at every subsequent intermediate point and also applies for the overall SortOrder. The overall SortOrder must be updated every time the forward most intermediate is updated with the same values as the forward most intermediate.

Note: In some cases IRMs may not be at the bottom, when an event is live, IRMs may appear above those who have not yet started the competition.

When SortOrder/indexes are used they will always start at 1, be sequential and not repeat any values.

Where SortOrder is used for head to head units then 1 and 2 are used for home and away. This allocation will not change after the unit when the result is known.

6.10Which messages to process?

6.10.1 General (non-sport specific) messages

ODF users wishing to manage or render schedule information must process all DT_SCHEDULE and all DT_SCHEDULE_UPDATE messages in order to always maintain the latest schedule information.

ODF users wishing to manage or render participants information must process all DT_PARTIC and all DT_PARTIC_UPDATE (and for teams and horses) messages in order to always maintain the latest participants’ information.

Processing these two types of messages is not mandatory. ODF users wishing to render minimal competition results will be able to do so by using the unit date & times and participants’ name contained in the DT_RESULT messages.

ODF users wishing to manage or render background information, biographies, news, etc. must process all messages in order to always maintain the latest relevant information.

6.10.2 Results related messages

Results related messages (DT_RESULT, DT_PLAY_BY_PLAY, DT_RANKING etc.) are always full and complete messages and always replace the previous version of the same message.

ODF users wishing to manage or render live results must process all results related messages in order to always maintain the latest information.

ODF users wishing to manage or render point-in-time results only may decide for instance not to process any results related message with a ResultStatus = “LIVE” and only process results related messages with a ResultStatus = “START_LIST”, “INTERMEDIATE”, “UNOFFICIAL” and “OFFICIAL”.

Once ODF users determine which messages they plan to process, users must process all messages of these types regardless or the sequence in which they are received. All messages need to be processed to properly render the progress of the unit.

6.11Message Source in the Header

In some cases of complex venues (i.e. large sport complex holding multiple fields of play for different disciplines) there may be a different Source for different fields of play or different disciplines. This Source is only used to differentiate generating systems and should not be used for any other purpose.

6.12Use of an Explanatory Information Element

All ODF messages allow for a free-text element to be included in the Note tag. This is designed to allow sending short additional details to ODF users. The content of this element includes information displayed at the bottom of a result output and is expected to be displayed to end users in full and unmodified.

The content of this element should not be used for routine information which is normally part of the competition (for example explaining the competition), but can be useful for communicating unusual incidents that affect competition or results and are not represented by other parts of the message. Here are some possible uses:

· Some parts of the message have been significantly changed.

· An athlete has been disqualified and the message provides details

Example:

<Note>PARK Taehwan (KOR) reinstated after protest.</Note>

6.13Results Status

Two different status concepts exist within ODF:

· The first one is the ScheduleStatus as described in section 5.4.3

· The second one is the ResultStatus included in the header of most messages generated at the venue.

The intent of ResultStatus is to provide the status of the results message rather than the status of the Event Unit although some of the statuses are the same. This status can be used to determine which messages to process (as described in sections 4.4.1 and 6.10.2) and which are the most important (official). It is also used to indicate that the Event Unit is LIVE and that messages are being continually sent.

Some of the key statuses are described below. The complete list of statuses is available in the ODF Codes Document. More detail is provided in section 9.1 Schedule and Results Status.

6.13.1 Start List

The results message is sent with ResultStatus = “START_LIST”.

The message contains start information but no results yet (except for IRMs, e.g. DNS [Did Not Start]).

6.13.2 Intermediate

The results message is sent with ResultStatus = “INTERMEDIATE”.

The message contains results information and is sent at logical break points during the unit (after a period in Ice Hockey or Basketball, after a certain number of paddlers in Canoe Slalom, before resurfacing the ice in Figure Skating, etc.).

The results and ranks in the message are subject to change once the action on the field of play resumes.

6.13.3 Live

The results message is sent with ResultStatus = “LIVE”.

Live is used while there is sport activity in an Event Unit and data is being continuously updated.

6.13.4 Unconfirmed

The results message is sent with ResultStatus = “UNCONFIRMED”.

Unconfirmed is the last of the live messages and indicates that the Event Unit is over although not moved to the unofficial or official status yet.

In disciplines where units are changed to unofficial or official without delay (e.g. swimming) then UNCONFIRMED is not used, it is used to advise end users the competition is complete and all data is complete.

The message must be used if there is any delay in sending UNOFFICIAL or OFFICIAL (whichever is used).

6.13.5 Unofficial

The results message is sent with ResultStatus = “UNOFFICIAL”.

This status is used when appropriate in a particular sport. The protocols vary by sport and this status may not be used in some instances.

Once results are set to Unofficial, such results are subject to final approval and may still change following decisions of the competition officials.

6.13.6 Official

The results message is sent with ResultStatus = “OFFICIAL”.

The results have been signed off and will not change other than in exceptional circumstances such as a disqualification.

6.13.7 Partial

The results message is sent with ResultStatus = “PARTIAL”.

The data in the document is “official” but does not contain all of the data for all of the competitors. This status is usually only used withy PDF messages and DT_RANKING.

6.14Extensions

6.14.1 Use of extensions

ODF aims to provide a generic structure with which all competition formats can be represented, but many sports and competitions require the use of additional information that must be provided to ODF users. ODF allows for the use of special elements called extensions that allow sections of messages to be expanded to include the most specific of sport information but in a way still generic enough to allow ODF users to easily process and render results.

6.14.2 Content of extensions

Each extension has three attributes:

· Code

· Pos

· Value

Code is mandatory. Pos and Value are optional.

Within the same element no two extensions can have the same combination of Code and Pos values.

Extensions are grouped under a parent element where the Code of the parent provides the context for the extensions.

Below is an example of an extension used to provide detailed information about three attempts in weightlifting:

6.14.2.1 Code

The Extension Code indicates the meaning of the value for this extension. The Extension Code provides more detail to the extension type (Extended Results [ER] in the example above).

The use of a Code allows ODF users to translate the display of extensions into their chosen language if required.

6.14.2.2 Pos

Pos may be used where there are multiple occurrences of an Extension Code in the same section. In the Weightlifting example above Pos is used to indicate which lift is under consideration. Pos is needed wherever there are multiple Extension Codes in the same group.

6.14.2.3 Value

Value can be almost anything and suppliers and ODF users need to refer to the ODF Data Dictionaries for a description of the possible values.

In the example above, the Value indicates the weight attempted.

Values generally fall into one of three general types:

· Number – this might be a count or a result and may be an integer or decimal number. Where the definition describes a number of decimal places suppliers must include leading and trailing zeros. For example, 2.5 to two decimal places must be written 2.50.

· Text (not predefined) – allows the value to be any text up to the maximum field length (see extension xml definition). Used where the values aren’t known in advance or there are very many possible values such as for providing a name.

· Pick-list / Predefined – where there is a limited number of possible options which can be defined in advance. For example left or right for handedness.

6.14.3 Ignoring extensions

ODF users can use the Type of extensions to include or exclude sets of information when processing results as they choose. Some ODF users may choose to ignore this extended detail.

6.14.4 Extension Hierarchy

In most cases a simple extension should provide all the information that an end user requires – a score at half time, a number of attempts. However, there are cases where there is a need to send a group of extensions organised into categories.

For example in Weightlifting there are two types of lifts which require the same information.

To allow for extending in this manner Extensions are usually grouped as shown in the example below.

6.14.5 Selecting extensions

To make the feed as easy as possible to use providers should re-use extensions from sport to sport for the same concepts (goals for example). This re-use will make it easier for ODF users to develop their own systems for different sports.

Before adding any new extension code, providers must check if such extension code already exists (potentially in another sport discipline) and use it for their own software development.

Providers are not authorised to re-use a code and change its intrinsic meaning. Doing so would make the newly developed software non-ODF compliant.

6.15Cumulative Messages, not all athletes progress

In some event formats which are cumulative not all athletes progress to the subsequent unit (for example in Equestrian and Snowboard). In these formats the general principle is that the Start List and Results include only those athletes participating in that unit (even if it is the second of two cumulative units) and therefore the unqualified athletes are not included nor are they usually included in the DT_CUMULATIVE_RESULT message (there may be variations by sport). However all of the athletes are included in the DT_RANKING message for the event.

6.16Positive and Negative Tags

In defining names used in tags, when the option of defining a positive or negative tags arises, the positive option should always be used to make the information easier to read. For example use VALID=”Y” instead of INVALID=”N”.

Where using the negative option would lead to rare use of the tag like UNCHECKED=”Y” then this option should be used.

6.17Single athlete competing multiple times

Some disciplines and competition formats allow an athlete to compete multiple times in a single event. For example in Equestrian an athlete may compete more than once but on different horses.

Where an athlete competes multiple times in a single event then the competitor code for the athlete will not be the same as the athlete’s ID. A different competitor code will be used each time the athlete participates in the applicable unit.

6.18Teams of Teams

Some disciplines include events where teams of teams compete. Some examples include:

· Figure Skating Teams (comprising individuals and pairs)

· Table Tennis Teams (comprising individual and doubles matches)

· Davis / Fed Cup in tennis (comprising individual and doubles matches)

To apply ODF to these formats the usual method is to have each lowest level competition as a unit. For example:

· In Teams Figure Skating there would be normal start list and results for each of the men, women, pairs (team) and dance (team).

· In Davis Cup there would be normal start list and results for each of the four (4) singles and one double match.

In each case the overall team result is found in a cumulative message which provides the details for results of the full event.

A similar technique is used in events like decathlon or modern pentathlon though these do not include teams of teams.

6.19ODF Message Overwrite

ODF users must replace the content of a previously processed message whenever a new version of the same message is received.

As described in section 3.3.2, a message unique identifier is the aggregation of the following attributes:

1. CompetitionCode

2. DocumentCode

3. DocumentSubcode

4. DocumentType

5. DocumentSubtype

6. Source

7. Version

Any new version of a message with the same first 5 attributes as listed above completely overrides its previous version.

Some specific messages, (with an UPDATE suffix) are used for updating some elements and keep the rest of data unchanged, e.g.

· DT_SCHEDULE_UPDATE

· DT_PARTIC_UPDATE

· DT_PARTIC_TEAMS_UPDATE

· DT_PARTIC_HORSES_UPDATE

For these messages, the logic to check for new versions of the same message is not applicable.

6.20Guides, Pilots and Directors in the Paralympic Games

The governing rule is the IPC only allows one guide to win a medal (per athlete per event where the guide is from the same NPC) though in some sports allows multiple guides during the event, either different guides in different phases or changing guides within a unit (in longer events)

Regarding what to display/what to expect in the messages in case of Guides, Pilots, Directors etc.:

· The single guide eligible for a medal will be included in all applicable messages (DT_RESULT, DT_MEDALLISTS etc).

· Entries should collect at most up to two guides, pilot etc. per event (per athlete). This is primarily needed in athletics events over 5000m or cross-country skiing distance events where an athlete is entitled to have two guide-runners. Both guides should be captured through sports entries and attributed to the athlete and transferred to OVR. NPCs can drop one of them at the final confirmation, then the remaining guide may be eligible for a medal. If both are confirmed, then neither will be eligible for a medal.

· OVR will provide a Guide in the message in DT_MEDALLISTS if he/she wins a medal

Following from this:

· If an athlete has no guide then OVR /SEQ does not provide Guide and no guide information is displayed

· If an athlete has one guide (and is eligible for a medal) then OVR / Entries provides Guide Information and all systems display Guide information

· If an athlete has one guide (and is not eligible for a medal, for example if Guide NPC is different to athlete NPC) then OVR / Entries does not provide Guide and no systems display guide information.

· If an athlete has more than one guide (and one is the "main guide" and is eligible for a medal [if allowed under rules as in CC, BT]) then OVR / Entries provide Guide Information and all systems display Guide information for the single eligible guide.

· If an athlete has more than one guide then entries provides the Guides which is in DT_PARTIC (& UPDATE) but not in other messages. Guide information is only displayed if a guide is eligible for a medal.

7 Message Transmission

7.1 Options for Transmission

ODF is primarily designed for use as a live real time system using the online HTTP message transmission detailed below. The same messages may however be distributed in other ways though these are not used at the Olympic or Paralympic Games.

7.1.1 At the Olympic and Paralympic Games

· The messages will be distributed to all ODF users simultaneously.

· All generated and distributed messages will be stored in a dedicated repository for later re-distribution if required. This re-distribution may apply to any number of ODF users and can either be:

o Manual and based on search criteria (see section 7.3.1 Backup Message Web Site for details); or

o Automatic (see section 7.3.2 Automatic Resend for details).

· Undelivered or partially delivered messages due to loss of connectivity will be queued and automatically transmitted after re-establishing the connectivity.

7.2 Online HTTP Message Transmission

7.2.1 Connectivity

ODF message transmission is accomplished via a combination of an underlying TCP/IP based connection along with message transmission using the HTTP protocol.

This method of transmission requires that ODF users be able to establish TCP based connectivity with the organizing committee’s network along with having software capable of receiving and dealing with HTTP Post requests.

7.2.2 HTTP Usage

Messages will be delivered to ODF users using the HTTP protocol. Specifically each message will be delivered using an HTTP Post request. This is a example of an ODF message posting:

POST /path/ODFClient HTTP/1.1
Content-type: text/xml
User-Agent: ODF/1.0
Cache-Control: no-cache
Pragma: no-cache
Host: 172.24.44.85:80
Connection: keep-alive
Content-Length: 1402

<?xml version="1.0" encoding="utf-8"?>
<OdfBody CompetitionCode="LOCOG" DocumentCode="VBV-------------------------------" DocumentSubcode="GENERAL" DocumentType="DT_PARTIC_UPDATE" FeedFlag="T" Date="2012-08-11" Time="121537867" LogicalDate="2012-08-11" Version="1" >
   <Competition>
     <Participant Code="50214132" Parent="50214132" Status="ACTIVE" GivenName="PABLO" FamilyName="HERRERA" PrintName="HERRERA PABLO" PrintInitialName="HERRERA P." TVName="HERRERA PABLO" TVInitialName="HERRERA P." Gender="M" Organisation="ESP" BirthDate="1982-06-29" Height="193" Weight="85" PlaceofBirth="" CountryofBirth="ESP" PlaceofResidence="" CountryofResidence="" Nationality="ESP" Current="true" ModificationIndicator="N" OlympicSolidarity="N" MainFunctionId="AA01">
        <Discipline Code="VBV-------------------------------">
           <RegisteredEvent Gender="M" Event="400" Bib="">
              <EventEntry Code="CAPTAIN" Type="ENTRY" Value="N" />
              <EventEntry Code="POSITION" Type="ENTRY" Pos="1" Value="L"/>
              <EventEntry Code="POSITION" Type="ENTRY" Pos="2" Value="B"/>
              <EventEntry Code="SHIRT_NAME" Type="ENTRY" Value="HERRERA"/>
           </RegisteredEvent>
        </Discipline>
     </Participant>
   </Competition>
</OdfBody>

The above example assumes the following:

· The request URI (in this case ‘path/ODFClient’) will be specified by each ODF user.

· The TCP port the requests will be sent to will be specified by each ODF user. The default will be port 80 but each ODF user is free to change this.

· The message payload will contain the ODF message.

Upon receiving the HTTP request the ODF users designated handler may apply any required business rules to the message but it must pass an HTTP response back with a return code of 200 to the sender to indicate successful reception of the message. Here’s what the response would look like:

HTTP/1.1 200 OK

If the sending software does not receive a successful response within a specific timeframe (for example, 5 seconds) from the recipient the message should be queued again and resent at regular intervals (for example, 5 seconds) till a successful response is received. If failures continue then the recipient must be contacted to resolve the issue.

7.2.3 Expected Results

HTTP Response will be expected from the ODF users.

7.3 Backup and Recovery

For the Olympic and Paralympic Games the “Backup Internet Data Feed” (BIF) server will be the sole backup mechanism in place should there be a failure in the HTTP based delivery mechanism. The BIF will consist of a Website and an automatic resend process.

ODF users can detect missing messages using Version number (all versions of a particular document should have sequential versions) in the Header (Note: This is not valid if an ODF user applies filtering mechanism so to not receive all messages of a message key).

ODF users have three options to recover missed messages:

· Wait for the next version of the message (this option is only valid while the unit is LIVE);

· Manually retrieve it from the BIF application; or

· Request an automatic resend (explained in section 7.3.2).

All messages are available in BIF as a backup.

7.3.1 Backup Message Web Site

An interactive web site where ODF users will be able to retrieve previously posted ODF messages is available for the Olympic and Paralympic Games. The site allows for filtering of the messages to be retrieved based on the following criteria:

· Games Day (logical day)

· Language

· Format

· Time

· Document Code

· Document Type

ODF users can then select messages and:

· Compress them into one .zip file and download it; or

· (Re)distribute them to the ODF Feed using the functionality available at the site.

Users of BIF are also able to retrieve messages with direct HTTP calls rather than using the on-line form. This HTTP call (using Representational state transfer or REST) is an ideal mechanism for those requiring a more automated request mechanism. A sample call would be http://bifserver/resend?DocumentCode=ATH-------------------------------&DocumentType=DT_PDF&DocumentSubtype=C67&FeedFlag=P.

7.3.2 Automatic Resend

The interactive web site will enable ODF users to request resending any previously posted ODF messages. To do so, the ODF user will need to do an HTTP GET or POST request to a specific URL in the BIF web server with the following parameters:

Request Parameter	Mandatory	Description
DocumentCode	Y	Document Code
DocumentSubcode	N	Document Subcode
DocumentType	Y	Document Type
DocumentSubtype	N	Document Subtype
Version	Y	Version
LogicalDate	N	Message Logical Date
Date	N	Message Date
FeedFlag	Y	Feed Flag
Language	N	Language

An example of a request in the Olympic or Paralympic Games would be:

http://bifserver/resend?DocumentCode=ATH------------------------------- &DocumentType=DT_PDF&DocumentSubtype=C67&Version=1&LogicalDate=20120812&FeedFlag=P

All files which meet the request criteria will be resent.

7.4 Alternate Transmission Methods

As ODF files contain complete information at the point of creation they can be distributed in different ways at other competitions than the Olympic and Paralympic Games. This document will not go into those details as each provider is free to use methods which best suit their users’ requirements for example:

· Email

· RSS/ATOM

· FTP

If these alternate transmission methods are used it is recommended to use a file name scheme to ensure the files do not overwrite each other and are easily identified. The following is recommended in order:

· Competition Code

· Logical Date (yyyy-mm-dd)

· Date (yyyy-mm-dd)

· Time (hhmmssnnn)

· Document Type (30)

· Document Subtype (20)

· Document Code (34)

· Document Subcode (34)

· ResultStatus (15)

· Version (5)

· Feed Flag (1)

· Language (3)

E.g.:

OWG20182018-02-122018-02-12100927351DT_RESULT_______________________________ATHM010101-------------------------__________________________________OFFICIAL___00001PENG.xml

OWG2018~2018-02-12~2018-02-12~100927351~DT_RESULT~~ATHM010101-------------------------~~OFFICIAL~1~P~ENG.xml

for a file with Document Code=ALPMDH----------------------------, Document Type=DT_RESULT, Version=1, Feed Flag=P, Language=ENG, Date=2012-08-20 and Time=100927351

These transmission methods are not used at the Olympic or Paralympic Games.

8 Sequence of Messages

This chapter provides some examples of the sequence in which ODF messages can be sent. There are more examples in the sport specific ODF Data Dictionaries.

8.1.1 Standard Sequence

This is the standard sequence for the last unit in a phase:

Message	Result Status	Comments
DT_SCHEDULE_UPDATE		Getting Ready
DT_RESULT	START_LIST	Add IRMs
DT_SCHEDULE_UPDATE		Running
DT_CURRENT	LIVE	Current Status
DT_RESULT	LIVE
DT_CURRENT	LIVE	Current Status
DT_RESULT	LIVE
DT_SCHEDULE_UPDATE		Finished
DT_RESULT	UNCONFIRMED	Competition is over
DT_PHASE_RESULT	UNCONFIRMED	Unconfirmed Phase Results
DT_RESULT	UNOFFICIAL	Unofficial Results
DT_PHASE_RESULT	UNOFFICIAL	Unofficial Phase Results
DT_RESULT	OFFICIAL	Official Results
DT_PHASE_RESULT	OFFICIAL	Official Phase Results
DT_MEDALLISTS	OFFICIAL
DT_RANKING	OFFICIAL	Final Ranking

9 Appendices

9.1 Schedule and Results Status

As introduced in earlier, two different status concepts exist within ODF:

· The first one is the ScheduleStatus (used in schedule messages)

· The second one is the ResultStatus included in the header of most messages generated at the venue.

The full and comparative list is as follows:

ScheduleStatus	ResultStatus	Comments
UNSCHEDULED		A possible unit to be scheduled, not to be displayed by ODF users (e.g. swim-off)
SCHEDULED		Scheduled unit, expected to happen
	START_LIST	Used when DT_RESULT includes start information
GETTING_READY		At time x (sport by sport) before start (see section 9.1.1 for full details).
RUNNING	LIVE	Competition is underway (see section 9.1.1 for full details).
SCHEDULED_BREAK		Planned break in competition (e.g. end of period)
	INTERMEDIATE	Updated results at scheduled points or breaks in competition
FINISHED	UNCONFIRMED	All play is complete in the unit but not yet Unofficial nor Official
	UNOFFICIAL	Results are unofficial, data is subject to change depending on sports rules (after filing a protest for instance)
	OFFICIAL	Results are official, data is unlikely to change except in case of subsequent disqualification.
DELAYED		The start of the unit has been delayed
CANCELLED		A scheduled unit has been cancelled (usually for meteorological reasons)
POSTPONED		Unit to be moved to a later (unknown) time
RESCHEDULED		Unit has been moved to a new later time (known time)
INTERRUPTED		Play in the unit is unexpectedly stopped
	PARTIAL	Shows part of the results in the PDF. Considered official but only for some of the athletes. May also be used in final medal and ranking messages.
	PROTESTED	Used after the competition is no longer LIVE and a protest has been lodged according to the rules of the discipline. After all decisions on the protest are made the ResultStatus will change to UNOFFICIAL or OFFICIAL as appropriate in the discipline.

9.1.1 Triggers for ‘Getting Ready’ & ‘Running’

These are the triggers used for changing the ScheduleStatus to GETTING_READY and RUNNING as well as the ResultStatus to LIVE.

9.1.1.1 Olympic and Paralympic Summer Sport Disciplines

Discipline	Event	Phase	Trigger for ‘Getting Ready’	Trigger for ‘Running’ / ‘Live’
ARC pARC	All	All	First athlete/team entering the field of play	First athlete loads first arrow
ATH	Decathlon Heptathlon	100m 100m Hurdles	Athletes lining up for initial presentation	Gunshot (clock begins)
ATH	Decathlon Heptathlon	Track	Athletes positioning at the lanes	Gunshot (clock begins)
ATH	Decathlon Heptathlon	Field	1 minute before the start	First athlete in position, ready to throw/jump
ATH pATH	Jumps	All	Athletes lining up for presentation, or approx. 2 minutes before competition when there is no presentation	First athlete in position, ready to jump
ATH pATH	Road	All	Most athletes already at the start, approx. 2 min before start of the race	Gunshot (clock begins)
ATH pATH	Throws	All	Athletes lining up for presentation, or approx. 2 minutes before start when there is no presentation	First athlete in position, ready to throw
ATH pATH	Track	All	Athletes positioning at the lanes	Gunshot (clock begins)
BDM	All	All	Immediately before coin toss (approx. 3 minutes before competition)	First athlete/team ready to serve
BKB WBK	All	All	Teams in formation to listen to their national anthems.	Referee throws the ball and first period clock begins
BMX	All	All	Athletes starting to line up at the start	Gates open
BOC	All	All	Athletes line-up before the start	First athlete throws the first ball.
BOX	All	All	First athlete comes through the tunnel	Round 1 clock starts
CRD	Road race	All	Most/all athletes already at the start, approx. 2 min before start of the race	Athletes pass the start line and clock begins
CRD	Time trial	All	First athlete getting into the start position, approx. 30 seconds before start	Clock begins for first athlete
CSL	All	All	Athlete getting to the position from where he will later speed up towards the start line, approx. 30 seconds before the start.	Athlete crosses the start line and clock begins
CSP	All	All	Athletes already on their Canoes/Kayaks and approaching the start line	Referee signals the start of the race and clock begins
CTR	Most events	Most phases	Athletes and their coaches at the start line or approaching it	Keirin: gunshot (no clock); Sprint: referee’s whistle; Others: gunshot (and clock begins)
CTR	Omnium	Points Race, Elimination Race, Scratch Race	Athletes ready for the initial speeding up lap	First athlete crosses the start line and laps start to be counted
DIV	All	All	Athletes lining up to be presented	First athlete on top of the springboard, ready to dive
EQU	Eventing	Cross Country	First athlete approaching the position from where he will speed up towards the start line, approx. 30 seconds before the start.	First athlete crosses the start line and his clock begins
EQU pEQU	Most events		First athlete enters the field of play	First athlete’s clock starts
FBL pFB7 FB5	All	All	Teams lining up to listen to the national anthems.	Referee blows his/her whistle
FEN	All	All	Referees and athletes/teams enter competition area	Referee signals the start of the match and clock begins countdown
GAR	All	All	Athletes lining up for presentation	First athlete starts performing at his/her apparatus
GBL	All	All	Teams lining up to listen to the national anthems.	Referee blows his/her whistle
GLF	All	All	When the first athlete is introduced on the first tee	First athlete hits the ball for the first time
GRY	All	All	First athlete enters the competition area	First athlete’s performance music begins
GTR	All	All	Athletes line up for presentation	First athlete climbs to the trampoline after warm up
HBL	All	All	Athletes line up for presentation	Referee’s whistle, and clock begins
HOC	All	All	Teams lining up for presentation	Referee’s whistle, and clock begins
JUD pJUD	All	All	Athletes line up at the entrance of the competition area, for presentation	Referee signals the start and clock begins the countdown.
MPN	Combined	Combined	Most athletes at the start, approx. 2 minutes before race begins	Race clock begins
MPN	Fencing	Fencing	Athletes line up for presentation	First athletes’ clock begins countdown
MPN	Riding	Riding	First athlete enters the field of play	First athlete’s clock begins
MPN	Swimming	Swimming	First group of athletes enter the pool area	Start signal for first group of athletes (and clock begins)
MTB	All	All	Most/all athletes already at the start, approx. 2 min before start of the race	Gunshot (clock begins)
OWS	All	All	Most athletes already at the starting platform, approximately 2 min before start of the race	Race clock begins
pCSP	All	All	Athletes already on their Canoes/Kayaks and approaching the start line	Referee signals the start of the race and clock begins
pCTR	All	Most phases	Athletes and their coaches at the start line or approaching it	Count down (and clock begins)
ROW pROW	All	All	Athletes on starting positions, waiting for presentation	Green light, and race clock begins
RUG	All	All	Athletes entering field of play (this is about 1 minute before match begins, as there are no anthems or athletes’ presentations)	Referee blows the whistle
SAL pSAL	All	All	Signal warning that race will begin in 5 minutes time	Countdown for start of the race reaches 0.
SHO	Skeet, Trap	All	Athletes lining up for presentation	First disk for first athlete is on air
SHO pSHO	Rifle, pistol	All	Athletes lining up behind their pistols / rifles, for presentation	First targets appear and can be shot at
SWM pSWM	All	All	Athletes entering the pool area	Start signal (and clock begins)
SYN	All	All	First team/duet entering the pool area	First team/duet’s performance music begins
TEN WTE	All	All	Athletes already practicing their service, during warm-up, approx. 2 minutes before match begins.	First athlete ready to serve
TKW	All	All	First athlete entering competition area	Referee signals the start and clock begins the countdown of the first period.
TRI pTRI	All	All	Most athletes already at the starting platform, approx. 2 min before start of the race	Race clock begins
TTE wTTE	All	All	Warm-up begins, approx. 2 minutes before the match	First athlete ready to serve
VBV	All	All	Athletes in their benches after warm up, waiting for presentation	First team ready to serve
VVO VBS	All	All	Athletes in their benches after warm-up, waiting for presentation	First team ready to serve
WFE	All	All	Presentation of athletes	Referee signals the start of the match and clock begins countdown
WLF PWL	All	All	First athlete enters field of play	First athlete starts lifting
WPO	All	All	Athletes lining up for presentation	Referee blows his/her whistle and athletes swim towards the ball
WRE	All	All	First athlete enters the competition area	Referee blows his/her whistle and first period’s clock begins
WRU	All	All	Teams in formation to listen to their national anthems.	Referee blows the whistle

9.1.1.2 Winter Sport Disciplines

Discipline	Event	Phase	Trigger for ‘Getting Ready’	Trigger for ‘Running’ / ‘Live’
ALP pALP	All	All	First athlete in position, approx. 30 seconds before start	First athlete’s clock begins
BOB SKN LUG	All	All	The track test runs before the start are completed	BS/SN: countdown begins for athletes to start; LG: first athlete grabs the start handles
BTH pBTH	Interval starts Pursuit	All	First athlete in position, approx. 30 seconds before start	First athlete’s clock begins
BTH pBTH	Mass start Relay	All	Most athletes at the start, approx. 1 minute before competition	Race clock begins
CCS pCCS	Interval starts Pursuit	All	Same as BT for Interval start and pursuit	First athlete’s clock begins
CCS pCCS	Mass start Relay	All	Same as BT for Mass start and Relay	Race clock begins
CUR pCUR	All	All	When the athletes march into the FoP.	When the Game time starts
FRS	Aerials Moguls Halfpipe Slopestyle Cross Qual.	All (except Cross, only Qual)	First athlete in position, approx. 30 seconds before start	First athlete leaves the gate (and clock begins, in Cross Qualification and Moguls).
FRS	Cross	Finals	Athletes positioning at the gates	Gates open
FSK	All	All	Skaters are called to conclude the warm-up and clear the ice, approx. 30 seconds before the start	First skater/pair’s performance music begins
IHO ISH	All	All	Teams lining up in front of each other before the start	First face-off takes place and first period clock begins
SBD pSBD	Big Air Halfpipe Slopestyle Cross Qual.	All (except Cross, only Qual)	Like FR for these same events	First athlete leaves the gate (and clock begins, in Cross Qualification).
SBD pSBD	Cross Finals	Finals	Like FR for the same event	Gates open
SBD	PGS	All	First athlete(s) positioning at the gate(s)	Gates open
SJP	All	All	30 seconds before the start	First athlete starts going down the ramp
NCB	All	Ski Jumping	Same as in Ski Jumping events	First athlete starts going down the ramp
NCB	All	Cross Country	Same as CC pursuit events	First athlete’s clock begins
SSK	All	All	First athlete(s)/team(s) on track, waiting to be presented and then occupy their starting positions.	Gunshot (and clock begins)
STK	All	All	Athletes called by the officials to occupy their starting positions, approx. 30 seconds before the start	Gunshot (and clock begins)

9.2 Information for providers wanting to extend ODF

This section is reserved for providing advice to providers who may need to extend ODF for other competitions. To be added in later versions.

9.3 RSC Codification Scheme

9.3.1 Introduction

The IOC identified the need to normalise the codification of the sport disciplines and events. The need for such a normalisation is identified by:

· IOC Technology to keep all the historical result databases coherent (JORES database),

· the ORIS Project where this will help the electronic data exchange between the Games organisers, International Sport Federations, the Olympic Data Feed recipients and the IOC,

· the International Sport Federations for easier identification and archiving,

· Constituent groups of stakeholders receiving, processing and presenting Games data to global audiences, such as the WNPA group and press agencies and broadcasters of the Games, to use it as reference in developing and setting up their systems and software,

· Other multisport event’s organisers who intend to use data feeds compatible to the Olympic Games data feed platform.

The original codification scheme operated from the 1990s until the 2016 Games in Rio. As the number of users of the data increased there was a need to makes the codes easier to use/read and have them contain more information.

The original scheme was nine characters in length. The new scheme adopted in 2015 for use after the Rio Games of 2016 extended this to 34 characters in length.

The code which uniquely identifies information regarding the results of the competitions is called Result System Code (RSC). This code is constructed from the following elements in the hierarchical order of their importance:

1 The first three (3) characters uniquely identify the sport’s discipline code (e.g. “SWM“ for swimming, “ALP” for alpine skiing, etc.);

2 The fourth character identifies the gender of the discipline (e.g. “W” for events where only women participate, “X” for events where both genders participate equally);

3 The next eighteen (18) characters represent the event. This is further divided into eight characters for the event type and the following ten characters for the event modifier. (e.g. “100m” for 100 metres, and a modifier if needed for things like disability class in the Paralympic Games or age group etc.);

4 The next four characters (4) are for the competition phase (e.g. preliminaries, semi-final, final, repechage, etc.) or part of competition (e.g. pool, subdivision, etc.);

5 The last eight (8) characters identify the unit and event sub-unit (e.g. a match, heat, group, etc. or run 1 and run 2 in the case of sub units).

The following general rules apply for the code:

· Fixed length, 34 characters,

· Full alphanumeric to increase human readability e.g. FNL for Final phase,

· Uppercase is used in all codes,

· The dash character “-“ is used as a filler, it is used when a part of the code is not applicable,

· Allow characters are A ... Z, 0...9 and the special characters of dot and dash. Dash is only used as a filler,

· Apply right padding with the filler character in any part of the RSC when the respective code is less characters than the maximum length of this part e.g. FNL (Final phase) is shown as “FNL-“ in the RSC.

9.3.1.1 Discipline Code (DDD)

A discipline is a branch of an Olympic sport comprising one or several events.

A discipline groups similar events (ex. aquatics is divided into swimming, synchronised swimming, diving, open water and water polo, canoe-kayak is divided into sprint and slalom events, etc.). Often, these divisions are related to the organisation of the International Federation though they may differ.

In defining these codes they must be unique between summer, winter and the Paralympics though the Paralympics may use the code where the discipline is the same.

9.3.1.2 Gender (G)

The gender depends on who is allowed to participate in an event. There are events which are exclusively male or female events as well as the mixed (where the team is composed of number of men and women) or open events (in which women and men participate equally).

“M” for male events e.g. Men’s 100m or Men’s Doubles etc.

“W” for female events e.g. “Women’s 100m”, “Women’s Singles etc.

“X” for mixed events e.g. Mixed Doubles, Figure Skating Pairs etc.

“O” for mixed events e.g. Luge Doubles or Equestrian Dressage etc.

9.3.1.3 Event / Event Modifier

”An event is a specific competition in a sport resulting in a ranking giving rise to the award of medals and diplomas.” (Olympic Charter)

An event consists of one or several steps or parts (phases) of one sport discipline. The number of the event steps (one or more) leads to the final step which awards the medals.

For the combined events, one event is constituted of several phases.

9.3.1.4 Event Type

The first eight (8) characters are reserved for the event type. In defining the codes used for events firstly any existing codes used in the discipline should be used, for example DH for Downhill in Alpine Skiing.

If there is no existing code then the code should be defined to transmit as much information as reasonable. The following principles generally apply (though are not mandatory):

· Teamx for teams where x usually indicates the number of athletes in the FoP. For example basketball would be “Team5”.

· Relays may be indicated in the usual format 4xnnnm for example 4X100M if there are fixed distances however the following the follow may also be used, include the work “RELAY” or “RY” or in the case of different size relay teams RELAYX where x indicates the number competing.

· In weight dependent events use xxKG and OxxKG to indicate under and over particular weights. For example under 54kg would be “54KG”.

· Generally the used codes should be easily readable to know the meaning / event.

9.3.1.5 Event Modifier

The remaining ten (10) characters are used for the event modifier. For example if there are multiple 100m events in men’s Paralympic athletics the same event type is used and the modifier distinguishes the classes. In a similar way it is used to distinguish different age groups. It may be used in other competitions for other purposes if no event modifier applies.

Principles:

· All 10 characters can be used as a modifier for a particular competition

· In the Paralympics the first 5 characters are used for Paralympic class of the event

o MMMMM can be split again into parts according to the pattern HHNNZ with

o HH = Highest sport class of the class combination

o NN = Number of classes combined

o Z = Auto-increment index for same HHNN

o Examples:
Athletics: 11010 = F11, 38020 = F37/38, 38021 = F36/38, 51030 = F31/32/51 etc.
Swimming: 05050 = S1-5, 05051 = SB1-5, 05052 = SM1-5, 10100 = 20pts (freestyle relay = S1-10), 10101 = 34pts, 10190 = 20pts (medley relay = S1-10 + SB1-9) etc.

· If both Paralympic and age group applies then characters 6-8 are used for age group (U18 = Under 18, O45 = Over 45)

Competition organisers are recommended to contact the International Paralympic Committee for further information.

The modifier should not be used for “open” competition. It is only intended for use in underage, veteran or Paralympic competition.

9.3.1.6 Phase (PPPP)

The phase is a section of a competition, most easily described by rounds in tennis or heats and finals in swimming. The following are the proposed standard codes to be used though this list is not comprehensive.

Phase	Meaning
R128	Round of 128
R64	Round of 64
R32	Round of 32
8FNL	1/8 Finals (Round of 16)
QFNL	Quarterfinal
SFNL	Semifinal
FNL	Final
DRAW	Draw
MEET	Team Managers / Team Captains meeting
VICT	Ceremonies
TRNO	Official Training
TRNU	Unoffical Training / Training
ZERO	Zeroing (BT)
SESS	Session
DAY	Day
GPx	Group x in Pools
HEAT	Heat
QUAL	Qualification / Ranking Round
PREL	Preliminaries
RND1	Round 1
RND2	Round 2
RND3	Round 3
RND4	Round 4
LL	Lucky Loser
REP	Repechage
REP1	Repechage Round 1
REP2	Repechage Round 2
HJ	High Jump (in Decathlon & Heptathlon)
1500	1500m(in Decathlon)
FERR	Fencing Ranking Round (MP)
FEBR	Fencing Bonus Round (MP)
SW	Swimming (MP)
COMB	Combined (MP)
EQ	Equestrian (MP)
FAKE	Special units only used for scheduling purposes

Note that any play-offs for final ranking positions like 7-8 play-off or bronze medal match would always be considered phase “FNL”.

9.3.1.7 Unit (UUUUUUUU)

The part of the competition that is set to be played within a Phase is called an unit.

A unit in generic terms represents a heat, match, game etc. It is generally the lowest level component of a competition.

When competition format is structured in such a way where, a second level of units is required in order to complete an unit then, this is called a subunit. In such situations a unit is structured, played and completed in different stages then, each one is considered as a subunit. A subunit can be, in competition terms, a heat, match, game etc. Therefore subunits are units within units. Subunits can be of the same playing type as units or of different type. The outcome of a subunit is aggregated to the previous subunits in order to accomplish the result of the parent unit. The range of applicability of a subunit result is only inside the parent unit.

Some examples of subunits:

· The runs in a heat in Alpine Skiing Team event.

· The individual matches in Table Tennis Team event. On the other hand, subunit is not a period in team sports.

The full size reserved in RSC pattern for the unit component, including potential use of subunits, is eight (8) characters.

When the unit is completed in a single stage, this is containing no subunits, then the first six characters are used. All six characters must always be used without any RSC placeholder (“-“) in any position. Character positions 7 and 8 will contain “-“.

When unit is structured and completed in more than one stages, that is subunits, character positions 7 and 8 are used (that is not “-“). Subunits are used in the case that a number of lower level competition components are completed to make the result of the unit. For example in the case of table tennis teams, in the semifinal phase there are two units (semifinal 1 and semifinal 2). Each of these semifinals consists of up to five matches, these five matches are subunits of each semifinal unit.

Subunit are not used in the case the lowest level units being accumulated into the total phase or event result. For example bobsleigh comprises of four runs, these results are accumulated into the total event result without the need of subunits.

If subunits are used then all eight units characters are used both at unit (or parent level) & subunit level. At the higher unit level characters 7 & 8 will be 00 to indicate it is the parent of the subunits.

For example:

“Normal” units:

· 000100-- (unit 1)

· 000200-- (unit 2)

· 0001SJ-- (unit)

Units with subunits:

· 00010000 (parent)

· 00010001 (subunit 1)

· 00010002 (subunit 2)

Some special cases:

· Medal Ceremony (with or without flowers) MEDAL---

· Flower Ceremony (no medals) FLOWER--

9.3.2 Examples

These are examples and are not necessarily the codes in use.

Alpine Team Event 1/8 Final 1	ALPXPLTEAM4-----------8FNL00010000
Alpine Team Event 1/8 Final 1 Run 1	ALPXPLTEAM4-----------8FNL00010001
Alpine Team Event 1/8 Final 1 Run 2	ALPXPLTEAM4-----------8FNL00010002
Alpine Team Event 1/8 Final 1 Run 3	ALPXPLTEAM4-----------8FNL00010003
Alpine Team Event 1/8 Final 1 Run 4	ALPXPLTEAM4-----------8FNL00010004
Alpine Team Event 1/8 Final 2	ALPXPLTEAM4-----------8FNL00020000
Alpine Team Event 1/8 Final 2 Run 1	ALPXPLTEAM4-----------8FNL00020001
Alpine Team Event 1/8 Final 2 Run 2	ALPXPLTEAM4-----------8FNL00020002
Alpine Team Event 1/8 Final 2 Run 3	ALPXPLTEAM4-----------8FNL00020003
Alpine Team Event 1/8 Final 2 Run 4	ALPXPLTEAM4-----------8FNL00020004
Four-man	BOBOTEAM4-------------------------
Four-man	BOBOTEAM4-------------FNL---------
Four-man Heat 1	BOBOTEAM4-------------FNL-000100--
Four-man Heat 2	BOBOTEAM4-------------FNL-000200--
Four-man Heat 3	BOBOTEAM4-------------FNL-000300--
Four-man Heat 4	BOBOTEAM4-------------FNL-000400--
Four-man Medal Ceremony	BOBOTEAM4-------------VICTMEDAL---
Men's Round Robin Session 1	CURMTEAM4-------------PREL000100--
Men's Round Robin Session 1	CURMTEAM4-------------PREL000101--
Men's Round Robin Session 1	CURMTEAM4-------------PREL000102--
Men's Round Robin Session 1	CURMTEAM4-------------PREL000103--
Men's Round Robin Session 1	CURMTEAM4-------------PREL000104--
Ind. Gund. LH/10km	NCBMLH10KM------------------------
Ind. Gund. LH/10km, Cross-Country	NCBMLH10KM------------FNL-0001CC--
Ind. Gund. LH/10km, Competition Round	NCBMLH10KM------------FNL-0001SJ--
Ind. Gund. LH/10km, Trial Round	NCBMLH10KM------------TRAL0001SJ--
Ind. Gund. LH/10km Off CC Trng	NCBMLH10KM------------TRNO0100CC--
Ind. Gund. LH/10km Off SJ Trng 1	NCBMLH10KM------------TRNO0100SJ--
Ind. Gund. LH/10km Off SJ Trng 1 Jump 1	NCBMLH10KM------------TRNO0101SJ--
Ind. Gund. LH/10km Off SJ Trng 1 Jump 2	NCBMLH10KM------------TRNO0102SJ--
Ind. Gund. LH/10km Off SJ Trng 1 Jump 3	NCBMLH10KM------------TRNO0103SJ—

10 Document Control

10.1File Reference

ODF/INT400 R-WOG-2018 V1.1 APP

10.2Version History

Version	Date	Comments
R-WOG-2018 V0.1 SFR	29 June 2015	First Version
R-WOG-2018 V0.2 SFR	9 Sept 2015	Minor Edits Changes applied to Rio Release
R-WOG-2018 V0.3 SFR	18 Dec 2015	Updates and clarifications
R-WOG-2018 V0.4 SFR	22 June 2016	Change Requests implemented
R-WOG-2018 V1.0 APP	23 Feb 2017	Change Requests and typographical corrections
R-WOG-2018 V1.1 APP	20 July 2017	Minor updates with more information

10.3Change Log

Version	Status	Changes
V0.1	SFR	N/A
V0.2	SFR	Change triggers in Curling (9.1.1.2) and added the changes for summer sports and Paralympics.
V0.3	SFR	Updated with changes from Rio version 1.9 at 3.1 and 5.15 3.1 – more details on empty/zero values (5^th dot point) 5.6 – Note to send DT_RESULT as LIVE as soon as unit starts (last paragraph).
V0.4	SFA	CR8927 remove serial in ODF messages. CR9036 add message invalidation (4.4) and change <Competition> element to optional (3.3.3.1). CR9943 changed the naming of back-up files (7.4) CR9994 Increase CompetitionCode in ODF Header (3.3.2)
V1.0	APP	CR14579 remove StartListMod from ODF Header (3.3.2) Corrected typographical error at 3.1 “Known optional ~~elements~~ attributes must always be sent unless there are special circumstances” Clarify that participants are included in DT_PARTIC regardless of status.
V1.1	APP	Updated Codes at 9.1.1 Add RSC Principles at Appendix 9.3