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.


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.



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.


The following abbreviations are used in this document



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.


An overall sporting meeting including one or more sports. For example the 2016 Olympic Games.


International Federation, the international governing body of a sport


Info Diffusion System, central technology system which manages many disciplines.


International Olympic Committee


International Paralympic Committee


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.


National Olympic Committee recognized as such by the IOC


National Paralympic Committee as recognized by the IPC


Olympic Data Feed


Olympic News Service


Olympic Results and Information Services


On-Venue Results system


Results System Codes, identify uniquely one unit of any competition, specifying the discipline, gender, event, phase and unit.


Gender has two meanings, gender of a person (man/women) or gender of an event (for men, women, mixed, any)


A group of units at the same level in an event, for example heats in Swimming, pool matches in Basketball or quarterfinals in tennis.


An individual part of an event, for example a single heat in Swimming, a match in Tennis or a bout in Boxing.


World News Press Agencies


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


This document describes the ODF messages

ODF Data Dictionaries (One per discipline)


This document details and extends the ODF messages described in ODF/INT184 for each sport

ODF Language Guidelines and Participant Names


This documents details the policies related to participant names.

ODF Codes Document


This document describes the ODF codes used across the ODF documents

ODF Schema


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


Team Sports

Timed and Judged Sports

Head to Head


Football / Ice Hockey

Aquatics / Skiing



Football / Ice Hockey

Swimming / Alpine Skiing







Men’s Tournament

200m Freestyle

Women’s Singles






Quarterfinal 1

Heat 5

Semifinal 2



·         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


·         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


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

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.







CC @Competition
[max. char(15)]

Unique ID for competition




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.




Extension for the DocumentCode

Used when the RSC is not sufficient to uniquely identify the content of the XML message.




Message Type (e.g. DT_RESULT)




Attribute used to extend DocumentType for some messages.




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)



CC @ResultStatus

Defines the status of the result included in the message.



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.





Test message or production message.




Date when the message is generated, expressed in the local time zone where the message was produced.




Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.




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.



CC @Source

Code indicating the system which generated the message.



<?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
<Note> Athlete nnnn disqualified…</Note>
</OdfBody>      <Competition> Element

All valid ODF messages contain the element <Competition>.

<Competition>      <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 “&lt;” & as “&amp;” > as  “&gt;” “ as “&quot;” and ‘ as &apos;. Any other character will not be escaped.


<Note>PEÑA Jorge (ESP)  &quot;reinstated&quot; after protest.</Note>      <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.









S(20) with no leading zeroes

Competitor ID



T, A, G

T = Team

A = Athlete

G = Group



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.

<Competitor Code= "878987" Type="A" Organisation="SUI">
<Athlete Code="878987" Order="1" Bib="10">
<Description GivenName="John" FamilyName="Smith" Gender="M" Organisation="SUI" BirthDate="1976-12-15" IFId="123423" />


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

<Competitor Code="T2145" Type="T" Organisation="SUI">
<Description TeamName="Switzerland"/>
<Athlete Code="4357627" Order="1">
<Description GivenName="Jane" FamilyName="Smith" Gender="W" Organisation="SUI" BirthDate="1976-12-15" IFId="123456" />
<Athlete Code="4333627" Order="2">
<Description GivenName="Jenny" FamilyName="Jones" Gender="W" Organisation="SUI" BirthDate="1976-09-15" IFId="123234" />

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">
<Athlete Code="1065564" Order="1" Bib="227" >
<Description GivenName="Jane" FamilyName="Smith" Gender="W" Organisation="SUI" BirthDate="1997-07-15" IFId="12345443" />
<Athlete Code="1087051" Order="2" Bib="219" >
<Description GivenName="Jenny" FamilyName="Jones" Gender="W" Organisation="ESP" BirthDate="1998-06-15" IFId="324522" />


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






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



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



Represents a digit used in the time element “day”

For the 5th of the  month:
in DD = 05
in D = 5
For the 15th of the  month:
in DD = 15
in D = 15



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



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



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


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


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.




Is used as UTC designator.




to separate the time elements “year”, “month” and “day”.




to separate the time elements “hour”, “minute” and “second”



3.4.2     Formats used in ODF

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


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.


Text strings without a predetermined length used in attributes without html


Text strings with a length of up to n characters





·       hh: hour

·       mm: minutes

·       ss: seconds

·       fff: milliseconds

