Text Box: Olympic Data Feed

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

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

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

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

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

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

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

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

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

Table of Contents

1 Introduction 6

1.1.. About ODF. 6

1.2.. Development of ODF. 6

1.3.. Scope. 7

1.4.. Objective. 7

1.5.. Main Audience. 7

1.6.. Project Governance. 7

1.7.. Background. 7

1.8.. What ODF isn’t 8

1.9.. Change Management 8

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

1.11 Glossary. 9

1.12 Documentation. 10

1.13 Language and Translation. 10

2 Understanding Sports Competitions 11

2.1.. Understanding Competitions. 11

2.2.. Messages and Data available. 13

3 Message Definition 14

3.1.. Introduction. 14

3.2.. Encoding. 14

3.3.. ODF Message Structure. 14

3.4.. ODF Data Types and Formats. 23

4 Message Operation and Use 28

4.1.. Message generation systems. 28

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

4.3.. Message Serialization. 28

4.4.. Message Frequency and Triggers. 29

5 Key Data Messages 30

5.1.. Participants. 30

5.2.. Teams. 31

5.3.. Horses. 31

5.4.. Schedule. 32

5.5.. Configuration. 33

5.6.. Results. 33

5.7.. Phase Results. 33

5.8.. Cumulative Results. 34

5.9.. Pools. 34

5.10 Brackets. 34

5.11 Event Ranking. 34

5.12 Medals. 35

5.13 Statistics. 35

5.14 Play by Play. 35

5.15 Current Data. 36

5.16 Official Communications. 36

6 Principles Used 37

6.1.. Codes. 37

6.2.. RSC Level 37

6.3.. ExtendedInfos. 37

6.4.. Competitor unique identifiers. 38

6.5.. Participant Names. 38

6.6.. Mandatory and Optional Elements/Attributes. 39

6.7.. Empty values and updates. 39

6.8.. Ordering and Timing of messages. 40

6.9.. Sorting within Messages. 40

6.10 Which messages to process?. 41

6.11 Message Source in the Header 41

6.12 Use of an Explanatory Information Element 41

6.13 Results Status. 42

6.14 Extensions. 43

6.15 Cumulative Messages, not all athletes progress. 46

6.16 Positive and Negative Tags. 46

6.17 Single athlete competing multiple times. 46

6.18 Teams of Teams. 46

6.19 ODF Message Overwrite. 47

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

7 Message Transmission 49

7.1.. Options for Transmission. 49

7.2.. Online HTTP Message Transmission. 49

7.3.. Backup and Recovery. 51

7.4.. Alternate Transmission Methods. 53

8 Sequence of Messages 54

9 Appendices 55

9.1.. Schedule and Results Status. 55

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

10 Document Control 62

10.1 File Reference. 62

10.2 Version History. 62

10.3 Change Log. 63

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.10 Programme of the Olympic Games (excerpt from the Olympic Charter)

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

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

The sports are those sports governed by the IFs.

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

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

1.11 Glossary

The following abbreviations are used in this document

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

1.12 Documentation

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

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

Some of these documents may vary from competition to competition.

1.13 Language 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/INT190]).

The default language for all ODF messages is English.

When multiple languages are used:

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

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

When only English is used:

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

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

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

2 Understanding Sports Competitions

2.1 Understanding Competitions

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

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

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

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

2.1.1 Basic Competition Hierarchy

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

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

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

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

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

Notes:

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

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

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

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

2.2 Messages and Data available

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

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

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

· News and informational messages

· Biographies

o Athletes

o Coaches

o …

· Records

· Weather

· Participant Lists

· Schedules

· Results

o Units

o Phases

o PDF

· Extended Results

o Results Analysis

o Current Information

o Images

o Records

o Statistics

o Play-by-Play

· Medal information

o By Event

o By Sport

o …

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

3 Message Definition

3.1 Introduction

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

Some important considerations for the ODF messages:

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

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

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

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

· Known optional elements must always be sent (e.g.Place of Birth).

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

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

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

· The order of attributes is not important.

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

3.2 Encoding

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

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

3.3 ODF Message Structure

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

ODF messages are data structures based on standard XML:

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

3.3.1 ODF Declaration

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

3.3.2 ODF Header

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

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

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

