This document includes the ODF Bobsleigh Data Dictionary. This document refines the messages described in the ODF General Messages Interface Document specifically for Bobsleigh, as well as defines the codes used in these messages.

1.2 Objective

The objective of this document is to provide a complete and formal definition of the ODF Bobsleigh Data Dictionary, with the intention that the information message producer and the message consumer can successfully interchange the information as the Bobsleigh competition is run.

1.3 Main Audience

The main audience of this document is the IOC as the ODF promoter, ODF users such as the World News Press Agencies, Rights Holding Broadcasters and International Sports Federations.

1.4 Glossary

The following abbreviations are used in this document

Acronym	Description
IF or International Federation	The international governing body of an Olympic Sport as recognized by the IOC
IOC	International Olympic Committee
IPC	International Paralympic Committee
NOC	National Olympic Committee recognized as such by the IOC
NPC	National Paralympic Committee as recognized by the IPC
ODF	Olympic Data Feed
ODF Light	It is a type of ODF message that includes extensions to standard ODF messages in order to resolve references between messages and common codes. These extensions facilitate the message processing for ODF customers
ODF-PiT	Olympic Data Feed Point in Time, messages that are generated at certain point during competition
ODF-RT	Olympic Data Feed Real Time, messages that are generated when available
OPNS	Olympic and Paralympic News Service
RSC	Results System Codes, determine uniquely one unit of the competition, specifying the discipline, gender, event, phase and unit.
Sport	is administered by an international federation and can be composed of one or more disciplines
WNPA	World News Press Agencies

1.5 Related Documents

Document Reference	Document Title	Document Description
ODF/INT001	ODF Message Transmission Document	This document describes the technical standards to be used to transfer ODF messages between the message generators and the final ODF users
ODF/COD001	ODF Common Codes Document	This document describes the ODF codes used across the rest of the ODF documents
ODF/INT004	ODF General Messages Interface Document	This document describes the ODF general messages

2 Overall Perspective

2.1 Objective

The objective of this document is to focus on the formal definition of the ODF Bobsleigh Data Dictionary.

2.2 End to End data flow

In the following chapters, for each ODF message the general description, header values, triggers and frequency, structure, values and sort of the message will be defined.

3 Messages

3.1 Applicable Messages

The following table is a full list of all ODF messages and describes the list of messages used in this sport.

• The column “Message type” indicates the DocumentType that identifies a message

• The column “Message name” is the message name identified by the message type

• The column “Feed” identifies the message feed (PiT for Point in Time messages, RT for Real Time messages and PDF for PDF messages)

• The column “Message extended in this document” indicates whether a particular message has extended definition in regards to those that are general for all sports. If one message has extended definition, it should be considered both, the extensions as well as the general rules for one message that is used in the case of the sport. However, if one particular message is not extended, then it should follow the general definition rules.

Message Type	Message Name	Feed	Message extended
DT_SCHEDULE	Competition schedule	PiT
DT_SCHEDULE_UPDATE	Competition schedule update	PiT
DT_PARTIC / DT_PARTIC_UPDATE	List of participants by discipline / List of participants by discipline Update	PiT	X
DT_PARTIC_TEAMS / DT_PARTIC_TEAMS_UPDATE	List of teams / List of teams update	PiT	X
DT_MEDALS	Medal standings	PiT
DT_MEDALLISTS_DAY	Medallists of the day	PiT
DT_GLOBAL_GM	Global good morning	PiT
DT_GLOBAL_GN	Global good night	PiT
DT_START_LIST	Start List	PiT	X
DT_RESULT	Event Unit Results	PiT/RT	X
DT_CUMULATIVE_RESULT	Cumulative Results	PiT/RT	X
DT_RANKING	Event Final Ranking	PiT	X
DT_MEDALLISTS	Event’s Medallists	PiT	X
DT_MEDALLISTS_DISCIPLINE	Medallists by discipline	PiT
DT_COMMUNICATION	Official Communication	PiT
DT_GM	Discipline/venue good morning	PiT
DT_GN	Discipline/venue good night	PiT
DT_CONFIG	Discipline Configuration	PiT	X
DT_WEATHER	Event Unit Weather Conditions	PiT	X
DT_SERIAL	List of Current PiT Serial	PiT
DT_RT_KA	RT Discipline/Venue keep alive	RT
DT_PDF	PDF Message	PDF
DT_PDF_GM	PDF Discipline/Venue good morning	PDF
DT_PDF_GN	PDF Discipline/Venue good night	PDF
DT_PDF_SERIAL	List of Current PDF Serial	PDF
DT_RT_GM	RT Discipline/venue good morning	RT
DT_RT_GN	RT Discipline/venue good night	RT

3.2 Messages

3.2.1 List of participants by discipline / List of participants by discipline Update

3.2.1.1 Description

A participant is considered as an individual competitor (type athlete, participating or not in the current games) or as an official in one or several disciplines or as a competitor being part of a team (team member).

Although the participant participates in more than one event or more than one discipline, this message just contains all the information for the discipline of the message, although listing the information of all the events for that discipline.

This message includes historical athletes that do not participate in the current competition. Historical athletes will not be registered to any event.

It is important to point out that all the sport messages that make references to athletes (start list, event unit results, etc.) will always match the athlete ID with the athlete ID as it is being sent in the List of athletes by discipline message. The historical athletes will be used to match historical athlete information as it is in the records message when sending the previous record information and this previous record was an historical record not being broken in the current competition.

This message also includes the historical team members of the historical teams’ messages. It could happen these historical athletes would appear in this message just for this reason (being part of historical teams).

List of participants by discipline (DT_PARTIC) is a bulk message, provided for each discipline. It is a complete participant information message for one particular discipline. The arrival of this message resets all the previous participants’ information for one particular discipline. This message can include a list of current athletes, officials, coaches, guides, technical officials, Reserves and historical athletes.

List of participants by discipline update (DT_PARTIC_UPDATE) is an update message. It is not a complete list of participants’ information by discipline message, only the participant data being modified, i.e. if some data of one participant changes, the element Participant for it with all its children and attributes must mbe sent.

The key of the information updated consists of the following attribute: Participant @Code. Therefore, any new or updated Participant Discipline-Event will be identified by all these attributes.

3.2.1.2 Header Values

3.2.1.2.1 PiT Header

The following table describes the ODF header attributes

Attribute	Value	Comment
DocumentCode	DD0000000	DD is defined according to CC @Discipline
DocumentType	DT_PARTIC / DT_PARTIC_UPDATE	List of participants by discipline message
Version	1..V	Version number associated to the message’s content. Ascendant number
FeedFlag	“P”-Production “T”-Test	Test message or production message.
Date	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	MillisTime	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	Date	Logical Date of events that extends until next day. 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 output will 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 correction. Logical Date is expressed in the local time zone where the message was produced
Serial	Numeric	Sequence number for ODF-PiT messages. Serial starts with 1 each day session at every different venue. In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information
Venue	CC @VenueCode	Venue where the message is generated.

3.2.1.3 Trigger and Frequency

3.2.1.3.1 PiT Triggers

The DT_PARTIC message is sent as a bulk message one month before the Games. It is sent several times up to the date from what only DT_PARTIC_UPDATE messages are sent.

The DT_PARTIC_UPDATE message is triggered when there is a modification in a DT_PARTIC bulk message sent before.

3.2.1.5 Message Values

Competition

Attribute	M/O	Value	Comments
Code	M	CC @Competition	Unique ID for competition

Participant

Attribute	M/O	Value	Comments
Code	M	S(20) with no leading zeroes	Participant’s ID. It identifies an athlete or an official and the holding participant’s valid information for one particular period of time. It is used to link other messages to the participant’s information. Participant’s information (example @Organisation) will not be the latest for the athlete/official, unless the @Code attribute is the same as the @Parent attribute. However, this information could be the one being valid in the particular moment of a start list, event unit results, etc. When the participant is an historical one, then this ID will start with “A” when it is an Athlete, “C” when Coach and “O” when Official.
Parent	M	S(20) with no leading zeroes	Participant’s parent ID, which is used to link to the latest valid information for one participant. @Parent attribute should be linked to the latest participant‘s information, by retrieving that Athlete/Official whose @Code attribute is the same as @Parent. The participant containing @Code attribute being the same as the @Parent attribute will be the one with the latest information for the participant. The @Parent attribute will only be different from @Code in the case that critial personal information has changed from previous competitions. The typical examples are Organisation (for change of country) or Name (particularly for women changing their name at marriage). Further to be clear, @Parent and @Code can only be different if Current = "false".
Status	O	CC @AccreditationStatus	Participant’s accreditation status this atribute is Mandatory in the case of @Current=”true” and it is optional in the case that @Current=”false”. To delete a participant, a specific value of the Status attribute is used.
GivenName	O	S(25)	Given name in WNPA format (mixed case)
FamilyName	M	S(25)	Family name in WNPA format (mixed case)
PrintName	M	S(35)	Print name (family name in upper case + given name in mixed case)
PrintInitialName	M	S(18)	Print Initial name (for the given name it is sent just the initial, without dot)
TVName	M	S(35)	TV name
TVInitialName	M	S(18)	TV initial name
Gender	M	CC @PersonGender	Participant’s gender
Organisation	M	CC @Organisation	Organisation ID
BirthDate	O	YYYYMMDD	Date of birth. This information could be not known at the very beginning, but it will be completed for all participants after successive updates
Height	O	N(3) 999	Height in centimetres. It will be included if this information is available. This information is not needed in the case of officials/referees.
Weight	O	N(3) 999	Weight in kilograms. It will be included if this information is available. This information is not needed in the case of officials/referees.
PlaceofBirth	O	S(75)	Place of Birth
CountryofBirth	O	CC @Country	Country ID of Birth
PlaceofResidence	O	S(75)	Place of Residence
CountryofResidence	O	CC @Country	Country ID of Residence
Nationality	O	CC @Country	Participant’s nationality. Although this attribute is optional, in very exceptional situations it will not be known, and for this reason not ready to be sent.
MainFunctionId	O	CC @Function	Main function In the Case of Current=”true” this attribute is Mandatory.
Current	M	boolean	It defines if a participant is participating in the games (true) or is a Historical participant (false).
OlympicSolidarity	O	Y or N	Flag to indicating if the participant participates in the Olympic Movement program.
ModificationIndicator	M	N, U	Attribute is mandatory in the DT_PARTIC_UPDATE message only N-New participant (in the case that this information comes as a late entry) U-Update participant If ModificationIndicator=’N’, then include new participant to the previous bulk-loaded list of participants If ModificationIndicator=’U’, then update the participant to the previous bulk-loaded list of participants To delete a participant, a specific value of the Status attribute is used.