All formatted with leading and trailing zeros (example: 090303020, 150712530).


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.


 ‘true’ or ‘false’


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 “&lt;” & as “&amp;” > as  “&gt;” “ as “&quot;” and ‘ as &apos;. 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.







































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.


Conversion Rules


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


1m/sec = 3.6km/hr

1km/h = 0.27777777778m/sec

1kt = 1nmi/h


1lbs = 0.453 592 37kg

1kg = 2.2046226218lbs


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

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.


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.


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


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:

<ExtendedInfo Type="EI" Code="INT_FED" Value="IAAF" >
<Extension Type="INT_FED" Code="CATEGORY" Value="OSG" />
<Extension Type="INT_FED" Code="EVENT_CODE" Value="7005" />
<SportDescription DisciplineName="Athletics" EventName="Men’s 100 metres" EventUnitName="Men’s 100 metres Final" Gender="M" />
<VenueDescription Venue="OLY" VenueName="Olympic Stadium" Location="STA" LocationName="Olympic Stadium"/>

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:

<UnitDateTime StartDate="2012-08-07T19:00:00+01:00" />
<ExtendedInfo Type="UI" Code="SPLIT_POINT" Pos="1" Value="2.20" />
<ExtendedInfo Type="UI" Code="SPLIT_POINT" Pos="2" Value="2.25" />
<ExtendedInfo Type="UI" Code="SPLIT_POINT" Pos="3" Value="2.29" />
<ExtendedInfo Type="UI" Code="SPLIT_POINT" Pos="4" Value="2.33" />
<ExtendedInfo Type="UI" Code="SPLIT_POINT" Pos="5" Value="2.36" />
<ExtendedInfo Type="UI" Code="SPLIT_POINT" Pos="6" Value="2.38" />
<ExtendedInfo Type="UI" Code="SPLIT_POINT" Pos="7" Value="2.40" />

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:






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


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

<ExtendedResult Type="ER" Code="SNATCH" Value="95" >
<Extension Code="ATTEMPT" Pos="1" Value="92" />
<Extension Code="ATTEMPT" Pos="2" Value="92" />
<Extension Code="ATTEMPT" Pos="3" Value="95" />
<Extension Code="ATTEMPT_VALID" Pos="1" Value="N" />
<Extension Code="ATTEMPT_VALID" Pos="2" Value="Y" />
<Extension Code="ATTEMPT_VALID" Pos="3" Value="Y" />
</ExtendedResult>    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.    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.    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.

<ExtendedResult Type="ER" Code="SNATCH" Value="95">
<Extension Code="IDX" Value="3" />
<Extension Code="ATTEMPT" Pos="1" Value="92" />
<Extension Code="ATTEMPT" Pos="2" Value="92" />
<Extension Code="ATTEMPT" Pos="3" Value="95" />
<Extension Code="ATTEMPT_VALID" Pos="1" Value="N" />
<Extension Code="ATTEMPT_VALID" Pos="2" Value="Y" />
<Extension Code="ATTEMPT_VALID" Pos="3" Value="Y" />
<ExtendedResult Type="ER" Code="CLEAN" Value="131">
<Extension Code="IDX" Value="1" />
<Extension Code="ATTEMPT" Pos="1" Value="125" />
<Extension Code="ATTEMPT" Pos="2" Value="131" />
<Extension Code="ATTEMPT" Pos="3" Value="135" />
<Extension Code="ATTEMPT_VALID" Pos="1" Value="Y" />
<Extension Code="ATTEMPT_VALID" Pos="2" Value="Y" />
<Extension Code="ATTEMPT_VALID" Pos="3" Value="N" />

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.





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

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





Document Code



Document Subcode



Document Type



Document Subtype






Message Logical Date



Message Date



Feed Flag





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)





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:


Result Status




Getting Ready



Add IRMs






Current Status






Current Status









Competition is over



Unconfirmed Phase Results



Unofficial Results



Unofficial Phase Results



Official Results



Official Phase Results






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:






A possible unit to be scheduled, not to be displayed by ODF users (e.g. swim-off)



Scheduled unit, expected to happen



Used when DT_RESULT includes start information



At time x (sport by sport) before start (see section 9.1.1 for full details).



Competition is underway (see section 9.1.1 for full details).



Planned break in competition (e.g. end of period)



Updated results at scheduled points or breaks in competition



All play is complete in the unit but not yet Unofficial nor Official