· CompetitionCode

· DocumentCode

· DocumentSubcode

· DocumentType

· DocumentSubtype

· Source

· Version

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

Attribute	M/O	Value	Comment
CompetitionCode	M	CC @Competition	Unique ID for competition
DocumentCode	M	S(9)	DocumentCode can have different values depending on the nature of the message. RSC is used for Results messages and is structured as DDGEEEPUU, where · DD=discipline; · G=discipline gender; · EEE=event; · P=phase; · UU-unit The other possible values include (depending on the message) the ID of an athlete (for biographies), sequential numbers (for background imports) etc. Full details are documented in the ODF General Data Dictionary.
DocumentSubcode	O	S(20)	Extension for the DocumentCode Used when the 9 characters of the RSC are not sufficient to uniquely identify the content of the XML message.
DocumentType	M	S(30)	Message Type (e.g. DT_RESULT)
DocumentSubtype	O	S(20)	Attribute used to extend DocumentType for some messages.
Version	M	1..V	Version of the message, sequential number with the highest indicating the most recent version. Increments when the unique identifier fields without version are the same. (Positive integer)
ResultStatus	O	CC @ResultStatus	Defines the status of the result included in the message.
Language	O	CC @Language	Language used for message content. If the message is distributed in multiple languages then this attribute should always be included. Where a message is not defined in multiple languages, this attribute must not be included. In this case of a single language then the language of the message is English.
FeedFlag	M	“P”-Production “T”-Test	Test message or production message.
Date	M	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	M	Time	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	M	Date	Logical Date of events. This is the same as the physical day except when the unit or message transmission extends after midnight. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the message will all be dated Aug 2). The end of the logical day is defined by default at 03:00 a.m. For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the day of the correction. Logical Date is expressed in the local time zone where the message was produced.
Source	O	CC @Source	Code indicating the system which generated the message.
StartListMod	O	S(1)	For DT_RESULT only. Send Y if the start list has been changed with this message and the ResultStatus is not START_LIST. Do not send the attribute if it is not Y. Only send once for each start list change. In this case the full current message is sent with whatever is the current ResultStatus. The Start List is considered to be changed if any of the following changes: · Competitors or athletes are added, changed or removed including in <UnifInfos> · Any change in <Officials> · Any change in StartOrder or StartSortOrder · Any changes in <Coaches> · Any changes in <EventUnitEntry>
Serial	M	Numeric	Sequence number (positive integer) for ODF messages. Serial starts with 1 each day for each Source.

Sample

<?xml version="1.0" encoding="utf-8"?>
<OdfBody CompetitionCode="OG2012" DocumentCode="JUM200101" DocumentType="DT_RESULT" Version="3" ResultStatus="OFFICIAL" FeedFlag="P" Date="2012-08-03" Time="162843056" LogicalDate="2012-08-03" Source="AT1" Serial="649">
……

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 Code= …>                    Message Body
     …
   </Competition>
<Note> Athlete nnnn disqualified…</Note>
</OdfBody>

3.3.3.1 <Competition> Element

All ODF messages contain a mandatory element <Competition>.

Element

Attribute

M/O

Value

Comment

Competition

Code

CC @Competition

Unique ID for the competition.

Note: Code is deprecated as the information also appears in the header. It will be removed after Rio.

3.3.3.2 <Note> Element

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

<Note> element follows the <Competition> element.

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

3.3.3.3 <Competitor> Element

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

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

If Competitor is an Athlete:

· <Competitor> element contains:

o The mandatory attribute Type = ”A”;

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

o The attribute Organisation provides the organisation of the athlete;

o The mandatory element <Composition>.

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

· <Athlete> element contains:

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

o The mandatory attribute Order =”1”;

o The optional attribute Bib;

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

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

· <Description> element contains:

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

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

o The mandatory attribute Gender;

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

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

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

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

If Competitor is a Team:

· <Competitor> element contains;

o The mandatory attribute Type =”T”;

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

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

o The attribute Organisation provides the organisation of the team;

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

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

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

· <Description> element contains:

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

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

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

· <Athlete> element contains:

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

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

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

o The optional attribute Bib;

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

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

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

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

· <Competitor> element contains

o the mandatory attribute Type = ”G”

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

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

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