Participant /Discipline

Although any participating athlete will be assigned at least one discipline, it could be more. Any accredited official will be assigned at least one discipline, but it could be more. If an athlete or official is assigned to more than one discipline, it will be included in the participant message of both disciplines.

Attribute	M/O	Value	Comments
Code	M	CC @Discipline	It is the discipline code used to fill the OdfBody @DocumentCode attribute.
InternationalFederationId	O	S(16)	Competitor’s federation number for the corresponding discipline (include if the discipline assigns international federation codes to athletes).

Participant /Discipline /RegisteredEvent

Any accredited athlete will be assigned to one or more events. There is one exception: in some sports, substitutes may be accredited without any associated event.

Historical athletes are not register to any event.

Attribute	M/O	Value	Comments
Gender	M	CC @DisciplineGender	Discipline Gender Code
Event	M	CC @Event	Event ID
Bib	O	N/A	Bib number nou used for Bobsleigh

Participant /Discipline /RegisteredEvent /EventEntry

Send if there are specific athlete’s event entries.

Type	Code	Pos	Value	Description
E_ENTRY	E_POSITION		CC @Position	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos : Do not send anything - For @Value: Athlete’s position
E_SUBSTITUTE		S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos : Do not send anything - For @Value: Send “Y” if the participant is a reserve. Otherwise, don´t send it.

Type

Code

Pos

Value

Description

E_ENTRY

E_POSITION

CC @Position

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos :

Do not send anything

- For @Value:

Athlete’s position

E_SUBSTITUTE

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos :

Do not send anything

- For @Value:

Send “Y” if the participant is a reserve. Otherwise, don´t send it.

For the table above, we have the following additional/summary information:

Type/Code	Description	Expected
E_ENTRY/ E_POSITION	Athlete’s position	Always, as soon as this information is available
E_ENTRY/ E_SUBSTITUTE	Reserve flag	Only if participant is a reserve for competition

3.2.1.6 Message Sort

The message is sorted by Participant @Code

3.2.2 List of teams / List of teams update

3.2.2.1 Description

DT_PARTIC_TEAMS contains the list of teams related to the current competition.

A team is a type of competitor, being a group of two or more individual athletes participating together in one event. Pairs (tennis, figure skating, etc.) are also defined as team of two competitors. One team participates in one event of one discipline. When one team participates in multiple events, there will be one team for each event for the same group. Also when the same organisation participates in the same event twice, there will different teams.

A historical team is defined as a group of athletes (team members) competing in the past in a competition event for an organisation. The historical team members appearing in this message will be listed in the list of historical athletes’ messages. The list of historical teams just associates historical team members with the corresponding historical teams. Historical teams will not be registered to any event.

For equestrian one athlete and one horse are not considered a team, the horse is an attribute of the athlete.

List of teams (DT_PARTIC_TEAMS) is a bulk message by discipline. The list is always complete. The arrival of this message resets all the previous participant teams’ information for that discipline. It is assumed that all teams appearing in this list are valid, in the meaning that they are participating or they could participate in one event.

List of teams update (DT_PARTIC_TEAMS_UPDATE) is an update message. It is not a complete list of teams’ information message. It only contains the team data being modified.

The key of the information updated consists of the following attribute: Team @Code. Therefore, any new or updated Team Discipline-Event will be identified by all these attributes.

3.2.2.2 Header Values

3.2.2.2.1 PiT Header

The following table describes the ODF header attributes

Attribute	Value	Comment
DocumentCode	DD0000000	DD is defined according to CC @Discipline
DocumentType	DT_PARTIC_TEAMS_UPDATE / DT_PARTIC_TEAMS	List of participant teams message
Version	1..V	Version number associated to the message’s content. Ascendant number
FeedFlag	“P”-Production “T”-Test	Test message or production message.
Date	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	MillisTime	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	Date	Logical Date of events that extends until next day. 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 output will 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 correction. Logical Date is expressed in the local time zone where the message was produced
Serial	Numeric	Sequence number for ODF-PiT messages. Serial starts with 1 each day session at every different venue. In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information
Venue	CC @VenueCode	Venue where the message is generated.

3.2.2.3 Trigger and Frequency

3.2.2.3.1 PiT Triggers

The DT_PARTIC_TEAMS message is sent as a bulk message one month before the Games. It is sent several times up to the date from what only DT_PARTIC_TEAMS_UPDATE messages are sent.

The DT_PARTIC_TEAMS_UPDATE message is triggered when there is a modification in a DT_PARTIC_TEAMS bulk message sent before.

Attribute	M/O	Value	Comments
Code	M	CC @Competition	Unique ID for competition

Attribute	M/O	Value	Comments
Code	M	S(20) with no leading zeroes	Team’s ID (example ATM001ESP01, 393553) When the Team is an historical one, then this ID starts with “T”.
Organisation	M	CC @Organisation	Team organisation’s ID
Number	O	N(2)	Team’s number. If there is not more than one team for one organisation participating in one event, it is 1. Otherwise, it will be incremental, 1 for the first organisation’s team, 2 for the second organisation’s team, etc. Required in the case of current teams.
Name	M	S(73) see table comment	Team’s name. It will apply to some of the disciplines. If there is not any special rule for that discipline, send the Description of the code CC@Organisation. It is Optional in the case of List of Team Update when the @ ModificationIndicator=D
Gender	M	CC @DisciplineGender	Discipline Gender Code of the Team
Current	M	boolean	It defines if a team is participating in the games (true) or it is a Historical team (false)
ModificationIndicator	M	N, U, D	Attribute is mandatory in the DT_PARTIC_TEAMS_UPDATE message only N-New team (in the case that this information comes as a late entry) U-Update team D-Delete team If ModificationIndicator=’N’, then include new team to the previous bulk-loaded list of teams If ModificationIndicator=’U’, then update the team to the previous bulk-loaded list of teams If ModificationIndicator=’D’, then delete the team to the previous bulk-loaded list of teams

Attribute	M/O	Value	Comments
Code	M	CC @Discipline	It must be the discipline code used to fill the OdfBody @DocumentCode attribute
InternationalFederationId	O	S(16)	Federation number for the corresponding discipline (include if the discipline assigns international federation codes to teams)

Attribute	M/O	Value	Comments
Event	M	CC @Event	Event ID
Gender	M	CC @DisciplineGender	Discipline Gender Code
Bib	O	Bib number	Bib number. Bib number is in fact a special Event Entry. However, since it is very meaningful in the sports that make use of this attribute, it has been considered as an attribute, although it was part of EventEntry in the previous versions.

Attribute	Value	Comment
DocumentCode	DDGEEEPUU	The DocumentCode attribute in the ODF header will be sent according to the ODF Common Codes document (header values sheet).
DocumentType	DT_START_LIST	Start List message
Version	1..V	Version number associated to the message’s content. Ascendant number
FeedFlag	“P”-Production “T”-Test	Test message or production message.
Date	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	MillisTime	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	Date	Logical Date of events that extends until next day. 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 output will 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 correction. Logical Date is expressed in the local time zone where the message was produced
Venue	CC @VenueCode	Venue where the message is generated.
Serial	Numeric	Sequence number for ODF-PiT messages. Serial starts with 1 each day session at every different venue. In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information

3.2.3.5 Message Values

Competition

Attribute	M/O	Value	Comments
Code	M	CC @Competition	Unique ID for competition

UnitInfos /UnitDateTime

Scheduled start date and time.

Attribute	M/O	Value	Comments
StartDate	M	DateTime	Actual start date and time. For multiday units, the start time is on the first day.

UnitInfos /UnitInfo

Unit info item associated to the event unit.

Type	Code	Pos	Value	Description
UI_BS	BS_HEAT_NUMBER		N(2) 99	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Heat number
	BS_START_RECORD_TIME		MM:SS.hh 99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Start time record of track MM is minutes, SS is seconds, hh is hundredth of second
	BS_START_RECORD_PARTIC		S(20)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Competitor ID record owner, with no leading zeroes,
	BS_START_RECORD_DATE		N(8) YYYYMMDD	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Date of record
	BS_TRACK_RECORD_TIME		MM:SS.hh 99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Heat time record of track MM is minutes, SS is seconds, hh is hundredth of second
	BS_TRACK_RECORD_ PARTIC		S(20)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Competitor ID record owner, with no leading zeroes
	BS_TRACK_RECORD_DATE		N(8) YYYYMMDD	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Date of record

For the table above, we have the following additional/summary information:

Type/Code	Description	Expected
UI_BS/ BS_HEAT_NUMBER	Heat number	Always
UI_BS/ BS_START_RECORD_TIME	Start time Track Record	Always
UI_BS/ BS_START_RECORD_PARTIC	Competitor´s ID	Always
UI_BS/ BS_START_RECORD_DATE	Record Date	Always
UI_BS/ BS_TRACK_RECORD_TIME	Time Track Record	Always
UI_BS/ BS_TRACK_RECORD_ PARTIC	Competitor’s ID	Always
UI_BS/ BS_TRACK_RECORD_DATE	Record Date	Always

Officials /Official

Official associated to the event unit.

Attribute	M/O	Value	Comments
Code	M	S(20) with no leading zeroes	Official’s code
Function	M	CC @Function	Official’s function (example: referee, etc.). Can be different from the function sent in the DT_PARTIC message.
Order	O	N/A	Official’s order (if the discipline specificity required it).

Start

This element is optional (due to the information availability, the information related to the event unit can be sent before the competitors information).

Attribute	M/O	Value	Comments
StartOrder	O	Numeric	Competitor’s start order
SortOrder	M	Numeric See table comment	Used to sort all start list competitors in an event unit (for example, when the StartOrder is missing).

Attribute

M/O

Value

Comments

StartOrder

Numeric

Competitor’s start order

SortOrder

Numeric

See table comment

Used to sort all start list competitors in an event unit (for example, when the StartOrder is missing).

Start /Competitor

Competitor participating in the event unit

Start /Competitor /Composition is optional for a similar reason: knowing the teams participating in one event unit, it is not known yet the team members participating.

Attribute	M/O	Value	Comments
Code	M	S(20) with no leading zeroes	Competitor’s ID
Type	M	T	T for team
Bib	M	Bib number	Team’s bib number (Competitor @Type should be T).

Start /Competitor /EventUnitEntry