Results are unofficial, data is subject to change depending on sports rules (after filing a protest for instance)



Results are official, data is unlikely to change except in case of subsequent disqualification.



The start of the unit has been delayed



A scheduled unit has been cancelled (usually for meteorological reasons)



Unit to be moved to a later (unknown) time



Unit has been moved to a new later time (known time)



Play in the unit is unexpectedly stopped



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.



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.      Olympic and Paralympic Summer Sport Disciplines




Trigger for
‘Getting Ready’

Trigger for
‘Running’ / ‘Live’




First athlete/team entering the field of play

First athlete loads first arrow



100m Hurdles

Athletes lining up for initial presentation

Gunshot (clock begins)




Athletes positioning at the lanes

Gunshot (clock begins)




1 minute before the start

First athlete in position, ready to throw/jump




Athletes lining up for presentation, or approx. 2 minutes before competition when there is no presentation

First athlete in position, ready to jump




Most athletes already at the start, approx. 2 min before start of the race

Gunshot (clock begins)




Athletes lining up for presentation, or approx. 2 minutes before start when there is no presentation

First athlete in position, ready to throw




Athletes positioning at the lanes

Gunshot (clock begins)




Immediately before coin toss (approx. 3 minutes before competition)

First athlete/team ready to serve




Teams in formation to listen to their national anthems.

Referee throws the ball and first period clock begins




Athletes starting to line up at the start

Gates open




Athletes line-up before the start

First athlete throws the first ball.




First athlete comes through the tunnel

Round 1 clock starts


Road race


Most/all athletes already at the start, approx. 2 min before start of the race

Athletes pass the start line and clock begins


Time trial


First athlete getting into the start position, approx. 30 seconds before start

Clock begins for first athlete




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




Athletes already on their Canoes/Kayaks and approaching the start line

Referee signals the start of the race and clock begins


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)



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




Athletes lining up to be presented

First athlete on top of the springboard, ready to dive



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


Most events


First athlete enters the field of play

First athlete’s clock starts




Teams lining up to listen to the national anthems.

Referee blows his/her whistle




Referees and athletes/teams enter competition area

Referee signals the start of the match and clock begins countdown




Athletes lining up for presentation

First athlete starts performing at his/her apparatus




Teams lining up to listen to the national anthems.

Referee blows his/her whistle




When the first athlete is introduced on the first tee

First athlete hits the ball for the first time




First athlete enters the competition area

First athlete’s performance music begins




Athletes line up for presentation

First athlete climbs to the trampoline after warm up




Athletes line up for presentation

Referee’s whistle, and clock begins




Teams lining up for presentation

Referee’s whistle, and clock begins




Athletes line up at the entrance of the competition area, for presentation

Referee signals the start and clock begins the countdown.




Most athletes at the start, approx. 2 minutes before race begins

Race clock begins




Athletes line up for presentation

First athletes’ clock begins countdown




First athlete enters the field of play

First athlete’s clock begins




First group of athletes enter the pool area

Start signal for first group of athletes (and clock begins)




Most/all athletes already at the start, approx. 2 min before start of the race

Gunshot (clock begins)




Most athletes already at the starting platform, approximately 2 min before start of the race

Race clock begins




Athletes already on their Canoes/Kayaks and approaching the start line

Referee signals the start of the race and clock begins



Most phases

Athletes and their coaches at the start line or approaching it 

Count down (and clock begins)




Athletes on starting positions, waiting for presentation

Green light, and race clock begins




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




Signal warning that race will begin in 5 minutes time

Countdown for start of the race reaches 0.


Skeet, Trap


Athletes lining up for presentation

First disk for first athlete is on air


Rifle, pistol


Athletes lining up behind their pistols / rifles, for presentation

First targets appear and can be shot at




Athletes entering the pool area

Start signal (and clock begins)




First team/duet entering the pool area

First team/duet’s performance music begins




Athletes already practicing their service, during warm-up, approx. 2 minutes before match begins.

First athlete ready to serve




First athlete entering competition area

Referee signals the start and clock begins the countdown of the first period.




Most athletes already at the starting platform, approx. 2 min before start of the race

Race clock begins




Warm-up begins, approx. 2 minutes before the match

First athlete ready to serve




Athletes in their benches after warm up, waiting for presentation

First team ready to serve




Athletes in their benches after warm-up, waiting for presentation

First team ready to serve