3.4 ODF Data Types and Formats

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

3.4.1 Format Strings

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

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

3.4.2 Formats used in ODF

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

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

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

3.4.3 Common Number and Time formats

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

Measure

Format

Example

Height/Distance

#0.00m

##0cm

#’#0’’

1.83m

183cm

6’0’’

Weight

##0kg

##0lbs

100kg

220lbs

Temperature

#0ºC

##0ºF

35ºC

95ºF

Distance

#0.000km

#0.000mi

1.789km

6.123mi

Speed

#0.000m/s

#0.000mph

#0.000km/h

1.789m/s

6.123mph

3.890km/h

Precipitation

#0mm

#0in

2mm

1in

3.4.4 Rules for measurement conversion

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

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

3.4.5 Rules for rounding numbers

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

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

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

3.4.6 Decimals and separators

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

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

For example

· 65.43

· 1003.45

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

4 Message Operation and Use

4.1 Message generation systems

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

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

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

4.2 Competition Day, Start and Stop Transmission

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

· start the transmission with a DT_LOCAL_ON message and;

· end the transmission with a DT_LOCAL_OFF message.

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

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

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

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

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

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

4.3 Message Serialization

Every message has a serial number in the header. Each system that generates ODF messages serializes its own messages. For the Olympic Games, this means serial numbers are generated both at the venues and at the IDS central systems. Different disciplines or OVR systems will have independent serial numbers.

Serial numbers are reset to “1” at the start of each logical day in for each Source.

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.

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

5.7 Phase Results

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

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

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

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

5.8 Cumulative Results

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

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

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

5.9 Pools

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

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

5.10 Brackets

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.11 Event Ranking

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

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

5.12 Medals

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

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

5.13 Statistics

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.14 Play 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.15 Current 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 only used in a small number of sports and is generally used for:

· Server information;

· Score in team sports;

· Clock information in team sports;

· Speed Information;

· Previous 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.16 Official Communications

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

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

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

6 Principles Used

6.1 Codes

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

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

6.2 RSC Level

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

6.3 ExtendedInfos

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

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

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

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

Qualification rules and progression rules may also be included here.

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

A sample for high jump follows:

6.4 Competitor unique identifiers

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

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

6.5 Participant Names

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

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

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

6.6 Mandatory and Optional Elements/Attributes

The intent of the terms Mandatory and Optional are:

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

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

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

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

6.7 Empty values and updates

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

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

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

6.8 Ordering and Timing of messages

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

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

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

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

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

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

o DT_CURRENT

o DT_RESULT

o DT_PLAY_BY_PLAY

o DT_CUMULATIVE_RESULT

o DT_PHASE_RESULT

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

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

6.9 Sorting within Messages

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

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

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

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

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

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

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

6.10 Which 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.11 Message 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.12 Use of an Explanatory Information Element

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

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

· Some parts of the message have been significantly changed.

· An athlete has been disqualified and the message provides details

Example:

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

6.13 Results 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 Extensions

6.14.1 Use of extensions

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

6.14.2 Content of extensions

Each extension has three attributes:

· Code

· Pos

· Value

Code is mandatory. Pos and Value are optional.

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

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

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

6.14.2.1 Code

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

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

6.14.2.2 Pos

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

6.14.2.3 Value

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

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

Values generally fall into one of three general types:

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

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

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

6.14.3 Ignoring extensions

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

6.14.4 Extension Hierarchy

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

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

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

6.14.5 Selecting extensions

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

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

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

6.15 Cumulative 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.16 Positive 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.17 Single 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.18 Teams 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.19 ODF Message Overwrite

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

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

1. CompetitionCode

2. DocumentCode

3. DocumentSubcode

4. DocumentType

5. DocumentSubtype

6. Source

7. Version

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

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

· DT_SCHEDULE_UPDATE

· DT_PARTIC_UPDATE

· DT_PARTIC_TEAMS_UPDATE

· DT_PARTIC_HORSES_UPDATE

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

6.20 Guides, 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 where an athlete is entitled to have two guide-runners. Both guides should be captured through sports entries and attributed to the athlete and transferred to OVR. NPCs can drop one of them at the final confirmation, then the remaining guide may be eligible for a medal. If both are confirmed, then neither will be eligible for a medal.

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