Type	Code	Pos	Value	Description
EU_ENTRY	E_IRM		CC @IRM	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: DNS or DSQ

Type

Code

Pos

Value

Description

EU_ENTRY

E_IRM

CC @IRM

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

DNS or DSQ

For the table above, we have the following additional/summary information:

Type/Code	Description	Expected
EU_ENTRY/ E_IRM	Team´s IRM before start competition	Always

Start /Competitor /Composition /Athlete

Athlete or team member’s extended information.

Attribute	M/O	Value	Comments
Code	M	S(20) with no leading zeroes	Athlete’s ID, corresponding to either a team member or an individual athlete
Order	M	Numeric	N/A
Bib	O	N/A	Bib Number not used for Bobsleigh

Start /Competitor /Composition /Athlete /EventUnitEntry

Team member or individual athlete’s event unit entry.

Type	Code	Pos	Value	Description
EU_ENTRY	E_POSITION		CC @Position	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Athlete’s position

Type

Code

Pos

Value

Description

EU_ENTRY

E_POSITION

CC @Position

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Athlete’s position

For the table above, we have the following additional/summary information:

Type/Code	Description	Expected
EU_ENTRY/ E_POSITION	Athlete’s position	Always

3.2.3.6 Message Sort

The message is sorted by the Start@SortOrder attribute.

3.2.4 Event Unit Results

3.2.4.1 Description

The Event Unit Results is a message containing the results for the list of competitors in one event unit, either competing as single athletes or as aggregated athletes according to the team definition as it can be seen in the List of teams’ message in the ODF General Messages Interface Document.

The Event Unit Results message is a generic message for all sports, including as much generic information as possible, considering results may have substantial differences between different disciplines and events (example: score of a match, time in a race, distance in a throw, etc.).

3.2.4.2 Header Values

3.2.4.2.1 PiT Header

The following table describes the ODF header attributes

Attribute	Value	Comment
DocumentCode	DDGEEEPUU	DD according to CC @Discipline G according to CC @DisciplineGender EEE according to CC @Event P according to CC @Phase UU according to CC @Unit
DocumentType	DT_RESULT	Event Unit Results message
ResultStatus	CC @ResultStatus	It indicates whether the result is official or unofficial (or intermediate, interim, partial). “OFFICIAL” / “UNOFFICIAL” / “INTERMEDIATE” / “INTERIM”/ “PARTIAL”
Version	1..V	Version number associated to the message’s content. Ascendant number
FeedFlag	“P”-Production “T”-Test	Test message or production message.
Date	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	MillisTime	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	Date	Logical Date of events that extends until next day. 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 output will 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 correction. Logical Date is expressed in the local time zone where the message was produced
Venue	CC @VenueCode	Venue where the message is generated.
DocumentSubtype	N/A	Not used in BS
Serial	Numeric	Sequence number for ODF-PiT messages. Serial starts with 1 each day session at every different venue. In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information

3.2.4.2.2 RT Header

The following table describes the ODF header attributes

Attribute	Value	Comment
DocumentCode	DDGEEEPUU	DD according to CC @Discipline G according to CC @DisciplineGender EEE according to CC @Event P according to CC @Phase UU according to CC @Unit
DocumentType	DT_RT_RESULT	Event Unit Real Time Results message
ResultStatus	CC @ResultStatus	It indicates whether the result is live update or live full (or live Mandatory, Live Last). “LIVE_UPDATE” / “LIVE_FULL” / “LIVE_MANDATORY” / “LIVE_LAST
Version	1..V	Version number associated to the message’s content. Ascendant number
FeedFlag	“P”-Production “T”-Test	Test message or production message.
Date	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	MillisTime	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	Date	Logical Date of events that extends until next day. 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 output will 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 correction. Logical Date is expressed in the local time zone where the message was produced
Venue	CC @VenueCode	Venue where the message is generated.
RTSerial	Numeric	Incremental and unique sequence number for ODF-RT messages.
Serial	Numeric	Sequence number for ODF-PiT messages. Serial starts with 1 each day session at every different venue. In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information

3.2.4.3 Trigger and Frequency

3.2.4.3.1 PiT Triggers

The general rule is that this message is sent as when the event unit finishes and the message becomes unofficial, and also afterwards when the message becomes official (when the event unit becomes official). The official/unofficial status can be seen in ODF headers (ResultStatus attribute).

Trigger also after any major change.

3.2.4.3.2 RT Triggers

• For ResultStatus=”LIVE_UPDATE”

o T1: Trigger after any correction of a competitor’s result.

o T2: Trigger when a competitor crosses an intermediate point.

o T3: Trigger when a competitor arrives to finish.

o T4: Trigger when an event unit starts.

o T5: Trigger to update traff light (green/red).

o T6: Trigger when competitor mark his top speed.

o T7: Trigger when a track record must be updated

• For ResultStatus=”LIVE_FULL”

o This value should be suggested after further testing and sent in the DT_RT_GM message after further testing

3.2.4.5 Message Values

Competition

Attribute	M/O	Value	Comments	RT Only	RT Trigger
Code	M	CC @Competition	Unique ID for competition	N	When available

UnitInfos /UnitDateTime

Actual start –and/or end- dates and times.

This element is just for PiT.

Attribute	M/O	Value	Comments	RT Only	RT Trigger
StartDate	O	DateTime	Actual start date-time. For multi-day units, the start date-time is on the first day. Not needed for Real Time.	N	When available
EndDate	O	DateTime See table comment	Actual end date-time (The attribute should be informed, when available, for ResultStatus UNOFFICIAL and OFFICIAL) Not needed for Real Time.	N	When available

Attribute

M/O

Value

Comments

RT Only

RT Trigger

StartDate

DateTime

Actual start date-time. For multi-day units, the start date-time is on the first day.

Not needed for Real Time.

When available

EndDate

DateTime

See table comment

Actual end date-time (The attribute should be informed, when available, for ResultStatus UNOFFICIAL and OFFICIAL)

Not needed for Real Time.

When available

UnitInfos /UnitInfo

Unit info item associated to the event unit.