Presentation of athletes

Referee signals the start of the match and clock begins countdown




First athlete enters field of play

First athlete starts lifting




Athletes lining up for presentation

Referee blows his/her whistle and athletes swim towards the ball




First athlete enters the competition area

Referee blows his/her whistle and first period’s clock begins




Teams in formation to listen to their national anthems.

Referee blows the whistle      Winter Sport Disciplines




Trigger for
‘Getting Ready’

Trigger for
‘Running’ / ‘Live’




First athlete in position, approx. 30 seconds before start

First athlete’s clock begins




The track test runs before the start are completed

BS/SN: countdown begins for athletes to start;

LG: first athlete grabs the start handles


Interval starts


First athlete in position, approx. 30 seconds before start

First athlete’s clock begins


Mass start


Most athletes at the start, approx. 1 minute before competition

Race clock begins


Interval starts


Same as BT for Interval start and pursuit

First athlete’s clock begins


Mass start


Same as BT for Mass start and Relay

Race clock begins




When the athletes march into the FoP.

When the Game time starts


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




Athletes positioning at the gates

Gates open




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




Teams lining up in front of each other before the start

First face-off takes place and first period clock begins


Big Air
Cross Qual.

All (except Cross, only Qual)

Like FR for these same events

First athlete leaves the gate (and clock begins, in Cross Qualification).


Cross Finals


Like FR for the same event

Gates open




First athlete(s) positioning at the gate(s)

Gates open




30 seconds before the start

First athlete starts going down the ramp



Ski Jumping

Same as in Ski Jumping events

First athlete starts going down the ramp



Cross Country

Same as CC pursuit events

First athlete’s clock begins




First athlete(s)/team(s) on track, waiting to be presented and then occupy their starting positions.

Gunshot (and clock begins)




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


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




Round of 128


Round of 64


Round of 32


1/8 Finals (Round of 16)










Team Managers / Team Captains meeting




Official Training


Unoffical Training / Training


Zeroing (BT)






Group x in Pools




Qualification / Ranking Round




Round 1


Round 2


Round 3


Round 4


Lucky Loser




Repechage Round 1


Repechage Round 2


High Jump (in Decathlon & Heptathlon)


1500m(in Decathlon)


Fencing Ranking Round (MP)


Fencing Bonus Round (MP)


Swimming (MP)


Combined (MP)


Equestrian (MP)


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


Alpine Team Event 1/8 Final 1 Run 1


Alpine Team Event 1/8 Final 1 Run 2


Alpine Team Event 1/8 Final 1 Run 3


Alpine Team Event 1/8 Final 1 Run 4


Alpine Team Event 1/8 Final 2


Alpine Team Event 1/8 Final 2 Run 1


Alpine Team Event 1/8 Final 2 Run 2


Alpine Team Event 1/8 Final 2 Run 3


Alpine Team Event 1/8 Final 2 Run 4






Four-man Heat 1


Four-man Heat 2


Four-man Heat 3


Four-man Heat 4


Four-man Medal Ceremony


Men's Round Robin Session 1


Men's Round Robin Session 1


Men's Round Robin Session 1


Men's Round Robin Session 1


Men's Round Robin Session 1


Ind. Gund. LH/10km


Ind. Gund. LH/10km, Cross-Country


Ind. Gund. LH/10km, Competition Round


Ind. Gund. LH/10km, Trial Round


Ind. Gund. LH/10km Off CC Trng


Ind. Gund. LH/10km Off SJ Trng 1


Ind. Gund. LH/10km Off SJ Trng 1 Jump 1


Ind. Gund. LH/10km Off SJ Trng 1 Jump 2


Ind. Gund. LH/10km Off SJ Trng 1 Jump 3




10 Document Control

10.1File Reference

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

10.2Version History




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









Change triggers in Curling ( and added the changes for summer sports and Paralympics.



Updated with changes from Rio version 1.9 at 3.1 and 5.15

3.1 – more details on empty/zero values (5th dot point)

5.6 – Note to send DT_RESULT as LIVE as soon as unit starts (last paragraph).



CR8927 remove serial in ODF messages.

CR9036 add message invalidation (4.4) and change <Competition> element to optional (

CR9943 changed the naming of back-up files (7.4)

CR9994 Increase CompetitionCode in ODF Header (3.3.2)



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.



Updated Codes at 9.1.1

Add RSC Principles at Appendix 9.3