Following from this:

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

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

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

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

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

7 Message Transmission

7.1 Options for Transmission

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

7.1.1 At the Olympic and Paralympic Games

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

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

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

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

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

7.2 Online HTTP Message Transmission

7.2.1 Connectivity

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

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

7.2.2 HTTP Usage

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

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

<?xml version="1.0" encoding="utf-8"?>
<OdfBody CompetitionCode="LOCOG" DocumentCode="BV0000000" DocumentSubcode="GENERAL" DocumentType="DT_PARTIC_UPDATE" FeedFlag="T" Date="2012-08-11" Time="121537867" LogicalDate="2012-08-11" Version="1" Serial="1">
   <Competition Code="LOCOG">
     <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="BV">
           <RegisteredEvent Gender="M" Event="400" Bib="">
              <EventEntry Code="CAPTAIN" Value="N" Type="E_ENTRY" />
              <EventEntry Code="POSITION" Value="L" Type="E_ENTRY" Pos="1"/>
              <EventEntry Code="POSITION" Value="B" Type="E_ENTRY" Pos="2"/>
              <EventEntry Code="SHIRT_NAME" Value="HERRERA" Type="E_ENTRY" />
           </RegisteredEvent>
        </Discipline>
     </Participant>
   </Competition>
</OdfBody>

The above example assumes the following:

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

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

· The message payload will contain the ODF message.

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

HTTP/1.1 200 OK

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

7.2.3 Expected Results

HTTP Response will be expected from the ODF users.

7.3 Backup and Recovery

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

ODF users can detect missing messages using Serial and 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=CM0000000&DocumentType=DT_PDF&DocumentSubtype=C67&FeedFlag=P.

7.3.2 Automatic Resend

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

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

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

http://bifserver/resend?DocumentCode=CM0000000&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. Such a scheme could include:

· Eight characters for the Logical Date

· Nine characters for Document Code

· Ten characters for Document Subcode

· Thirty characters for Document Type

· Twenty characters for Document Subtype

· Five characters for version

· One character for Feed Flag

· Three characters for language

· Ten characters for date (yyyy-mm-dd)

· Nine characters for time (hhmmssnnn)

· Three character for uniqueness

Eg:

20120820ATM010101__________DT_RESULT_________________________________________00001PENG2012-08-20100927351000.xml

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

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

8 Sequence of Messages

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

8.1.1 Standard Sequence

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

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

9 Appendices

9.1 Schedule and Results Status

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

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

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

The full and comparative list is as follows:

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

9.1.1 Triggers for ‘Getting Ready’ & ‘Running’

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

9.1.1.1 Olympic and Paralympic Summer Sport Disciplines