Type	Code	Pos	Value	Description
UI_BS	BS_ATTENDANCE		N(6) 999999	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Number of spectators
	BS_START_IND		N(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: 0 for Red Start Indicator, 1 for Green Start Indicator
	BS_START_RECORD_TIME		MM:SS.hh 99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Start time record of track MM is minutes, SS is seconds, hh is hundredth of second
	BS_START_RECORD_PARTIC		S(20)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Competitor ID record owner, with no leading zeroes, TBD, Code
	BS_START_RECORD_DATE		N(8) YYYYMMDD	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Date of record
	BS_START_RECORD_NEW		S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Send “Y” when START_RECORD values are a new record acquired, otherwise send “N”
	BS_TRACK_RECORD_TIME		MM:SS.hh 99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Heat time record of track MM is minutes, SS is seconds, hh is hundredth of second
	BS_TRACK_RECORD_ PARTIC		S(20)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Competitor ID record owner, with no leading zeroes, TBD, Code
	BS_TRACK_RECORD_DATE		N(8) YYYYMMDD	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Date of record
	BS_TRACK_RECORD_NEW		S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Send “Y” when TRACK_RECORD values are a new record acquired, otherwise send “N”

For the table above, we have the following additional/summary information:

Type/Code	Description	Expected	RT Only	RT Trigger
UI_BS/ BS_ATTENDANCE	Number of spectators	Always, as soon as this information is available Use only in Point in time messages	N	T4
UI_BS/ BS_START_IND	Start Indicator switch, for green/red light indicator	Send every time indicator must be changed	Y	T5
UI_BS/ BS_START_RECORD_TIME	Start time Track Record	Send when Start Record must be updated	N	T7
UI_BS/ BS_START_RECORD_PARTIC	Competitor’s ID	Send when Record value must be updated	N	T7
UI_BS/ BS_START_RECORD_DATE	Record Date	Send when Record value must be updated	N	T7
UI_BS/ BS_START_RECORD_NEW	Flag to know if record values are a new record	Send when Start Record values must be updated	N	T7
UI_BS/ BS_TRACK_RECORD_TIME	Time Track Record	Send when Heat Record must be updated	N	T7
UI_BS/ BS_TRACK_RECORD_ PARTIC	Competitor’s ID	Send when Heat Record must be updated	N	T7
UI_BS/ BS_TRACK_RECORD_DATE	Record Date	Send when Heat Record must be updated	N	T7
UI_BS/ BS_TRACK_RECORD_NEW	Flag to know if record values are a new record	Send when Track Record values must be updated	N	T7

Result

For each Event Unit Results message, there must be at least one competitor being awarded with a result in the event unit.

Attribute	M/O	Value	Comments	RT Only	RT Trigger
Rank	O	Numeric	Rank of the competitor after the current event unit This attribute is optional because the competitor could get an invalid rank mark.	N	T1,T2, T3, T4
RankEqual	O	Y or N	It identifies if a rank has been equalled. For Pit, send just ‘Y’ for equalled ranks.	N	T1,T2, T3, T4
Result	O	MM:SS.hh 99:90.00	Result after the current event unit. Send just in the case @ResultType is Time (see codes section) MM is minutes, SS is seconds, hh is hundredth of second	N	T1,T2, T3, T4
IRM	O	CC @IRM	IRM for the particular event unit Send just in the case @ResultType is IRM (see codes section)	N	T1,T2, T3, T4
QualificationMark	O	CC @QualificationMark	The code which gives an indication on the qualification of the competitor for the last heat of the competition (when there are 4 heats it should be informed in heat 3)	N	T1, T3
SortOrder	M	Numeric	Used to sort all the results of an event unit For Real Time this attribute is optional. Do not inform when the ResultType is empty. Also for Real Time, any sort order change from the initial start list order for any competitor will be provided in this attribute regardless the competitor is ranked or not (this includes ranked, none-ranked and IRM athletes/team).	N	T1,T2, T3, T4
ResultType	O	CC @ResultType	Type of the @Result attribute. In Real Time, when the ResultType attribute is sent empty that means that the Result element is not used. The message is used just to include some extended results for a particular kind of competitor. On the contrary, if ResultType is informed, and the other attributes are blank (‘’‘’), it is assumed that these attributes are being reset.	N	T1,T2, T3, T4

Result /Competitor

Competitor related to the result of one event unit.

Attribute	M/O	Value	Comments	RT Only	RT Trigger
Code	M	S(20) with no leading zeroes	Competitor’s ID	N	T1,T2,T3, T6
Type	M	T	T for team	N	T1,T2,T3, T6
Bib	M	Bib number	Bib number	N	T1,T2,T3, T6

Result /Competitor /ExtendedResults /ExtendedResult

Type	Code	Pos	Value	Description
ER_BS	BS_DIFF	Numeric	+MM:SS.hh +99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: Time difference for the current event unit (for Result @Rank=1, send 0.00) MM is minutes, SS is seconds, hh is hundredth of second
	BS_DIFF_CURR	Numeric	+MM:SS.hh +99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: Time difference for the current event unit for current sled display - This field always will show the difference between current sled and the leader (before the current sled!). I.e. if the current sled becomes the new leader this will stay negative and not turn to 0.00 at the finish.MM is minutes, SS is seconds, hh is hundredth of second
	BS_SPLIT	Numeric	+MM:SS.hh 99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: time up to the split for the current event unit MM is minutes, SS is seconds, hh is hundredth of second
	BS_RANK	Numeric	Numeric	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: Rank of the competitor at the moment of the split, according to its split time for the current event unit
	BS_ERANK	Numeric	S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: It identifies if the rank at this point has been equalled, send “Y” in this case.
	BS_DIFF_TOTAL	Numeric	+MM:SS.hh +99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: Overall Time difference (including previous heats) (for Result @Rank=1, send 0.00) MM is minutes, SS is seconds, hh is hundredth of second
	BS_DIFF_TOTAL_CURR	Numeric	+MM:SS.hh +99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: Overall Time difference for the current event unit for current sled display - This field always will show the difference between current sled and the leader (before the current sled!). I.e. if the current sled becomes the new leader this will stay negative and not turn to 0.00 at the finish MM is minutes, SS is seconds, hh is hundredth of second
	BS_SPLIT_TOTAL	Numeric	MM:SS.hh 99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: Overall Cumulative time up to the split (including previous heats) MM is minutes, SS is seconds, hh is hundredth of second
	BS_RANK_TOTAL	Numeric	Numeric	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: Overall Rank of the competitor at the moment of the split, according to its split time (including previous heats)
	BS_ERANK_TOTAL	Numeric	S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: It identifies if the Total rank at this point has been equalled, send “Y” in this case.
	BS_CURRENT		S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Do not send anything - For @Value: Send Y for the current competitor, “N” in other case
	BS_NEXT		S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Do not send anything - For @Value: Send “Y” for the next competitor, “N” in other case
	BS_RECENT		S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Do not send anything - For @Value: Send “Y” if this competitor is the most recent, “N” in other case.
	BS_START_RECORD		S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Do not send anything - For @Value: Send “Y” if the start_time is the actual record of the track, “N” in other case.
	BS_SPEED	Numeric	N(3).N(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: Send the measured speed in km/h
	BS_SPEED_RECORD	Numeric	S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Incremental number from 1 to N, to identify each one of the splits (intervals) - For @Value: Send “Y” if the BS_SPEED value is the maximum speed recorded of the track, “N” in other case.
	BS_TIME_RECORD		S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Do not send anything - For @Value: Send “Y” if the Total time is the actual record of the track, “N” in other case.
	BS_BEST_START		MM:SS.hh 99:90.00	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Do not send anything - For @Value: The best START_TIME of participant in the track. MM is minutes, SS is seconds, hh is hundredth of second
	BS_BEST_START_RECORD		S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Do not send anything - For @Value: Send “Y” if the BS_BEST_START value is the best STAR_RECORD in the track, “N” in other case
	BS_BEST_SPEED		N(3).N(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Do not send anything - For @Value: The maximum speed recorded by the participant in the track in km/h
	BS_BEST_SPEED_RECORD		S(1)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: Do not send anything - For @Value: Send “Y” if the BS_BEST_SPEED value is the maximum speed recorded in the track by any participant, “N” in other case

For the table above, we have the following additional/summary information:

Type/Code	Description	Expected	RT Only	RT Trigger
ER_BS/ BS_DIFF	Time difference	Always	N	T1,T2,T3
ER_BS/ BS_DIFF_CURR	Time difference for the current event unit for current sled display - This field always will show the difference between current sled and the leader (before the current sled!). I.e. if the current sled becomes the new leader this will stay negative and not turn to 0.00 at the finish	Always	Y	T1,T2,T3
ER_BS/ BS_SPLIT	Cumulative time up to the interval	Always	N	T1,T2,T3
ER_BS/ BS_RANK	Rank of the competitor at the moment of the interval	Always	N	T1,T2,T3
ER_BS/ BS_ERANK	For Identifies if Rank of the competitor has been equaled	Always	N	T1,T2,T3
ER_BS/ BS_DIFF_TOTAL	Overall Time difference	Always	N	T1,T2,T3
ER_BS/ BS_DIFF_TOTAL_CURR	Overall Cumulative Time difference for the current event unit for current sled display - This field always will show the difference between current sled and the leader (before the current sled!). I.e. if the current sled becomes the new leader this will stay negative and not turn to 0.00 at the finish	Always	Y	T1,T2,T3
ER_BS/ BS_SPLIT_TOTAL	Overall Cumulative time up to the interval	Always	N	T1,T2,T3
ER_BS/ BS_RANK_TOTAL	Overall Cumulative time up to the interval	Always	N	T1,T2,T3
ER_BS/ BS_ERANK_TOTAL	For Identifies if Rank of the competitor has been equaled	Always	N	T1,T2,T3
ER_BS/ BS_CURRENT	Send Y for the current competitor, N if it is not anymore.	Always	Y	T1,T2,T3,T6
ER_BS/ BS_NEXT	Send Y for the next competitor, N if it is not anymore.	Always	Y	T1,T2,T3,T6
ER_BS/ BS_RECENT	Send Y for the most recent competitor, N if it is not anymore.	Always	Y	T1,T2,T3,T6
ER_BS/ BS_START_RECORD	Send Y if BS_SPLIT (Pos=1) is the best time of the track, N in other case.	Always	N	T1,T2
ER_BS/ BS_SPEED	Measured speed in a intermediate point	Always	N	T1,T6
ER_BS/ BS_SPEED_RECORD	Send Y if BS_SPEED is the maximum speed recorded in the track.	Always	N	T1,T6
ER_BS/ BS_TIME_RECORD	Send Y if BS_SPLIT (Last Pos) is the best time of the track, N in other case.	Always	N	T1,T3
ER_BS/ BS_BEST_START	The best START_TIME of participant in the track.	Always	N	T1,T2,T3
ER_BS/ BS_BEST_START_RECORD	Send “Y” if the BS_BEST_START value is the best STAR_RECORD in the track, “N” in other case.	Always	N	T1,T2,T3
ER_BS/ BS_BEST_SPEED	The maximum speed recorded by the participant in the track.	Always	N	T1,T2,T3,T6
ER_BS/ BS_BEST_SPEED_RECORD	Send “Y” if the BS_BEST_SPEED value is the maximum speed recorded in the track by any participant, “N” in other case	Always	N	T1,T2,T3,T6

Result /Competitor /Composition /Athlete

Attribute	M/O	Value	Comments	RT Only	RT Trigger
Code	M	S(20) with no leading zeroes	Athlete’s ID. corresponding to a team member	N	T1,T2,T3, T6
Order	M	Numeric	Order attribute used to sort team members in a team (if Competitor @Type=”T”)	N	T1,T2,T3, T6

3.2.4.6 Message Sort

Sort by Result @SortOrder

3.2.5 Cumulative Results

3.2.5.1 Description

The Cumulative Results is a message containing the cumulative results for the list of competitors in one phase, up to the end of this phase (including information regarding to previous phases), or up to the end of an event unit within a phase (including also the units prior the current one) either competing as single athletes or as aggregated athletes according to the team definition.

The difference between the Phase Results message (DT_PHASE_RESULTS) and the Cumulative Results (DT_CUMULATIVE_RESULT) is that the first one includes only the results for the phase independently from previous phases, while the Cumulative Results takes into account the results of previous phases, and therefore it gives an idea about how a competition is progressing up to the end of an intermediate phase.

The Cumulative Results message may be used to send an interim summary of results (including rank) part way through a phase. In this case, the DocumentSubtype is used to specify the last phase or event unit that contributed results to the message.

The mandatory attributes and mandatory elements defined in this message will have to be used by all the sports, although each ODF Sport Data Dictionary will have to explain with further detail the optional attributes or optional elements of the message.

3.2.5.2 Header Values

3.2.5.2.1 PiT Header

The following table describes the ODF header attributes

Attribute	Value	Comment
DocumentCode	DDGEEE000	DD according to CC @Discipline G according to CC @DisciplineGender EEE according to CC @Event
DocumentType	DT_CUMULATIVE_RESULT	Cumulative Results message
ResultStatus	CC @ResultStatus	It indicates whether the result is official or unofficial. “OFFICIAL” / “UNOFFICIAL”
DocumentSubtype	DDGEEEPUU	The DocumentSubType should be by event unit (DDGEEEPUU) and should be sent just per Heats.
Version	1..V	Version number associated to the message’s content. Ascendant number
FeedFlag	“P”-Production “T”-Test	Test message or production message.
Date	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	MillisTime	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	Date	Logical Date of events that extends until next day. 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 output will 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 correction. Logical Date is expressed in the local time zone where the message was produced
Venue	CC @VenueCode	Venue where the message is generated.
Serial	Numeric	Sequence number for ODF-PiT messages. Serial starts with 1 each day session at every different venue. In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information

3.2.5.2.2 RT Header

The following table describes the ODF header attributes

Attribute	Value	Comment
DocumentCode	DDGEEE000	DD according to CC @Discipline G according to CC @DisciplineGender EEE according to CC @Event
DocumentType	DT_RT_CUMULATIVE_RESULT	Cumulative Real Time Results message
DocumentSubtype	DDGEEEPUU	The DocumentSubType should be by event unit (DDGEEEPUU) and should be sent just per Heats.
ResultStatus	CC @ResultStatus	It indicates whether the result is live update or live full (or live Mandatory, Live Last). “LIVE_UPDATE” / “LIVE_FULL” / “LIVE_MANDATORY” / “LIVE_LAST” For Real Time, live update (for the normal operative), or live full for the resynchronization messages, as explained in chapter 6.1 and ResultStatus codes as seen in chapter 3, live Mandatory when there is a correction of previous messages and Live Last for the last message of this key of messages.
Version	1..V	Version number associated to the message’s content. Ascendant number
FeedFlag	“P”-Production “T”-Test	Test message or production message.
Date	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	MillisTime	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	Date	Logical Date of events that extends until next day. 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 output will 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 correction. Logical Date is expressed in the local time zone where the message was produced
Venue	CC @VenueCode	Venue where the message is generated.
RTSerial	Numeric	Incremental and unique sequence number for ODF-RT messages.
Serial	Numeric	Sequence number for ODF-PiT messages. Serial starts with 1 each day session at every different venue. In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information

3.2.5.3 Trigger and Frequency

3.2.5.3.1 PiT Triggers

The general rule is that this message is sent as soon as:

• If results are accumulating across phases (i.e. the message is sent at event level and the Document Subtype of the message is DDGEEEP00):

It is sent after the last event unit for the first phase, in addition to subsequent phases. The message becomes unofficial just at the end of the event unit, and afterwards when the message becomes official (when the last event unit becomes official).

• If results are accumulated across event units (i.e. the message is sent at phase level and the Document Subtype of the message is DDGEEEPUU):

It is sent after the first event unit, in addition to subsequent event units; (in this case, the first DT_CUMULATIVE_RESULT message and the DT_RESULT message may contain the same information).The message becomes unofficial just at the end of the event unit, and afterwards when the message becomes official (when the last event unit becomes official).

The sequence is clarified below. The version number, n, is the version of the last DT_RESULT message sent for the same RSC code (n=0 if no DT_RESULT messages have been sent). The version number, m, is the version of the last DT_CUMULATIVE_RESULT message sent for the same RSC code (m=0 if no DT_CUMULATIVE_RESULT messages have been sent).

The clarification of this sequence can be:

Case 1:

a) Event has been complete and the results are unofficial:

1. Sent DT_RESULT with ODF Version n+1 and ResultStatus =” UNOFFICIAL”.

2. Sent DT_CUMULATIVE_RESULT with ODF Version m+1 and ResultStatus =” UNOFFICIAL”.

b) Results are checked and signed off by referee:

1. Sent DT_RESULT with ODF Version n+2 and ResultStatus =” OFFICIAL”.

2. Sent DT_CUMULATIVE_RESULT with ODF Version m+2 and ResultStatus =” OFFICIAL”.

Case 2:

a) Event has been complete and the results are directly officials:

1. Sent DT_RESULT with ODF Version n+1 and ResultStatus =” OFFICIAL”.

2. Sent DT_CUMULATIVE_RESULT with ODF Version m+1 and ResultStatus =” OFFICIAL”.

Trigger also after any major change.

Don’t send this message for trainings

3.2.5.3.2 RT Triggers

• For ResultStatus=”LIVE_UPDATE”

o T3: Trigger when a competitor arrives to finish.

• For ResultStatus=”LIVE_FULL”

o This value should be suggested after further testing and sent in the DT_RT_GM message after further testing

3.2.5.5 Message Values

Competition

Attribute	M/O	Value	Comments	RT Only	RT Trigger
Code	M	CC @Competition	Unique ID for competition	N	When available

Result

For any cumulative results message, there should be at least one competitor being awarded a cumulative result after one event unit or phase.

Attribute	M/O	Value	Comments	RT Only	RT Trigger
Rank	O	Text	Rank of the competitor in the cumulative result	N	T3
RankEqual	O	Y or N	It identifies if a rank has been equalled. In PiT message only Y value has sense.	N	T3
ResultType	O	CC @ResultType	Type of the @Result attribute	N	T3
Result	O	MM:SS.hh 99:90.00	The cumulative result of the competitor	N	T3
IRM	O	CC @IRM	The invalid rank mark, in case it is assigned	N	T3
QualificationMark	O	CC @QualificationMark	The code which gives an indication on the qualification of the competitor for the last heat of the competition (when there are 4 heats it should be informed in heat 3)	N	T3
SortOrder	M	Numeric	Used to sort all cumulative results, based on rank, but to break rank ties, etc. It is mainly used for display purposes.	N	T3

Result /ResultItems /ResultItem