Discipline	Event	Phase	Trigger for ‘Getting Ready’	Trigger for ‘Running’ / ‘Live’
AR pAR	All	All	First athlete/team entering the field of play	First athlete loads first arrow
AT pAT	Track	All	Athletes positioning at the lanes	Gunshot (clock begins)
AT pAT	Jumps	All	Athletes lining up for presentation, or approx. 2 minutes before competition when there is no presentation	First athlete in position, ready to jump
AT pAT	Throws	All	Athletes lining up for presentation, or approx. 2 minutes before start when there is no presentation	First athlete in position, ready to throw
AT	Decathlon Heptathlon	100m 100m Hurdles	Athletes lining up for initial presentation	Gunshot (clock begins)
AT	Decathlon Heptathlon	Track	Athletes positioning at the lanes	Gunshot (clock begins)
AT	Decathlon Heptathlon	Field	1 minute before the start	First athlete in position, ready to throw/jump
AT pAT	Road	All	Most athletes already at the start, approx. 2 min before start of the race	Gunshot (clock begins)
BD	All	All	Immediately before coin toss (approx. 3 minutes before competition)	First athlete/team ready to serve
BK WB	All	All	Teams in formation to listen to their national anthems.	Referee throws the ball and first period clock begins
BO	All	All	Athletes line-up before the start	First athlete throws the first ball.
BV	All	All	Athletes in their benches after warm up, waiting for presentation	First team ready to serve
BX	All	All	First athlete comes through the tunnel	Round 1 clock starts
CB	All	All	Athletes starting to line up at the start	Gates open
pCA	All	All	Athletes already on their Canoes/Kayaks and approaching the start line	Referee signals the start of the race and clock begins
CF	All	All	Athletes already on their Canoes/Kayaks and approaching the start line	Referee signals the start of the race and clock begins
CM	All	All	Most/all athletes already at the start, approx. 2 min before start of the race	Gunshot (clock begins)
CR	Road race	All	Most/all athletes already at the start, approx. 2 min before start of the race	Athletes pass the start line and clock begins
CR	Time trial	All	First athlete getting into the start position, approx. 30 seconds before start	Clock begins for first athlete
CS	All	All	Athlete getting to the position from where he will later speed up towards the start line, approx. 30 seconds before the start.	Athlete crosses the start line and clock begins
CT	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)
CT	Omnium	Points Race, Elimination Race, Scratch Race	Athletes ready for the initial speeding up lap	First athlete crosses the start line and laps start to be counted
pCT	All	Most phases	Athletes and their coaches at the start line or approaching it	Count down (and clock begins)
DV	All	All	Athletes lining up to be presented	First athlete on top of the springboard, ready to dive
EQ pEQ	Most events		First athlete enters the field of play	First athlete’s clock starts
EQ	Eventing	Cross Country	First athlete approaching the position from where he will speed up towards the start line, approx. 30 seconds before the start.	First athlete crosses the start line and his clock begins
FB pFB FT	All	All	Teams lining up to listen to the national anthems.	Referee blows his/her whistle
FE	All	All	Referees and athletes/teams enter competition area	Referee signals the start of the match and clock begins countdown
GA	All	All	Athletes lining up for presentation	First athlete starts performing at his/her apparatus
GB	All	All	Teams lining up to listen to the national anthems.	Referee blows his/her whistle
GO	All	All	When the first athlete is introduced on the first tee	First athlete hits the ball for the first time
GR	All	All	First athlete enters the competition area	First athlete’s performance music begins
GT	All	All	Athletes line up for presentation	First athlete climbs to the trampoline after warm up
HB	All	All	Athletes line up for presentation	Referee’s whistle, and clock begins
HO	All	All	Teams lining up for presentation	Referee’s whistle, and clock begins
JU pJU	All	All	Athletes line up at the entrance of the competition area, for presentation	Referee signals the start and clock begins the countdown.
MP	Fencing	Fencing	Athletes line up for presentation	First athletes’ clock begins countdown
MP	Swimming	Swimming	First group of athletes enter the pool area	Start signal for first group of athletes (and clock begins)
MP	Riding	Riding	First athlete enters the field of play	First athlete’s clock begins
MP	Combined	Combined	Most athletes at the start, approx. 2 minutes before race begins	Race clock begins
OW	All	All	Most athletes already at the starting platform, approximately 2 min before start of the race	Race clock begins
RO pRO	All	All	Athletes on starting positions, waiting for presentation	Green light, and race clock begins
RU	All	All	Athletes entering field of play (this is about 1 minute before match begins, as there are no anthems or athletes’ presentations)	Referee blows the whistle
SA pSA	All	All	Signal warning that race will begin in 5 minutes time	Countdown for start of the race reaches 0.
SH	Skeet, Trap	All	Athletes lining up for presentation	First disk for first athlete is on air
SH pSH	Rifle, pistol	All	Athletes lining up behind their pistols / rifles, for presentation	First targets appear and can be shot at
SW pSW	All	All	Athletes entering the pool area	Start signal (and clock begins)
SY	All	All	First team/duet entering the pool area	First team/duet’s performance music begins
TE WT	All	All	Athletes already practicing their service, during warm-up, approx. 2 minutes before match begins.	First athlete ready to serve
TK	All	All	First athlete entering competition area	Referee signals the start and clock begins the countdown of the first period.
TR pTR	All	All	Most athletes already at the starting platform, approx. 2 min before start of the race	Race clock begins
TT wTT	All	All	Warm-up begins, approx. 2 minutes before the match	First athlete ready to serve
VO VS	All	All	Athletes in their benches after warm-up, waiting for presentation	First team ready to serve
WL PO	All	All	First athlete enters field of play	First athlete starts lifting
WP	All	All	Athletes lining up for presentation	Referee blows his/her whistle and athletes swim towards the ball
WR	All	All	First athlete enters the competition area	Referee blows his/her whistle and first period’s clock begins
WF	All	All	Presentation of athletes	Referee signals the start of the match and clock begins countdown
pWR	All	All	Teams in formation to listen to their national anthems.	Referee blows the whistle