Identifier of either phase or unit, for the schedule item to which it is going to be included the result summary. ResultItem /Result will be for either one particular previous phase -identified by @Phase- or unit (if @Unit is also informed or just phase otherwise.

Attribute	M/O	Value	Comments	RT Only	RT Trigger
Phase	M	CC @Phase	Phase code of the latest RSC schedule item (either phase or unit) to which the cumulative results is updated to.	N	T3
Unit	O	CC @Unit	Unit code of the latest RSC schedule item to which the cumulative results is updated to. It should be informed just in the case the latest schedule item is an event unit. Otherwise, do not include.	N	T3

Result /ResultItems /ResultItem /Result

For any Event Unit Results message, there should be at least one competitor being awarded a result for the event unit.

Attribute	M/O	Value	Comments	RT Only	RT Trigger
Rank	O	Text	Rank of the competitor in the result for the event unit or phase identified by /ResultItems /ResultItem.	N	T3
RankEqual	O	Y or N	It identifies if a rank has been equalled. In PiT message only Y value has sense.	N	T3
ResultType	O	CC @ResultType	Type of the @Result attribute for the event unit or phase identified by /ResultItems /ResultItem	N	T3
Result	O	MM:SS.hh 99:90.00	The result of the competitor in the event unit for the event unit or phase identified by /ResultItems /ResultItem	N	T3
IRM	O	CC @IRM	The invalid rank mark, in case it is assigned for the event unit or phase identified by /ResultItems /ResultItem	N	T3
QualificationMark	O	CC @QualificationMark	The code which gives an indication on the qualification of the competitor for the last heat of the competition, informed in the immediately previous event unit (when there are 4 heats it should be informed in heat 3) identified by /ResultsItems /ResultItem	N	T3
SortOrder	M	Numeric	Used to sort all results in an event unit or phase identified by /ResultItems /ResultItem	N	T3

Result /Competitor

Competitor related to one cumulative result.

Attribute	M/O	Value	Comments	RT Only	RT Trigger
Code	M	S(20) with no leading zeroes Or Organisation code in the case of NOC or NPC	Competitor’s ID	N	T3
Type	M	T	T for team	N	T3
Bib	M	N(3) 990	Bib number	N	T3

Result /Competitor /ExtendedResults /ExtendedResult

Team competitor’s extended results.

Type

Code

Pos

Value

Description

ER_BS

BS_DIFF

+MM:SS.hh

+99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Cumulative time difference after the finalisation of the current event unit (for Result @Rank=1, send 0.00)

MM is minutes, SS is seconds, hh is hundredth of second

BS_LAST_QUALIFIED

Y or N

- For @Type:

Send proposed type

- For @Code:

Send proposed type

- For @Pos:

Do not send anything.

- For @Value:

Send Y when competitor is the last competitor qualified according to sport rules. (See table below for more information)

For the table above, we have the following additional/summary information:

Type/Code	Description	Expected	RT Only	RT Trigger
ER_BS/ BS_DIFF	Cumulative time difference after event unit	Always	N	T3
ER_BS/ BS_LAST_QUALIFIED	The competitor is the last one to qualify according to rules. It is the virtual last qualified position in the current moment.	Always	N	T3

Result /Competitor /Composition /Athlete

Attribute	M/O	Value	Comments	RT Only	RT Trigger
Code	M	S(20) with no leading zeroes	Athlete’s ID, corresponding to a team member	N	T3
Order	M	Numeric	Order attribute used to sort team members in a team	N	T3
Bib	O	N(3) 990	Bib number not used for Bobsleigh	N	When available

3.2.5.6 Message Sort

Result @SortOrder will be the attribute used to sort the results.

3.2.6 Event Final Ranking

3.2.6.1 Description

The event final ranking is a message containing the final results and ranking at the completion of one particular event, either competing as single athletes or as aggregated athletes.

The final ranking message is a generic message for all sports, including the full event final result for all competitors that were either ranked, got an Invalid Rank Mark (disqualified, etc.), or both.

Depending on the sport rules it may include all competitors in the competition as all can be ranked (as in Marathon) or may only include this with a final ranking as other are unranked (as in tennis).

3.2.6.2 Header Values

3.2.6.2.1 PiT Header

The following table describes the ODF header attributes

Attribute	Value	Comment
DocumentCode	DDGEEE000	DD according to CC @Discipline G according to CC @DisciplineGender EEE according to CC @Event
DocumentType	DT_RANKING	Event Final ranking message
ResultStatus	CC @ResultStatus	Result status
Version	1..V	Version number associated to the message’s content. Ascendant number
FeedFlag	“P”-Production “T”-Test	Test message or production message.
Date	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	MillisTime	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	Date	Logical Date of events that extends until next day. 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 output will 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 correction. Logical Date is expressed in the local time zone where the message was produced
Venue	CC @VenueCode	Venue where the message is generated.
Serial	Numeric	Sequence number for ODF-PiT messages. Serial starts with 1 each day session at every different venue.

3.2.6.3 Trigger and Frequency

3.2.6.3.1 PiT Triggers

The general rule is that this message is sent just at the end of the last event unit of one particular event.

Trigger also after any major change.

3.2.8.5 Message Values

Competition

Attribute	M/O	Value	Comments
Code	M	CC @Competition	Unique ID for competition

Configs /Config

Attribute	M/O	Value	Comments
Gender	O	CC @DisciplineGender	Gender code of the RSC. Include if information is by Gender, by Event, by Phase or by Event Unit. Otherwise, do not include.
Event	O	CC @Event	Event code of the RSC. Include if information is by Event, by Phase or by Event Unit. Otherwise, do not include.
Phase	O	Numeric	Phase code of the RSC. Include if information is by Phase or by Event Unit. Otherwise, do not include.
Unit	O	Numeric	Unit code of the RSC. Include if information is by Event Unit. Otherwise, do not include.

Configs /Config /ExtendedConfig

Type	Code	Pos	Value	Description
EC_QUALIFICATION_RULE	BS_RANK_QUALIFY_NEXT_ROUND	Numeric	Numeric	- For @Type: Send proposed type - For @Code: Send the proposed code for the qualification rule. BS_RANK_QUALIFY_NEXT_ROUND is the code that indicates the qualification for next round based on rank. - For @Pos: Send 1 to indicate first rank included in the @Code rule Send 2 to indicate last rank included in the @Code rule - For @Value: Send the rank according to @Code rule and @Pos
EC_BS	BS_ALTITUDE_START		N(4) 9999	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Start altitude in meters
	BS_ALTITUDE_FINISH		N(4) 9999	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Finish altitude in meters
	BS_ALTITUDE_DROP		N(4) 9999	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Vertical drop in meters
	BS_LENGTH		N(4) 9999	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: Length of course in meters
	BS_INTERMEDIATE_RESULT_DIST	Numeric	N(4).N(1) 9999.9	- For @Type: Send proposed type - For @Code: Send proposed code - For @Pos: The number that identifies the intermediate result point, from 1 to the total number of intermediate result points - For @Value: Distance in meters with three one decimal digit of the intermediate result point (e.g.: 2000.6)
	BS_TOP_SPEED_POINT		N(2)	- For @Type: Send proposed type - For @Code: Send proposed code - For @Value: The number that identifies the intermediate point where is reached the top speed in the track.

For the table above, we have the following additional/summary information:

Type/Code	Description	Expected
EC_QUALIFICATION_RULE/ BS_RANK_QUALIFY_NEXT_ROUND	Qualification for next round based on rank	Always if the rule applies to the competition
EC_BS/ BS_ALTITUDE_START	Start altitude in meters	Always
EC_BS/ BS_ALTITUDE_FINISH	Finish altitude in meters	Always
EC_BS/ BS_ALTITUDE_DROP	Vertical drop in meters	Always
EC_BS/ BS_LENGTH	Length of course in meters	Always
EC_BS/ BS_INTERMEDIATE_RESULT_DIST	Distance for the intermediate result point in meters	Always
EC_BS/ BS_TOP_SPEED_POINT	Intermediate point where is reached the top speed in the track	Always

3.2.8.6 Message Sort

There is no general message sorting rule.

3.2.9 Event Unit Weather Conditions

3.2.9.1 Description

The “Event Unit Weather Conditions” is a message containing the weather conditions in the Event Unit.

3.2.9.2 Header Values

3.2.9.2.1 PiT Header

The following table describes the ODF header attributes

Attribute	Value	Comment
DocumentCode	DD0000000	DD according to CC @Discipline
DocumentType	DT_WEATHER	Weather conditions in the match message
Version	1..V	Version number associated to the message’s content. Ascendant number
FeedFlag	“P”-Production “T”-Test	Test message or production message.
Date	Date	Date when the message is generated, expressed in the local time zone where the message was produced.
Time	MillisTime	Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced.
LogicalDate	Date	Logical Date of events that extends until next day. 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 output will 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 correction. Logical Date is expressed in the local time zone where the message was produced
Venue	CC @VenueCode	Venue where the message is generated.
Serial	Numeric	Sequence number for ODF-PiT messages. Serial starts with 1 each day session at every different venue. In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information

3.2.9.3 Trigger and Frequency

3.2.9.3.1 PiT Triggers

This message should be sent each hour during session.

3.2.9.5 Message Values

Competition

Attribute	M/O	Value	Comments
Code	M	CC @Competition	Unique ID for competition

Weather /Conditions

Attribute	M/O	Value	Comments
Code	M	START, FINISH	Weather Points
Humidity	O	N(3)	Humidity in %
Wind_Direction	O	CC @WindDirection	Wind direction
Prec_Type	O	CC @PrecType	Precipitation type

Weather /Conditions /Condition

Send two times in the case of Winter conditions.

Attribute

M/O

Value

Comments

Code

SKY, ICE

Weather conditions type

Value

CC @SnowConditions

CC @WeatherConditions

Sky or Ice Weather Condition.

Use CC @WeatherConditions for SKY Conditions

Use CC @SnowConditions for ICE Conditions

Weather /Conditions /Temperature

Send with two different @Code in the case of Winter conditions.

Attribute	M/O	Value	Comments
Code	M	AIR, ICE	Air, Ice temperature. If available, are mandatory.
Unit	M	F,C	Metric system unit for temperature
Value	M	-N(3).N(1) -990.0 or N(3).N(1) 990.0	Temperature in centigrade degrees (in case of positive temperature, do not send '+')
Type	O	Text	Type of Temperature (like Maximum, Minimum, Normal, etc.)

Weather /Conditions /Wind

Attribute	M/O	Value	Comments
Code	M	SPEED	Wind Speed
Unit	M	MS , KMH	Metric system unit for Wind
Value	M	N(3).N(1) 990.0	Wind Speed

3.2.9.6 Message Sort

There is no special sort order requirement for this message. Usually, Conditions@code is the attribute used to sort the conditions.

4 Messages Sequence

1. All Events Training

Message	DocumentCode	DocumentSubType	ResultStatus	Comments
DT_START_LIST	DDGEEEPUU	N/A	N/A	Start List for Training n
DT_RESULT	DDGEEEPUU	N/A	LIVE_UPDAT	Real Time Results for Training n
DT_RESULT	DDGEEEPUU	N/A	UNOFFICIAL	Unofficial Results for Training n
DT_RESULT	DDGEEEPUU	N/A	LIVE_LAST	End of Real Time Results for Training n
DT_RESULT	DDGEEEPUU	N/A	OFFICIAL	Official Results for Training n

2. All Events Competition

Message	DocumentCode	DocumentSubType	ResultStatus	Comments
DT_START_LIST	DDGEEEPUU	N/A	N/A	Start List for Heat n
DT_RESULT	DDGEEEPUU	N/A	LIVE_UPDAT	Real Time Results for Heat n
DT_CUMULATIVE_RESULT	DDGEEE000	DDGEEEPUU	LIVE_UPDAT	Real Time Cumulative Results for Heat n
DT_RESULT	DDGEEEPUU	N/A	UNOFFICIAL	Unofficial Results for Heat n
DT_CUMULATIVE_RESULT	DDGEEE000	DDGEEEPUU	UNOFFICIAL	Unofficial Cumulative Results for Heat n
DT_RESULT	DDGEEEPUU	N/A	LIVE_LAST	End of Real Time Results for Heat n
DT_CUMULATIVE_RESULT	DDGEEE000	DDGEEEPUU	LIVE_LAST	End of Real Time Results for Heat n
DT_RESULT	DDGEEEPUU	N/A	OFFICIAL	Official Results for Heat n
DT_CUMULATIVE_RESULT	DDGEEE000	DDGEEEPUU	OFFICIAL	Official Cumulative Results for Heat n
DT_RANKING	DDGEEE000	N/A	OFFICIAL	Event Final Ranking

5 Codes

5.1 Global Codes

Code Entity	Format	Entity Description	Link
CC @AccreditationStatus	S(6)	Defined in ODF Common Codes Document See entity Accreditation Status • The entity’s attribute to be used is Id	Link
CC @Competition	S(7)	Defined in ODF Common Codes Document See entity Competition • The entity’s attribute to be used is Id	Link
CC @Country	S(3)	Defined in ODF Common Codes Document See entity Country • The entity’s attribute to be used is Id	Link
CC @Discipline	S(2)	Defined in ODF Common Codes Document See entity Discipline • The entity’s attribute to be used is Id Valid disciplines contains Non-Sport attribute=’N’	Link
CC @DisciplineGender	S(1)	Defined in ODF Common Codes Document See entity Discipline Gender • The entity’s attribute is to access to the Discipline Gender entity is the combination of Discipline + Gender	Link
CC @Event	S(3)	Defined in ODF Common Codes Document See entity Event • The entity’s attribute to be used is Event • It will be related to Discipline and Gender	Link
CC @Function	S(30)	Defined in ODF Common Codes Document See entity Function • The entity’s attribute to be used is Id	Link
CC @MedalType	S(9)	ME_BRONZE : Bronze ME_GOLD : Gold ME_SILVER : Silver
CC @Organisation	S(3)	Defined in ODF Common Codes Document See entity Organization • The entity’s attribute to be used is Id	Link
CC @PersonGender	S(1)	Defined in ODF Common Codes Document See entity Person Gender • The entity’s attribute to be used is Id	Link
CC @Phase	S(1)	Defined in ODF Common Codes Document See entity Phase • The entity’s attribute to be used is Phase • It will be related to Discipline, Gender and Event	Link
CC @PrecType	S(1)	R : Rain S : Snow
CC @RecordCode	S(12)	Defined in ODF Common Codes Document See entity Record • The entity’s attribute to be used is Id	Link
CC @RecordType	S(4)	Defined in ODF Common Codes Document See entity Record Type • The entity’s attribute to be used is RecordTye • It will be related to Discipline	Link
CC @ResultStatus	S(15)	INTERIM : Results of the top x competitors at the logical, predefined points released during or at the end of a event unit. Every next competitor may change the standing of those who already have results at a predefined point. INTERMEDIATE : Results of the top x competitors at the logical, predefined points during race or match. The results at those points cannot change. The number of competitors may vary. In the case of Bracket message its progression will be consider INTERMEDIATE until the last Event Unit is sent as OFFICIAL. LIVE_FULL : This status is used only in real time messages. LIVE_LAST : This status is used only in real time messages. LIVE_MANDATORY : This status is used only in real time messages. LIVE_UPDATE : This status is used only in real time messages. PARTIAL : Results of the top x competitors are released at the end of a race and before all competitors finished their competition. The results including the ranking, from the competitors that finished the race do not change with the results from new competitors. OFFICIAL : Results of the competition released as soon as the event is officially confirmed taking into account the resolution of the protests, etc. UNOFFICIAL : Results of the competition released as soon as the event is over, not waiting any official decision of the International Federation. The correctness of data must be assured.
CC @SportClass	S(8)	Defined in ODF Common Codes Document See entity Sport Class • The entity’s attribute to be used is Id
CC @Unit	S(2)	Defined in ODF Common Codes Document See entity Event Unit • The entity’s attribute to be used is Eventunit • It will be related to Discipline, Gender, Event and Phase	Link
CC @VenueCode	S(3)	Defined in ODF Common Codes Document See entity Venue • The entity’s attribute to be used is Id	Link
CC @WeatherConditions	S(6)	Defined in ODF Common Codes Document See entity Weather Condition • The entity’s attribute to be used is Id	Link
CC @WindDirection	S(3)	Defined in ODF Common Codes Document See entity Wind Direction • The entity’s attribute to be used is Id	Link

5.2 Bobsleigh Codes

Code Entity	Format	Entity Description
CC @IRM	S(5)	DNF : Did not finish DNS : Did not start DSQ : Disqualified (The codes order provided is according to the sport rules. If more than one crew have the same IRM, they should be sorted based on number of completed heats/segments. Competitors having the same IRM and the same number of completed heats /segments should be sorted by "bib number").
CC @Position	S(2)	C : Crew P : Pilot
CC @QualificationMark	S(7)	Q: Qualified (to participate in the last heat)
CC @ResultType	S(13)	IRM : Invalid Result Mark TIME : Time

6 General definitions

6.1 ODF Message Structure

ODF interface defines ODF messages. ODF messages are data structures based on standard XML.

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

6.1.1 ODF Declaration

The first line in an ODF message is the XML declaration. It defines the XML version and the encoding used, UTF-8.

6.1.2 ODF Header

The next line after the declaration is the ODF header.

ODF header is the root element and it is always introduced by the element Odfbody.

Header attributes identifies ODF messages uniquely.

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

· DocumentCode,

· DocumentSubcode (Optional)

· DocumentType and

· DocumentSubtype (Optional)

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

Attribute	M/O	Value	Comment
DocumentCode	M	S(9)	RSC for Results messages DDGEEEPUU, where DD=discipline, G=discipline’s gender, EEE=event, P=phase, UU=unit DocumentCode can have many different values depending on the nature of the message. Each message defines the value for this header attribute.
DocumentSubcode	O	S(10)	Extension for the DocumentCode It is used when the RSC is not enough and it is required several different messages with the same RSC.
DocumentType	M	S(30)	Message Type (e.g. DT_RESULTS)
DocumentSubtype	O	S(20)	Attribute used to extend DocumentType for some messages.
Version	M	1..V	Version of the message
ResultStatus	O	CC @ResultStatus	Status of the messages for results message
Language	O	CC @Language	Language of the content of the message. If the message accepts multi-language and the attribute is not included, then by default the language is English If the message does not accept multi-language, then the attribute must not be included
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	MillisTime	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 that extends until next day. 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 output will 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 correction. Logical Date is expressed in the local time zone where the message was produced.
Venue	O	CC @VenueCode	Venue where the message is generated.
RTSerial	O	Numeric	Sequence number for ODF-RT messages. RTSerial starts with 1 each Real Time session at every different venue.
Serial	M	Numeric	Sequence number for ODF-PiT messages. Serial starts with 1 each day session at every different venue. In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information.

6.1.3 ODF Body

The next line after the ODF header is the body of the ODF Message.

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

Some important considerations for the ODF messages:

Mandatory elements are sent always.

· Empty optional elements are not sent neither in ODF-PiT nor ODF-RT

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

· Empty optional attributes are sent either empty (Attribute = ““) or not sent.

· Order of the elements inside an ODF message must be followed as defined in the ODF documentation. Elements must be sorted according what it is stated in the corresponding ODF message definition

· All elements in an ODF message are identified by one of the attributes (e.g. Code for an Competitor element) or a set of the attributes (e.g. Type + Code for an Extension element)

· ODF is being designed in such way that elements and attributes are organized to minimize redundancy and dependency. The objective is to isolate data so that additions, deletions, and modifications of an attribute can be made with just one message and then propagated through the rest of the messages via the defined references. However, in some very special circumstances, some important information (such as team members) will be repeated in order to make some message processing a little bit easier. Also, the ODF Light definition repeats some data across messages to simplify message processing to ODF Light Customers.

· ODF Light is a set of self-contained messages with the aim of simplifying the message processing to the clients as they do not have to resolve references

<Competition> Element

An ODF message contains a mandatory element <Competition>.

Element

Attribute

M/O

Value

Comment

Competition

Code

CC @Competition

Unique ID for the competition

<Message> Element

All ODF messages can have an optional element <Message> to include free non-formatted text in case more information is needed.

<Message> element follows the <Competition> element.

<Competitor> Element

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

Element

Attribute

M/O

Value

Comment

Competitor

Code

S(20) with no leading zeroes

Competitor’s ID

Type

T, A, G

T = Team

A = Athlete

G = Group

If Competitor is an Athlete:

· <Competitor> element contains the attribute Type = ”A”

· <Competitor> element contains the attribute Code = AthleteID. This attribute links to an athlete appearing in the DT_PARTIC message.

· <Competitor> element contains the element <Composition>. This element is provided always.

· <Composition> element contains the mandatory element <Athlete>. Both codes in the <Athlete> and in the <Competitor> elements are the same, the AthleteID

· <Athlete> element contains the mandatory attribute Order with value 1.

· Athlete’s Bib (if applicable) will be only sent in Competitor /Composition /Athlete element.

· Sport specific extensions are in the <Athlete> element and defined in the ODF Discipline Data Dictionary.

</Composition>

</Competition>

If Competitor is a Team:

· <Competitor> element contains the attribute Type =”T”

· <Competitor> element contains the attribute Code = TeamCode. This attribute links to a team appearing in the DT_PARTIC_TEAMS message.

· <Competitor> element contains the element <Composition>. This element is optional because there are situations where the team members are not known when message is provided.

· <Composition> element contains the mandatory element <Athlete> with the list of athletes that are the team members. The Code attribute links to an athlete appearing in the DT_PARTIC (athletes) message.

· Although team members for the whole event will be able to be found in the DT_PARTIC_TEAMS message, the specific ODF Sport messages will also include always the team’s members particularized for the message.

· <Athlete> element contains the mandatory attribute Order with the team members sort order.

· Team’s Bib (if applicable) will be sent in Competitor element.

· Team members’ Bib (if applicable) will be sent in Competitor /Composition /Athlete element.

· Team sport specific extensions are in the <Competitor> element and defined in the ODF Discipline Data Dictionary.

· Team members sport specific extensions are in the <Athlete> element and defined in the ODF Discipline Data Dictionary.

…

</Composition>

</Competition>

If Competitor is a Group:

· <Competitor> element contains the attribute Code = NOC/NPC when the athletes belong to the same organization, otherwise MIXn.

· There will be several Competitor /Composition /Athlete elements, containing the group competitor members.

6.2 ODF Data Types and Formats

This chapter describes data types and formats for the attributes in the ODF messages.

Format	Format Description
CC @CodeEntity	Set of values included in the CodeEntity. CodeEntity is the name of the entity that identifies a particular set of codes.
String	Text strings without a predetermined length
S(n)	Text strings with a length of up to n characters
Date	YYYYMMDD
MillisTime	HHMMSSmmm HH: hour MM: minutes SS: seconds mmm: milliseconds All formatted with leading zeroes (example: 090303020).
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 in 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
Boolean	‘true’ or ‘false’
Numeric	Number with no predetermined length If the number starts with 9 (e.g. 99), then leading zeroes are removed. Example: 10 in format 99 is 10, and 3 in format 99 is 3. If the number starts with 0 (e.g. 00), then leading zeroes are kept. Example: 10 in format 00 is 10, and 3 in format 00 is 03. · If nothing is stated, it is assumed that the leading zeroes are removed
N(n)	Number with a length up to n digits
N(n).N(m)	Number with decimal N(n) integer part up to n digits N(m) decimal part up to m digits
Specific pattern	Attributes with an specific pattern not specified in this table
Free text	Free text is never used in a message attribute, but it can be used inside the element content Example <element>Free text goes in here</element>

6.2.1 Rules for rounding numbers

This chapter describes the rules for rounding numbers to use in all messages, unless other rules are specified in the sport documentation. (sport rules are applied before the transmission of the data)

· Last digit in the number decimal part < 5 (0, 1, 2, 3, 4) à no rounding (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)

6.2.2 Measures format

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

Measure

Value

Format

Example

Height/Distance

N(1).N(2)m

N(3)cm

N(1)’N(2)’’

9.00m

900cm

9’09’’

1.83m

183cm

6’0’’

Weight

N(3)kg

N(3)lbs

900kg

900lbs

100kg

220lbs

Temperature

N(2)ºC

N(3)ºF

90ºC

990ºF

35ºC

95ºF

Distance

N(3).N(3)km

N(3).N(3)mi

90.000km

90.000m

1.789km

6.123mi

Speed

N(2).N(3)m/s

N(3).N(3)mph

N(3).N(3)km/h

90.000m/s

90.000mph

90.000km/h

1.789m/s

6.123mph

3.890km/h

Precipitation

N(2)cm

N(2)in

90cm

90in

2cm

1in

6.2.3 Rules for measures conversion

This chapter describes measure 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 and fore mentioned rounding rules must be applied.

Measure	Conversion Rules
Distance	1 in = 0,0254 m 1 ft = 12 in = 0,3048 m 1 yd = 3 ft = 36 in = 0,9144 m 1 mi = 1.760 yd = 5.280 ft = 63360 in = 1609,344 m 1 nmi (nautical mile) = 1,852 m
Speed	1 km/h = 3,6 m/s 1 kts= 1 nmi/h
Weight	1 lbs = 0,453 592 37 kg
Temperature	T[°F] = 1,8 × T[°C] + 32 T[°C] = (T[°F] – 32) / 1.8

6.3 ODF Message Update

An update occurs when it is received a message whose identification is coinciding with the identification of an already received message.

Message identification is the combination of the header attributes: DocumentCode + DocumentSubcode + DocumentType + DocumentSubtype.

ODF PiT:

The latest message substitutes completely the previous received message.

There are specific messages, (with an UPDATE suffix) for updating some elements and keep the rest of the message, e.g. DT_SCHEDULE_UPDATE, DT_PARTIC_UPDATE, DT_PARTIC_TEAMS_ UPDATE or DT_PARTIC_HORSES_UPDATE.

ODF RT:

When the message header contains the attribute ResultStatus = LIVE_FULL or LIVE_LAST or LIVE_MANDATORY, the latest message substitutes completely the previous received message.

When the message header contains the attribute ResultStatus = LIVE_UPDATE, only the elements and attributes in the new message must be updated by message receiver. Elements and attributes provided before must be kept by message receiver.

· New message only includes the changed attributes, with the exception of the mandatory attributes that are always sent even if there is no modification.

When an attribute sent in the past has no value anymore, send the same message with ResultStatus=LIVE_MANDATORY and

· If the attribute is mandatory send it empty (Attribute=””)

· If the attribute is optional either do not send it or send it empty

7 DOCUMENT CONTROL

7.1 File Reference

ODF/INT007 R3 v6.2 APP (BS)

7.2 Version history

Version	Date	Comments
R3 v1.0	02 January 2012	Submitted for review version.
R3 v1.1	30 January 2012	Submitted for review version.
R3 v2.0	17 February 2012	Submitted for approval.
R3 v2.1	12 March 2012	Submitted for approval.
R3 v3.0	08 May 2012	Submitted for approval.
R3 v4.0	16 July 2012	Approval
R3 v5.0	23 July 2012	After WNPA meeting changes: ODF light information deletion and new messages proposal (APP-DRAFT).
R3 v5.1	04 September 2012	Updated version.
R3 v5.2	20 September 2012	CRs
R3 v5.3	05 October 2012	DRF comments.
R3 v5.4	11 October 2012	Updated version.
R3 v5.5	14 December 2012	Updated version.
R3 v5.6	31 January 2013	Updated version.
R3 v5.7	15 March 2013	Updated version.
R3 v6.0	09 August 2013	CR000827, CR000666, CR000906 and CR000974 - Applied
R3 v6.1	27 September 2013	CR1161 - Applied
R3 v6.2	12 December 2013	CR001748 and CR001564 - Applied

7.3 Change Log

Version	Status	Changes on version
R3 v1.0	SFR	• First version.
R3 v1.1	SFR	• Reviewer comments included.
R3 v2.0	SFA	• Submitted for approval. DRF comments applied.
R3 v2.1	SFA	• Applicable messages table updated (no impact in messages, only explanation). • Some elements of Start_list & DT_Ranking messages have been updated (no impact in messages, only explanation). • Description and Headers of Start_list, Results, Results_summary and Ranking have been updated to remove ODF Sport Data Dictionary References (no impact in messages).
R3 v3.0	SFA	• Change in Track records names. • Change done in RT_RESULTS to unify definition with DT_CONFIG (definition of intermediate points). • New fields added to manage better “Best Start” and “Best Speed” values.
R3 v4.0	APP	• RT_RESULTS - Clarify attribute descriptions. • Type in UnitInfo unified for all attributes. • DT_CONFIG – New distance format for intermediate points. • BEST_TRACK_SPEED replaced by BEST_SPEED_RECORD. • New field to define where is reached the top speed value in the track (DT_CONFIG). • DT_RANKING header values updated. • BS_INTERMEDIATE_SPEED_REL removed from DT_CONFIG. • BS_SPEED description updated in RESULTS messages.
R3 v5.0	APP (DRAFT)	• New messages proposal: Added the definition of DT_CUMULATIVE_RESULT and DT_RT_CUMULATIVE_RESULT messages (marked in blue color). These messages should be used (instead of DT_RESULT_SUMMARY and DT_RT_RESULT_SUMMARY) at the moment that these changes are approved until then the deprecated messages should be still used. • Deletion messages proposal: DT_RESULT_SUMMARY and DT_RT_RESULT_SUMMARY (marked in pink color). These messages should be deleted at the moment that these changes are approved until then the deprecated messages should be still used. • Deletion extensions proposal: ODF Light extensions from the DT_START_LIST Message. Marked in pink color the ODF Light extensions. These extensions should be deleted at the moment that these changes are approved until then they should be still used.
R3 v5.1	APP (DRAFT)	• New attributes added to message DT_RESULTS & DT_RT_RESULTS. • Modified explanation of some attributes of DT_RESULTS & DT_RT_RESULTS to clarify the contained value. • Format of Speed attribute changed to comply with format defined by ORIS. • New optional element used in message DT_START_LIST.
R3 v5.2	SFR	• Light extension: ODF Light extensions from the DT_START_LIST and DT_CUMULATIVE_RESULT Message marked in pink colour. These extensions will be deleted at the moment that these changes are implemented by Omega for Non-Olympics projects from those messages and included in new messages. • Light Extensions: DT_START_LIST PreviousResults defined as non-light extension. • New messages: Added the definition of DT_CUMULATIVE_RESULT and DT_RT_CUMULATIVE_RESULT messages. These messages should be used (instead of DT_RESULT_SUMMARY and DT_RT_RESULT_SUMMARY). • DT_EXTRA_DATA renamed to DT_OFFICIAL_EXTRA_DATA. • DT_CUMULATIVE_RESULT and DT_RT_CUMULATIVE_RESULT messages structure merged: - CumulativeResults element of DT_CUMULATIVE_RESULT and DT_RT_CUMULATIVE_RESULT renamed to Results. - Bib attribute added to Competitor and Athlete element of the DT_CUMULATIVE_RESULT and DT_RT_CUMULATIVE_RESULT messages. • SortOrder attribute clarified so that any result sort order change from the initial start list order will be provided in the SortOrder attribute (or any extension used to sort competitors) of the DT_RT_RESULT and DT_RT_CUMULATIVE_RESULT messages (this includes ranked, none-ranked and IRM athletes/team).
R3 v5.3	SFA	• Bib definition updated for individual athlete in all messages. • Bib attribute updated in PARTIC_TEAM. • Class & guide definition updated in DT_PARTIC (RegisteredEvent). • UnitDateTime updated in RESULT messages. • UnitActions in Sorting section removed in RESULT messages. • BS_BEST_START attribute format updated in RESULT messages. • WLT description updated in RESULT & CUMULATIVE_RESULT messages. • CUMULATIVE_RESULT attributes definition updated. • RecordIndicator removed from BS codes.
R3 v5.4	SFA	• Participant entries updated to identify reserve participants. • 2.2 definition updated.
R3 v5.5	APP	• CUMULATIVE_RESULT triggers updated. To send only for competition events. • Updated SPEED definition in DT_RESULT message. • BS_SPEED_RECORD added to know when exactly speed record has been achieved. • UnitInfo updated to receive Record information also with PiT messages (DT_RESULT). • UnitInfo updated to add a flag to know if record values are a new record or an old record.
R3 v5.6	APP	• 3.3 Section updated for remove codes not used for the sport • Official definition updated in START_LIST message • LAST_QUALIFIED attribute added to CUMULATIVE_RESULT message • QualificationMark is not used for Bobsleigh. Results messages updated.
R3 v5.7	APP	• New document format done (also in HTML).
R3 v6.0	APP	• CR000827 - For DT_PARTIC / DT_PARTIC_UPDATE messages and for Participant /Discipline /RegisteredEvent /EventEntry element change entry E_RESERVE by E_SUBSTITUTE (consistency across sports) • CR000666 - Added Venue attribute as mandatory for DT_PARTIC / DT_PARTIC_UPDATE and DT_PARTIC_TEAMS_UPDATE / DT_PARTIC_TEAMS messages • CR000906 - Removed ODF Light elements from DT_START_LIST and DT_CUMULATIVE_RESULTS messages • CR000974 - DT_WEATHER: Remove "+" symbol in weather attributes, when sending values above 0 degrees
R3 v6.1	APP	• CR001161: BS: SN: Add qualification mark. - New Sport Code Entity "CC @QualificationMark" - Attribute "QualificationMark" added at Result element level in all Results related messages (Event Unit Results and Cumulative Results)
R3 v6.2	APP	• CR001748 - DT_WEATHER: Weather /Conditions /Wind@Unit changed to MS / KMH • CR001564 - DT_WEATHER Weather and Wind data fixes 1) Weather /Conditions /Condition@Value defined as CC @WeatherConditions for SKY Conditions and defined as CC @SnowConditions for SNOW and ICE conditions 2) Weather /Conditions /Wind@Value defined as N(3).N(1) without plus/minus symbols 3) Weather /Conditions@Wind_Direction value defined as CC @WindDirection without possibility of being N(3)