9.1.1.2 Winter Sport Disciplines

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

9.2 Information for providers wanting to extend ODF

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

10 Document Control

10.1 File Reference

ODF/INT183 R-SOG-2016 V1.9 APP

10.2 Version History

Version	Date	Comments
R4 V1.0 SFR	21 June 2013	First Version
R4 V1.1 SFA	25 Sept 2013	Updated after comments from ODF working group
R4 V1.2 SFA	5 Nov 2013	Updated after ODF meeting and additional comments
R4 V1.3 APP	16 Dec 2013	Updated after final review by ODF working group
R4 V1.4 APP	15 Jan 2014	Updated with minor corrections and editing.
R4 V1.5 APP	28 March 2014	Replace Venue in the Header with Source and other minor clarifications.
R4 V1.6 APP	29 Sept 2014	Updated to match CR3853 and other clarifications.
R4 V1.7 APP	12 Feb 2015	Minor Clarifications
R4 V1.8 APP	1 Oct 2015	Triggering Updates CR7478 Approved
R4 V1.9 APP	14 Dec 2015	Clarified DT_CURRENT message

10.3 Change Log

Version	Status	Changes
R4 V1.0	SFR	N/A
R4 V1.1	SFA	Complete update after comments from ODF group
R4 V1.2	SFA	Major rework after comments
R4 V1.3	APP	Final Update
R4 V1.4	APP	Corrected typographical error at 3.3.3.3 3.3.3.3 <Competitor> Element ….. If the Competitor is a Team <Competitor> element contains …. The attribute Organisation provides the organisation of the ~~athlete~~team; Removed the former section 6.4 UnitInfo / PhaseInfo / EventInfo and moved the content to 6.3 (ExtendedInfo) to consolidate in one “Info” section. Changed the document attributes in Competition Element at 3.3.3.1 to codes from stings to make them consistent. Added a note in Re-Send (7.3.3) to state all files meeting the criteria will be resent. Other editing without affecting the meaning of the content.
R4 V1.5	APP	Replace Venue with Source in the Header with related changes at 3.3.2, 4.3, 6.10 and 6.18. 5.2 Clarify that teams usually comprise athletes from a single organisation (always in the case of the Olympic Games). 5.3 Update to explain which sports use which horse messages. 6.5 Clarify names use in teams and horses messages. 6.9.1 Clarify that the principle also applies for teams and horses. 6.12.7 Section added to explain PARTIAL ResultStatus. Various typographical errors fixed without changing meaning.
R4 V1.6	APP	3.3.3.1 Remove document versions in the <Competition> element, for consideration for 2018 as these were incorrectly added. 5.7 Add a paragraph regarding the use of qualifying marks in DT_PHASE_RESULT. Added a paragraph on sorting within messages at 6.9. Added a paragraph regarding Paralympic Guides at 6.20. Added new ResultStatus “PROTESTED” as per CR4203 at 9.1. Updated the descriptions of the DT_PHASE_RESULT and DT_CUMULATIVE_RESULT (5.7 & 5.8) Update section 7.3 with the changes from the strategic gap in Rio. FTP backup has been removed.
R4 V1.7	APP	5.4.1 Description of the schedule message to clarify that the initial message includes all units in a discipline which the _UPDATE message should only include units with additions and changes. 5.8 Cumulative Results updated to note the use of the cumulative message for cases where the best performance is used in addition to the more common use where the accumulated result is used. 9.1.1.1 Getting Ready trigger changed in SA to be 5 minutes before the start (aligned with countdown) Other minor editorial changes without changing the implementation of ODF. Corrected the triggering at 4.4 related to maximum OVR message frequency.
R4 V1.8	APP	9.1.1.1 Triggers added for OW (was missing) 9.1.1 Triggers added for the Paralympics CR7478 – Change DocumentSubcode to S(20)
R4 V1.9	APP	3.1 Clarify the description of full messages 5.15 Clarify the use and content of DT_CURRENT