This page has been intentionally left blank

Level 1	Level 2	Level 3	Level 4	Level 5	Level 6
Competition
	Code
	Participant (1,N)
		Code
		Parent
		Status
		GivenName
		FamilyName
		PrintName
		PrintInitialName
		TVName
		TVInitialName
		Gender
		Organisation
		BirthDate
		Height
		Weight
		PlaceofBirth
		CountryofBirth
		PlaceofResidence
		CountryofResidence
		Nationality
		MainFunctionId
		Current
		OlympicSolidarity
		ModificationIndicator
		Discipline
			Code
			InternationalFederationId
			RegisteredEvent (0,N)
				Gender
				Event
				Bib
				EventEntry (0,N)
					*Code*
					*Type*
					*Pos*
					Value

Level 1	Level 2	Level 3	Level 4	Level 5
Competition
	Code
	Team (1,N)
		Code
		Organisation
		Number
		Name
		Gender
		Current
		ModificationIndicator
		Discipline (0,1)
			Code
			InternationalFederationId
			RegisteredEvent (0,1)
				Event
				Gender
				Bib

Level 1	Level 2	Level 3	Level 4	Level 5	Level 6	Level 7
Competition
	Code
	UnitInfos (0,1)
		UnitDateTime (0,1)
			StartDate
		UnitInfo (0,N)
			*Type*
			*Code*
			*Pos*
			Value
	Officials (0,1)
		Official (1,N)
			Code
			Function
			Order
	Start (0,N)
		StartOrder
		SortOrder
		Competitor
			Code
			Type
			Bib
			EventUnitEntry (0,N)
				*Type*
				*Code*
				*Pos*
				Value
			Composition (0,1)
				Athlete (1,N)
					Code
					Order
					Bib
					EventUnitEntry (0,N)
						*Type*
						*Code*
						*Pos*
						Value

Level 1	Level 2	Level 3	Level 4	Level 5	Level 6
Competition
	Code
	UnitInfos (0,1)
		UnitDateTime (0,1)
			*StartDate*
			EndDate
		UnitInfo (0,N)
			*Type*
			*Code*
			*Pos*
			Value
	Result (1,N)
		Rank
		RankEqual
		Result
		IRM
		QualificationMark
		SortOrder
		ResultType
		Competitor (1,N)
			*Code*
			Type
			Bib
			ExtendedResults (0,1)
				ExtendedResult (1,N)
					*Type*
					*Code*
					*Pos*
					Value
			Composition
				Athlete (1,N)
					*Code*
					Order

Level 1	Level 2	Level 3	Level 4	Level 5	Level 6
Competition
	Code
	Result (1,N)
		Rank
		RankEqual
		ResultType
		Result
		IRM
		QualificationMark
		SortOrder
		ResultItems
			ResultItem (1,N)
				*Phase*
				*Unit*
				Result
					Rank
					RankEqual
					ResultType
					Result
					IRM
					QualificationMark
					SortOrder
		Competitor
			*Code*
			Type
			Bib
			ExtendedResults (0,1)
				ExtendedResult (1,N)
					*Type*
					*Code*
					*Pos*
					Value
			Composition
				Athlete (1,N)
					*Code*
					Order
					Bib

3.2.1 List of participants by discipline / List of participants by discipline Update

3.2.2 List of teams / List of teams update

3.2.3 Start List

3.2.4 Event Unit Results

3.2.5 Cumulative Results

3.2.6 Event Final Ranking

3.2.7 Event’s Medallists

3.2.8 Discipline Configuration

3.2.9 Event Unit Weather Conditions

5.2 Bobsleigh Codes

6 General definitions

6.1 ODF Message Structure