Table of content

Table of content 2

1   Introduction  2

1.1.. This document 2

1.2.. Objective. 2

1.3.. Main Audience. 2

1.4.. Glossary. 2

1.5.. Related Documents. 2

2   Overall Perspective  2

2.1.. Objective. 2

2.2.. End to End data flow. 2

3   Messages  2

3.1.. Applicable Messages. 2

3.2.. Messages. 2

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

3.2.1.1    Description. 2

3.2.1.2    Header Values. 2

3.2.1.2.1     PiT Header 2

3.2.1.3    Trigger and Frequency. 2

3.2.1.3.1     PiT Triggers. 2

3.2.1.4    Message Structure. 2

3.2.1.5    Message Values. 2

3.2.1.6    Message Sort 2

3.2.2... List of teams / List of teams update. 2

3.2.2.1    Description. 2

3.2.2.2    Header Values. 2

3.2.2.2.1     PiT Header 2

3.2.2.3    Trigger and Frequency. 2

3.2.2.3.1     PiT Triggers. 2

3.2.2.4    Message Structure. 2

3.2.2.5    Message Values. 2

3.2.2.6    Message Sort 2

3.2.3... Historical records. 2

3.2.3.1    Description. 2

3.2.3.2    Header Values. 2

3.2.3.2.1     PiT Header 2

3.2.3.3    Trigger and Frequency. 2

3.2.3.3.1     PiT Triggers. 2

3.2.3.4    Message Structure. 2

3.2.3.5    Message Values. 2

3.2.3.6    Message Sort 2

3.2.4... Start List 2

3.2.4.1    Description. 2

3.2.4.2    Header Values. 2

3.2.4.2.1     PiT Header 2

3.2.4.3    Trigger and Frequency. 2

3.2.4.3.1     PiT Triggers. 2

3.2.4.4    Message Structure. 2

3.2.4.5    Message Values. 2

3.2.4.6    Message Sort 2

3.2.5... Event Unit Results. 2

3.2.5.1    Description. 2

3.2.5.2    Header Values. 2

3.2.5.2.1     PiT Header 2

3.2.5.2.2     RT Header 2

3.2.5.3    Trigger and Frequency. 2

3.2.5.3.1     PiT Triggers. 2

3.2.5.3.2     RT Triggers. 2

3.2.5.4    Message Structure. 2

3.2.5.5    Message Values. 2

3.2.5.6    Message Sort 2

3.2.6... Phase Results. 2

3.2.6.1    Description. 2

3.2.6.2    Header Values. 2

3.2.6.2.1     PiT Header 2

3.2.6.2.2     RT Header 2

3.2.6.3    Trigger and Frequency. 2

3.2.6.3.1     PiT Triggers. 2

3.2.6.3.2     RT Triggers. 2

3.2.6.4    Message Structure. 2

3.2.6.5    Message Values. 2

3.2.6.6    Message Sort 2

3.2.7... Event Final Ranking. 2

3.2.7.1    Description. 2

3.2.7.2    Header Values. 2

3.2.7.2.1     PiT Header 2

3.2.7.3    Trigger and Frequency. 2

3.2.7.3.1     PiT Triggers. 2

3.2.7.4    Message Structure. 2

3.2.7.5    Message Values. 2

3.2.7.6    Message Sort 2

3.2.8... Event’s Medallists. 2

3.2.8.1    Description. 2

3.2.8.2    Header Values. 2

3.2.8.2.1     PiT Header 2

3.2.8.3    Trigger and Frequency. 2

3.2.8.3.1     PiT Triggers. 2

3.2.8.4    Message Structure. 2

3.2.8.5    Message Values. 2

3.2.8.6    Message Sort 2

3.2.9... Records. 2

3.2.9.1    Description. 2

3.2.9.2    Header Values. 2

3.2.9.2.1     PiT Header 2

3.2.9.3    Trigger and Frequency. 2

3.2.9.3.1     PiT Triggers. 2

3.2.9.4    Message Structure. 2

3.2.9.5    Message Values. 2

3.2.9.6    Message Sort 2

3.2.10   Discipline Configuration. 2

3.2.10.1  Description. 2

3.2.10.2  Header Values. 2

3.2.10.2.1     PiT Header 2

3.2.10.3  Trigger and Frequency. 2

3.2.10.3.1     PiT Triggers. 2

3.2.10.4  Message Structure. 2

3.2.10.5  Message Values. 2

3.2.10.6  Message Sort 2

3.2.11   Event Unit Weather Conditions. 2

3.2.11.1  Description. 2

3.2.11.2  Header Values. 2

3.2.11.2.1     PiT Header 2

3.2.11.3  Trigger and Frequency. 2

3.2.11.3.1     PiT Triggers. 2

3.2.11.4  Message Structure. 2

3.2.11.5  Message Values. 2

3.2.11.6  Message Sort 2

4   Messages Sequence  2

5   Codes  2

5.1.. Global Codes. 2

5.2.. Short Track Codes. 2

6   General definitions  2

6.1.. ODF Message Structure. Error! Bookmark not defined.

6.1.1... ODF Declaration. Error! Bookmark not defined.

6.1.2... ODF Header Error! Bookmark not defined.

6.1.3... ODF Body. Error! Bookmark not defined.

6.2.. ODF Data Types and Formats. Error! Bookmark not defined.

6.2.1... Rules for rounding numbers. Error! Bookmark not defined.

6.2.2... Measures format Error! Bookmark not defined.

6.2.3... Rules for measures conversion. Error! Bookmark not defined.

6.3.. ODF Message Update. Error! Bookmark not defined.

7   DOCUMENT CONTROL  2

7.1.. File Reference. 2

7.2.. Version history. 2

7.3.. Change Log. 2

 

1    Introduction

1.1    This document

This document includes the ODF Short Track Data Dictionary. This document refines the messages described in the ODF General Messages Interface Document specifically for Short Track, 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 Short Track Data Dictionary, with the intention that the information message producer and the message consumer can successfully interchange the information as the Short Track 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 Short Track 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_HISTORIC_RECORD

Historical records

PiT

X

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_PHASE_RESULT

Phase Results

PiT/RT

X

DT_RANKING

Event Final Ranking

PiT

X

DT_RANKING

Event Final Ranking

PiT

 

DT_MEDALLISTS

Event’s Medallists

PiT

X

DT_MEDALLISTS_DISCIPLINE

Medallists by discipline

PiT

 

DT_RECORD

Records

PiT

X

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_PHOTOFINISH

Photofinish

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

Send at the beginning of the day, or as soon as the information is known.

 

Resend if a major change.

 

 


3.2.1.4  Message Structure

Following table defines the structure of the message.

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

 

 

OfficialFunction (0,N)

 

 

 

 

 

 

FunctionId

 

 

 


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 Short Track

 

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

M

N(3) 999

 Helmet number.

 

  Example: 600, 451, 345   …

 

Participant /Discipline /RegisteredEvent /EventEntry

Send if there are specific athlete’s event entries.

Type

Code

Pos

Value

Description

E_ENTRY

E_RANK

 

N(3)

999

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos:

Do not send anything

For @Value:

The world rank of the athlete

E_SUBSTITUTE

 

S(2)

Sx (x=1..8)

For @Type:

Send proposed type

For @Code:

Send proposed code

For @ Pos:

Do not send anything

For @Value:

Indicates if the competitor is a substitute

 

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

 

Type/Code

Description

Expected

E_ENTRY/ E_RANK

The world rank of the athlete

Always

E_ENTRY/ E_SUBSTITUTE

Indicates if the competitor is a substitute event units

Always

 

 

 

Participant /OfficialFunction

Send if the official has optional functions. Do not send, otherwise.

Attribute

M/O

Value

Comments

FunctionId

M

CC @Function

Additional officials’ function code

 

 

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.

 

 


3.2.2.4  Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Competition

 

 

 

 

 

Code

 

 

 

 

Team (1,N)

 

 

 

 

 

Code

 

 

 

 

Organisation

 

 

 

 

Number

 

 

 

 

Name

 

 

 

 

Gender

 

 

 

 

Current

 

 

 

 

ModificationIndicator

 

 

 

 

Composition (0,1)

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

Code

 

 

 

 

Order

 

 

Discipline (0,1)

 

 

 

 

 

Code

 

 

 

 

InternationalFederationId

 

 

 

 

RegisteredEvent (0,1)

 

 

 

 

 

Event

 

 

 

 

Gender

 


3.2.2.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

Unique ID for competition

 

Team

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

M

N(2)

Team’s number. For ST it will be 1.

Name

M

S(73)

Team’s name.

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

 

Team /Composition /Athlete

In the case of current teams the number of athletes is 2 or more.

Attribute

M/O

Value

Comments

Code

M

S(20) with no leading zeroes

Athlete’s ID of the listed team’s member. 

 

Therefore, he/she makes part of the team’s composition.

Order

O

Numeric

Team member order

 

Team /Discipline

Each team is assigned just to one discipline.

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)

 

Team /Discipline /RegisteredEvent

Each team is assigned at least to one event, except for a historical team, which will not be registered to any event.

Attribute

M/O

Value

Comments

Event

M

CC @Event

Event ID

Gender

M

CC @DisciplineGender

Discipline Gender Code

 

 

3.2.2.6  Message Sort

The message is sorted by Team @Code.


 

 

3.2.3     Historical records

3.2.3.1  Description

The “historical records” is a message that lists the records broken in previous Competitions.

 

 

3.2.3.2  Header Values

3.2.3.2.1  PiT Header

The following table describes the ODF header attributes

 

Attribute

Value

Comment

DocumentCode

The DocumentCode attribute in the ODF header will be sent according to the ODF Common Codes document (header values sheet).

The DocumentCode attribute in the ODF header will be sent according to the ODF Common Codes document (header values sheet).

DocumentType

DT_HISTORIC_RECORD

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

Venue

CC @VenueCode

Venue where the message is generated.

 

 

3.2.3.3  Trigger and Frequency

3.2.3.3.1  PiT Triggers

“Historical records” are sent only once with a bulk message when the information is available before the competition starts.  A new version of this message substitutes previous historical record information.

 

 


3.2.3.4  Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Level 6

Level 7

Level 8

Level 9

Competition

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

HistoricalRecords

 

 

 

 

 

 

 

 

 

Record (1,N)

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

RecordType (1,N)

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

Subcode

 

 

 

 

 

 

 

 

Equalled

 

 

 

 

 

 

 

 

RecordData

 

 

 

 

 

 

 

 

 

ResultType

 

 

 

 

 

 

 

 

Result

 

 

 

 

 

 

 

Competitor (1,N)

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

 

RecordData (0,1)

 

 

 

 

 

 

 

 

 

Country

 

 

 

 

 

 

 

 

Place

 

 

 

 

 

 

 

 

Date

 

 

 

 

 

 

 

 

Confirmed

 

 

 

 

 

 

 

 

Event

 

 

 

 

 

 

 

Composition (0,1)

 

 

 

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

Order

 

 

 

 

 

 

 

 

RecordData (0,1)

 

 

 

 

 

 

 

 

 

Country

 

 

 

 

 

 

 

 

Place

 

 

 

 

 

 

 

 

Date

 

 

 

 

 

 

 

 

Confirmed

 

 

 

 

 

 

 

 

Event

 


3.2.3.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

Unique ID for competition

 

HistoricalRecords /Record

Attribute

M/O

Value

Comments

Code

M

CC @RecordCode

Record code. Send several record codes in the case several record codes are available in the historical records message.

 

HistoricalRecords /Record /RecordType

Send several elements when several records were broken for the current event unit (specified in ODF header).

It is possible to have more than one element with the same type (as in the case of National Records.

Attribute

M/O

Value

Comments

Code

M

CC @RecordType

Record type.

Subcode

O

-  NOC if Code=”NR” or “NB”

-  Rank if Code=”BOP”, “ALL” or “SBP”

-  WRC order if Code=”WRC”

It will be mandatory in case of Code=”NR”, “NB”, “BOP”, “ALL, “SBP” or “WRC”

Equalled

M

Y, N

Y-There are more than one competitor sharing the record

 

 

N-There is just one competitor holding the record

 

HistoricalRecords /Record /RecordType /RecordData

Attribute

M/O

Value

Comments

ResultType

M

CC @ResultType

It will be time.

Result

M

MM:SS.mmm

99:90.000

The result of the competitor for the record.

MM is minutes, SS is seconds, mmm is milliseconds.

 

HistoricalRecords /Record /RecordType /Competitor

Competitor to whom the record is assigned.

Athlete’s or team’s information should be in DT_PARTIC (@Current=”false”) if Competitor @Type=”A” or DT_PARTIC_TEAMS (@Current=”false”) if Competitor @Type=”T”.

Attribute

M/O

Value

Comments

Code

M

S(20) with no leading zeroes

Competitor’s ID

 

When the Competitor is an historical athlete, then this ID will start with “A” and when it is a Team it will start with “T”.

Type

M

T, A

T for team

A for athlete

 

HistoricalRecords /Record /RecordType /Competitor /RecordData

If Competitor @Type=”T”, always send.

If Competitor @Type=”A”, do not use.

Attribute

M/O

Value

Comments

Country

M

CC @Country

Country code where the record was broken

Place

M

S(40)

Place (town or city) where the record was broken (example: “Salt Lake City”).

Date

M

YYYYMMDD

Date when the record was broken.

Confirmed

O

Y,N

Send if it is being requested by the specific discipline, since some historical records / record types may not be confirmed

Event

O

S(40)

Send the text of the event name where the record was broken (example: “World Championships”, “Olympic Games”, etc.).

 

HistoricalRecords /Record /RecordType /Competitor /Composition /Athlete

Individual athlete / team member information should be in   DT_PARTIC (@Current=”false”).

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

 

This ID will start with “A” as it is an historical Athlete.

Order

M

Numeric

Order attribute used to sort team members in a team if Competitor @Type=”T” or 1 if Competitor @Type=”A”.

 

HistoricalRecords /Record /RecordType /Competitor /Composition /Athlete /RecordData

Individual athlete’s record data, according to competitors’ rules.

 

If Competitor @Type=”A”, always send.

If Competitor @Type=”T”, do not use.

Attribute

M/O

Value

Comments

Country

M

CC @Country

Country code where the record was broken

Place

M

S(40)

Place (town or city) where the record was broken (example: “Salt Lake City”).

Date

M

YYYYMMDD

Date when the record was broken.

Confirmed

O

Y,N

Send if it is being requested by the specific discipline, since some historical records / record types may not be confirmed

Event

O

S(40)

Send the text of the event name where the record was broken (example: “World Championships”, “Olympic Games”, etc.).

 

 

3.2.3.6  Message Sort

Sort by Record @Code attribute and then by RecordType @Code attribute.


 

 

3.2.4     Start List

3.2.4.1  Description

The Start List is a message containing the list of competitors for one particular event unit (individual or team event unit).

 

The Start List is a mandatory message for all disciplines.

 

Each ODF Sport Data Dictionary will include the mandatory attributes /elements of this message and redefine the optional ones.

 

 

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

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.4.3  Trigger and Frequency

3.2.4.3.1  PiT Triggers

As general rule, the message is sent as soon as the expected information is available:

-  event unit related information (PhaseInfos, UnitInfos, and Officials)

-  event unit related competitors.

 

Trigger also after any major change.

 

 


3.2.4.4  Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Level 6

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

 

 

 

 

 

Composition (0,1)

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

Code

 

 

 

 

 

Order

 

 

 

 

 

Bib

 


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

ST_RACE_NUMBER

 

N(2)

99

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos:

Do not send anything

For @Value:

Race number at the competition level

ST_RACE_ORDER

 

N(2)

99

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos:

Do not send anything

For @Value:

Race order at the round level

 

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

 

Type/Code

Description

Expected

UI_ST/ ST_RACE_NUMBER

Race number at the competition level

Always

UI_ST/ ST_RACE_ORDER

Race order at the round level

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

Send the function code for:

Referee

First Assistant Referee

Assistant Referee

Starter

Assistant Starter

Assistant referee video

Competitors Steward

Order

M

Numeric

Order of the Officials following the Sports Rule

 

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

M

Numeric

Start order of the competitor in the start list (either single athlete or team).

 

In the case of team competitor, start order of the team. The team members will have the order within the team in their respective Competitor /Composition /Athlete elements (@Order attribute).

SortOrder

M

Numeric

Same as @StartOrder

 

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,A

T for team

A for athlete

 

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

Order attribute used to sort team

members (i.e.: 1, 2..4) in a team (if Competitor @Type=”T”) or 1 if Competitor @Type=”A”.

Bib

M

S(4)

Athlete’s helmet number.

 

 

3.2.4.6  Message Sort

The message is sorted by the Start@SortOrder attribute.


 

 

3.2.5     Event Unit Results

3.2.5.1  Description

The Event Unit Results is a message containing the results of the competitors in one (individual or team) event unit.

 

The Event Unit Results is a mandatory message for all sports. The  definition includes as much generic information as possible due to the fact that each discipline and event has its own format for the results information (example: score of a match, time in a race, distance in a throw…).

 

 

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

DDGEEEPUU

The DocumentCode attribute in the ODF header will be sent according to the ODF Common Codes document (header values sheet).

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

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

DDGEEEPUU

The DocumentCode attribute in the ODF header will be sent according to the ODF Common Codes document (header values sheet).

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.5.3  Trigger and Frequency

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

 

The “qualified by time” competitors should be known at the end of phase, and for this reason, for some of the event units, the information should be resent just to inform the @QualificationMark attribute with the “QT”.

 

 

3.2.5.3.2  RT Triggers

For ResultStatus=LIVE_UPDATE:

 

o  T2: Trigger when the competitor passes the lap counter

 

o  T3: Trigger when the results are available

 

o  T4: Trigger when the leading competitor completes a new lap

 

•  For ResultStatus=LIVE_FULL

Send as it will be defined for each RT transmission in the parameters of the DT_RT_GM message.

 

•  For ResultStatus=LIVE_MANDATORY

It is sent when a correction in the previous messages has to be done.

 

•  For ResultStatus=LIVE_LAST

Send as the last message (that indicates that no new messages are expected for the given ODF unique key, unless something unexpected, that needs correction of previous messages data, happens while the transmission is still open (Good night message has not been sent)).

 

 


3.2.5.4  Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Level 6

Level 7

Level 8

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

 

 

 

 

 

 

 

RecordIndicators (0,1)

 

 

 

 

 

 

 

 

RecordIndicator (1,N)

 

 

 

 

 

 

 

 

Order

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

RecordType

 

 

 

 

 

Competitor (1,N)

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

ExtendedResults (0,1)

 

 

 

 

 

 

 

 

ExtendedResult (1,N)

 

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Pos

 

 

 

 

 

 

 

Value

 

 

 

 

 

Composition

 

 

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Order

 

 

 

 

 

 

 

Bib

 

 

 

 

 

 

 

ExtendedResults (0,1)

 

 

 

 

 

 

 

 

ExtendedResult (1,N)

 

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Pos

 

 

 

 

 

 

 

Value

 


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

 

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 that on the first day.

N

When available

EndDate

O

DateTime

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

N

When available

 

UnitInfos /UnitInfo

Unit info item associated to the event unit.

Type

Code

Pos

Value

Description

UI_RESULTS

ST_LAPS_TGO

Numeric

S(20) with no leading zeroes

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos:

Send the laps to go

 

Send 0 when the leader reach the finish line.

For @Value:

Send the code of the leader for each laps to go(could be a team or an athlete code)

 

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

 

Type/Code

Description

Expected

RT Only

RT Trigger

UI_RESULTS/ ST_LAPS_TGO

The leader of each laps_to_go during the race.

Always, for all event units

N

T2

 

 

 

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 in the corresponding event unit. This attribute is optional because the skater could get an invalid rank mark.

N

T3

RankEqual

O

Y or N

It identifies if a rank has been equalled.

For Pit just include this attribute in case of equalled ranks with value "Y".

N

T3

Result

O

MM:SS.mmm

99:90.000

or 'No Time'

Result for the particular event unit.

 

Send just in the case @ResultType is Time or 'NO_TIME' (see codes chapter)

 

MM is minutes, SS is seconds, mmm is milliseconds

May be empty in the case of a referee decision to supress time.

N

T3

IRM

O

CC @IRM

IRM for the particular event unit

 

Send just in the case @ResultType is IRM (see codes chapter)

N

T3

QualificationMark

O

CC @QualificationMark

Send just in the case the skater qualified, according to the codes

N

T3

SortOrder

M

Numeric

This attribute is a sequential number with the order of the results for the particular event unit, if they were to be presented. It is mostly based on the rank, but it should be used to sort out rank ties as well as results without rank.

 

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

T3

ResultType

O

CC @ResultType

Result type, either time or IRM for the corresponding event unit

N

T3

 

Result /RecordIndicators /RecordIndicator

Result’s record indicator.

Attribute

M/O

Value

Comments

RT Only

RT Trigger

Order

M

Numeric

Order is always ‘1’for records broken/equalled in this Event Unit.

N

Only if necessary

Code

M

CC @RecordCode

Code which describes the record broken by the result value.

N

Only if necessary

RecordType

M

CC @RecordType

Code which specifies the level at which the record is broken.

N

Only if necessary

 

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 or TBD

Competitor’s ID or TBD in case that the competitor is unknown

N

T3, T2, T4

Type

M

T,A

T for team

A for athlete

N

T3, T2, T4

 

Result /Competitor /ExtendedResults /ExtendedResult

Type and extension Type

Code

Extension Code

Pos or extension Pos

Value or extension Value

Description

ER_ST

ST_LAPS_TGO

 

 

Numeric

For @Type:

Send proposed type

For @Code:

Send proposed code

For @ Pos:

Do not send anything

For @Value:

Send the laps to go for each team

 

Send empty when the ResultType=’Time’ or  ‘IRM’

ST_LAP

 

Numeric

NumericMM:SS.mmm

99:90.000

For @Type:

Send proposed type

For @Code:

Send proposed code

For @ Pos:

The number that identifies the loop, from 1 to the total number of loops

For @Value:

Time for the Pos loop. It is cumulative.

MM is minutes, SS is seconds, mmm is milliseconds.

ST_LAP_TIME

 

MM:SS.mmm

99:90.000

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos:

Do not send anything

For @Value:

Time for the Pos loop. It is not cumulative.

MM is minutes, SS is seconds, mmm is milliseconds.

ST_RANK

 

Numeric

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos:

Do not send anything

For @Value:

Rank at the @Pos lap for the team

ST_ERANK

 

S(1)

(Y, N)

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos:

Do not send anything

For @Value:

It identifies if the rank at this point has been equalled, send “Y” in this case.

 

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

 

Type/Code/Extension Code

Description

Expected

RT Only

RT Trigger

ER_ST/ ST_LAPS_TGO

Send the laps to go for each competitor

 

Send empty when the ResultType=’Time’ or  ‘IRM’

Always for team event units

Y

T2,T4

ER_ST/ ST_LAP

Cumulative time for each lap

Always for team event units

N

T2,T4

ER_ST/ ST_LAP/ ST_LAP_TIME

The time for each lap

Always for team event units

N

T2,T4

ER_ST/ ST_LAP/ ST_RANK

Rank at the @Pos lap for the team

Always for team event units

N

T2,T4

ER_ST/ ST_LAP/ ST_ERANK

It identifies if the rank at this point has been equalled, send “Y” in this case.

Always for team event units

N

T2,T4

 

 

 

Result /Competitor /Composition /Athlete

Attribute

M/O

Value

Comments

RT Only

RT Trigger

Code

M

S(20) with no leading zeroes

Athlete’s ID. Can belong to a team member or an individual athlete.

N

T3, T2, T4

Order

M

Numeric

Order attribute used to sort team members in a team (if Competitor @Type=”T”) or 1 if Competitor @Type=”A”.

N

T3, T2, T4

Bib

M

S(4)

Athlete’s bib number.

N

T3, T2, T4

 

Result /Competitor /Composition /Athlete /ExtendedResults /ExtendedResult

Team member or individual athlete’s extended result.

Type and extension Type

Code

Extension Code

Pos or extension Pos

Value or extension Value

Description

ER_ST

ST_LEG

 

Numeric

MM:SS.mmm

99:90.000

For @Type:

Send proposed type

For @Code:

Send proposed code

For @ Pos:

The number that identifies the leg, from 1 to the total number of legs (relay)

For @Value:

Cumulative time after the @Pos leg for the team member in the leg (relay)

MM is minutes, SS is seconds, mmm is milliseconds.

ST_LAP

 

Numeric

MM:SS.mmm

99:90.000

For @Type:

Send proposed type

For @Code:

Send proposed code

For @ Pos:

The number that identifies the loop, from 1 to the total number of loops

For @Value:

Time for the Pos loop. It is cumulative. It will be for single athlete, or team member in the case of relay

 

MM is minutes, SS is seconds, mmm is milliseconds.

ST_LAP_TIME

 

MM:SS.mmm

99:90.000

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos:

Do not send anything

For @Value:

Time for the Pos loop. It is not cumulative. It will be for single athlete, or team member in the case of relay

 

MM is minutes, SS is seconds, mmm is milliseconds.

ST_RANK

 

Numeric

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos:

Do not send anything

For @Value:

Rank at the intermediate lap for the single athlete

Send empty for all the laps if the ResultType=’IRM’.

ST_ERANK

 

S(1)

(Y,N)

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos:

Do not send anything

For @Value:

It identifies if the rank at this point has been equalled, send “Y” in this case.

ST_LAPS_TGO

 

 

Numeric

For @Type:

Send proposed type

For @Code:

Send proposed code

For @ Pos:

Do not send anything

For @Value:

Send the laps to go for each competitor

 

Send empty when the ResultType=’Time’ or  ‘IRM’

 

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

 

Type/Code/Extension Code

Description

Expected

RT Only

RT Trigger

ER_ST/ ST_LEG

Cumulative time for each leg

Always for individual event units

N

T2,T4

ER_ST/ ST_LAP

Cumulative time for each lap

Always

N

T2,T4

ER_ST/ ST_LAP/ ST_LAP_TIME

The time for each lap

Always

N

T2,T4

ER_ST/ ST_LAP/ ST_RANK

Rank at the intermediate lap for the single athlete

Send empty for all the laps if the ResultType=’IRM’.

Always

N

T2,T4

ER_ST/ ST_LAP/ ST_ERANK

It identifies if the rank at this point has been equalled, send “Y” in this case.

Always

N

T2,T4

ER_ST/ ST_LAPS_TGO

Send the laps to go for each competitor

 

Send empty when the ResultType=’Time’ or  ‘IRM’

Always

Y

T2,T4

 

 

 

 

3.2.5.6  Message Sort

Sort by Result @SortOrder


 

 

3.2.6     Phase Results

3.2.6.1  Description

The Phase Results is a message containing the results for the list of competitors in a particular phase (example: Alpine Skiing Super Combined, Downhill). The “Unit” attributes (in the ODF header or the message body) will be informed with zeroes. Then, the Phase Results will be understood for the phase as a whole (not including cumulative information from previous phases), if there are rules for the particular sport in regards to it.

 

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

 

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

 

 

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

DDGEEEP00

DD according to CC @Discipline

G according to CC @DisciplineGender

EEE according to CC @Event

P according to CC @Phase

DocumentType

DT_PHASE_RESULT

Phase Results message

ResultStatus

CC @ResultStatus

It indicates whether the result is official or unofficial.

“OFFICIAL” /

“UNOFFICIAL”

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.6.2.2  RT Header

The following table describes the ODF header attributes

 

Attribute

Value

Comment

DocumentCode

DDGEEEP00

DD according to CC @Discipline

G according to CC @DisciplineGender

EEE according to CC @Event

P according to CC @Phase

DocumentType

DT_RT_PHASE_RESULT

Real Time Phase 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.6.3  Trigger and Frequency

3.2.6.3.1  PiT Triggers

The general rule is that this message is sent as soon as the last event unit for the corresponding phase finishes and the message becomes unofficial just at the end of the event unit, and afterwards when the message becomes official (when the last event unit of the phase becomes official). The official/unofficial status can be seen in ODF header (ResultStatus attribute).

 

Trigger also after any major change.

 

 

3.2.6.3.2  RT Triggers

•  For ResultStatus=LIVE_UPDATE:

 

o  T4: Trigger when the results are known (after the competitor completes his race)

 

•  For ResultStatus=LIVE_FULL:

 

o  Send as it will be defined for each RT transmission in the parameters of the DT_RT_GM message

 

•  For ResultStatus=LIVE_MANDATORY

It is sending when a correction in the previous messages has been done.

 

•  For ResultStatus=LIVE_LAST

Send as the last message (that indicates that no new messages are expected for the given ODF unique key, unless something unexpected, that needs correction of previous messages data, happens while the transmission is still open (Good night message has not been sent)).

 

 


3.2.6.4  Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Level 6

Level 7

Level 8

Competition

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Result (1,N)

 

 

 

 

 

 

 

 

Rank

 

 

 

 

 

 

 

RankEqual

 

 

 

 

 

 

 

ResultType

 

 

 

 

 

 

 

Result

 

 

 

 

 

 

 

IRM

 

 

 

 

 

 

 

QualificationMark

 

 

 

 

 

 

 

SortOrder

 

 

 

 

 

 

 

RecordIndicators (0,1)

 

 

 

 

 

 

 

 

RecordIndicator (1,N)

 

 

 

 

 

 

 

 

Order

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

RecordType

 

 

 

 

 

Competitor

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

Composition (0,1)

 

 

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Order

 

 

 

 

 

 

 

Bib

 

 

 

 

 

 

 

ExtendedResults (0,1)

 

 

 

 

 

 

 

 

ExtendedResult (1,N)

 

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Pos

 

 

 

 

 

 

 

Value

 


3.2.6.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 Phase Results message, there should be at least one competitor being awarded a result for the phase.

Attribute

M/O

Value

Comments

RT Only

RT Trigger

Rank

O

Numeric

Rank value in the course

N

T4

RankEqual

O

Y or N

It identifies if a rank has been equalled.

For Pit just include this attribute in case of equalled ranks with value "Y"

N

T4

ResultType

M

CC @ResultType

Result type, either Time or IRM for the corresponding event unit

N

T4

Result

O

MM:SS.mmm

99:90.000

Result for the particular event unit.

 

Send just in the case @ResultType is Time (see codes chapter)

 

MM is minutes, SS is seconds, mmm is milliseconds.

May be empty in the case of a referee decision to supress time.

N

T4

IRM

O

CC @IRM

IRM for the particular event unit

 

Send just in the case @ResultType is the code including Invalid Rank Mark (see codes section)

N

T4

QualificationMark

O

CC @QualificationMark

Send in case of individual and team relay events.

N

T4

SortOrder

M

Numeric

This attribute is a sequential number with the order of the results for the particular event unit, if they were to be presented. It is mostly based on the rank, but it should be used to sort out rank ties as well as results without rank.

N

T4

 

Result /RecordIndicators /RecordIndicator

Phase result’s record indicator.

Attribute

M/O

Value

Comments

RT Only

RT Trigger

Order

M

Numeric

Order is always ‘1’ for the latest (best) record of each type broken/equalled up to the current phase.

N

T4

Code

M

CC @RecordCode

Code which describes the record broken by the result value.

N

T4

RecordType

M

CC @RecordType

Code which specifies the level at which the record is broken.

N

T4

 

Result /Competitor

Competitor related to one phase result.

Attribute

M/O

Value

Comments

RT Only

RT Trigger

Code

M

S(20) with no leading zeroes

Competitor’s ID

N

T4

Type

M

T,A

T for team

A for athlete

N

T4

 

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 either a team member or a single athlete

N

T4

Order

M

Numeric

Order attribute used to sort team members in a team (if Competitor @Type=”T”) or 1 if Competitor @Type=”A”.

N

T4

Bib

M

S(4)

Athlete’s helmet number.

N

T4

 

Result /Competitor /Composition /Athlete /ExtendedResults /ExtendedResult

Team member’s or individual athlete’s extended result, depending on whether Competitor @Type=”T” or Competitor @Type=”A”.

Type

Code

Pos

Value

Description

ER_ST

ST_HEAT

 

S(15)

For @Type:

Send proposed type

For @Code:

Do not send anything

For @Pos:

Do not send anything

For @Value:

Indicates in which heat the athlete competed.

Please sent 1, 2,…A or B for the finals.

 

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

 

Type/Code

Description

Expected

RT Only

RT Trigger

ER_ST/ ST_HEAT

Indicates in which heat the athlete competed.

Please sent 1, 2,…A or B for the finals.

Always

N

N/A

 

 

 

 

3.2.6.6  Message Sort

Sort by Result @SortOrder


 

 

3.2.7     Event Final Ranking

3.2.7.1  Description

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

 

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

 

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.

 

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

 

In ST, DT_RANKING message could be blank in case no one is out of the competition after a phase.

 

 

3.2.7.2  Header Values

3.2.7.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.7.3  Trigger and Frequency

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

 

In the case of this discipline, the message is also expected at the end of each phase

 

Trigger also after any major change.

 

 


3.2.7.4  Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Level 6

Level 7

Level 8

Competition

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Result (1,N)

 

 

 

 

 

 

 

 

Rank

 

 

 

 

 

 

 

RankEqual

 

 

 

 

 

 

 

ResultType

 

 

 

 

 

 

 

Result

 

 

 

 

 

 

 

IRM

 

 

 

 

 

 

 

SortOrder

 

 

 

 

 

 

 

Competitor

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

ExtendedResults (0,1)

 

 

 

 

 

 

 

 

ExtendedResult (1,N)

 

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Pos

 

 

 

 

 

 

 

Value

 

 

 

 

 

Composition

 

 

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Order

 

 

 

 

 

 

 

ExtendedResults (0,1)

 

 

 

 

 

 

 

 

ExtendedResult (1,N)

 

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Pos

 

 

 

 

 

 

 

Value

 


3.2.7.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

Unique ID for competition

 

Result

For any event final ranking message, there should be at least one competitor being awarded a result for the event.

Attribute

M/O

Value

Comments

Rank

O

Numeric

Final rank of the competitor in the corresponding event. This attribute is optional because the competitor could get an empty rank in the case of a red card, for example.

RankEqual

O

Y

It identifies if a rank has been equalled.

ResultType

M

CC @ResultType

Result type, either time, Code or IRM for the corresponding event.

Result

O

MM:SS.mmm

99:90.000

The best time of the particular event unit.

 

Send just in the case @ResultType is Time or Code (see codes chapter)

 

MM is minutes, SS is seconds, mmm is milliseconds

May be empty in the case of a referee decision to supress time.

IRM

O

CC @IRM

IRM for the particular event.

 

Send just in the case @ResultType is IRM

SortOrder

M

Numeric

This attribute is a sequential number with the order of the results for the particular event, if they were to be presented. It is mostly based on the rank, but it should be used to sort out rank ties as well as results without rank.

 

Result /Competitor

Competitor related to one final event result.

Attribute

M/O

Value

Comments

Code

M

S(20) with no leading zeroes

Competitor’s ID.

Type

M

T,A

T for team

A for athlete

 

Result /Competitor /ExtendedResults /ExtendedResult

Team competitor’s  extended results, according to competitors’ rules.

Type

Code

Pos

Value

Description

ER_ST

ST_PHASE

 

CC @ResultPhase

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

Last Phase reached by the competitor

ST_ROUND_RANK

 

Numeric

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

The rank of the last phase reached by the competitor

ST_RESULT

 

MM:SS.mmm

99:90.000

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

The best time of the competitor achieved in any phase.

MM is minutes, SS is seconds, mmm is milliseconds.

Will be blank if IRM in the first phase.

ST_RECORD

 

CC @RecordType

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

Indicates if the result of the competitor is a record

ST_ROUND_IRM

 

CC @IRM

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

The IRM of the last phase reached by the competitor

 

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

 

Type/Code

Description

Expected

ER_ST/ ST_PHASE

Last Phase reached by the competitor

Just for the team events

ER_ST/ ST_ROUND_RANK

The rank of the competitor in the last reached phase.

Just for the team events

ER_ST/ ST_RESULT

The best time of the competitor achieved in any phase.

MM is minutes, SS is seconds, mmm is milliseconds.

Just for the team events and if no IRM in the first phase.

ER_ST/ ST_RECORD

Indicates if the result of the competitor is a record

Just for the team events

ER_ST/ ST_ROUND_IRM

The IRM of the last phase reached by the competitor

Just for the team events

 

 

 

Result /Competitor /Composition /Athlete

Attribute

M/O

Value

Comments

Code

M

S(20) with no leading zeroes

Athlete’s ID, corresponding to an individual athlete or a team member.

 

Team members should be participating in the event.

Order

M

Numeric

Order attribute used to sort team members in a team (if Competitor @Type=”T”) or 1 if Competitor @Type=”A”.

 

Result /Competitor /Composition /Athlete /ExtendedResults /ExtendedResult

 Team member’s or individual athlete’s extended result, depending on whether Competitor @Type=”T” or Competitor @Type=”A” according to competitors’ rules.

Type

Code

Pos

Value

Description

ER_ST

ST_PHASE

 

CC @ResultPhase

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

Last Phase reached by the competitor

ST_ROUND_RANK

 

Numeric

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

The rank of the last phase reached by the competitor

ST_RESULT

 

MM:SS.mmm

99:90.000

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

The best time of the competitor achieved in any phase.

MM is minutes, SS is seconds, mmm is milliseconds.

Will be blank if IRM in the first phase.

ST_RECORD

 

CC @RecordType

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

Indicates if the result of the competitor is a record

ST_ROUND_IRM

 

CC @IRM

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

The IRM of the last phase reached by the competitor

ST_ALL_RANKS

 

S(5)

9-9-9

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Value:

Rank in all qualification rounds(C74A)

 

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

 

Type/Code

Description

Expected

ER_ST/ ST_PHASE

Last Phase reached by the competitor

Just for the individual events

ER_ST/ ST_ROUND_RANK

The rank of the competitor in the last reached phase.

Just for the individual events

ER_ST/ ST_RESULT

The best time of the competitor achieved in any phase.

MM is minutes, SS is seconds, mmm is milliseconds.

Just for the individual events and if no IRM in the first phase.

ER_ST/ ST_RECORD

Indicates if the result of the competitor is a record

Just for the individual events

ER_ST/ ST_ROUND_IRM

The IRM of the last phase reached by the competitor

Just for the individual events

ER_ST/ ST_ALL_RANKS

Rank in all qualification rounds

Just for the individual events

 

 

 

 

3.2.7.6  Message Sort

Sort by Result @SortOrder


 

 

3.2.8     Event’s Medallists

3.2.8.1  Description

The “Event’s Medallists” is a message containing the list of medallists awarded in one particular event.

 

 

3.2.8.2  Header Values

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

Event’s Medallists message

ResultStatus

CC @ResultStatus

It indicates whether the result is official or partial.

“OFFICIAL” /

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

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.8.3  Trigger and Frequency

3.2.8.3.1  PiT Triggers

The message should be sent with ResultStatus=PARTIAL when the information of the medallist is know but the final event Unit is not finished.

 

The message should be sent with ResultStatus=OFFICIAL when the medallists are official known when the final event unit finishes.

 

 


3.2.8.4  Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Level 6

Competition

 

 

 

 

 

 

Code

 

 

 

 

 

Medal (1,N)

 

 

 

 

 

 

Code

 

 

 

 

 

Phase

 

 

 

 

 

Unit

 

 

 

 

 

Competitor

 

 

 

 

 

 

Type

 

 

 

 

 

Code

 

 

 

 

 

Order

 

 

 

 

 

Composition

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

Code

 

 

 

 

 

Order

 


3.2.8.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

Unique ID for competition

 

Medal

Attribute

M/O

Value

Comments

Code

M

CC @MedalType

Medal type.

 

All the Competitors with the same CC@MedalType are not grouped in the same element.

Phase

M

CC @Phase

Phase code in which a medal was awarded.

 

It is used in case of disciplines like Ice Hockey or Basketball, with the bronze medal and the gold medal awarded in different event units.

Unit

M

CC @Unit

Unit code in which a medal was awarded.

 

It is used in case of disciplines like Ice Hockey or Basketball, with the bronze medal and the gold medal awarded in different event units.

 

Medal /Competitor

Attribute

M/O

Value

Comments

Type

M

T, A

T for team

A for athlete

Code

M

S(20) with no leading zeroes

Competitor’s ID

Order

M

Numeric

Competitor order (Send 1 by default). In the case of tie the order is defined for the sport rules.

 

Medal /Competitor /Composition /Athlete

(Include all members that won the medal according to sport rules if Competitor @Type=”T”)

Attribute

M/O

Value

Comments

Code

M

S(20) with no leading zeroes

Athlete’s ID, corresponding either to a team member or an individual athlete

Order

M

Numeric

Order of the team members in a team if Competitor @Type=”T”.

 

1 if Competitor @Type=”A”.

 

 

3.2.8.6  Message Sort

The message is sorted according to the medal type. Moreover, in case of tie the order is according to the Competitor@Order (given by the sport rule). Team members are sorted according to the Athlete@Order.


 

 

3.2.9     Records

3.2.9.1  Description

This message usually applies for World and Olympic records but may apply for other records depending on the sport.

 

The message contains the list of all current records, as well as the previous records being beaten (becoming obsolete) and the invalidated records.

 

 

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

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_RECORD

Records 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

In general, this message should be sent as soon as a record is broken in the unit or as soon as a record is invalidated. However, it will be necessary to include all current valid records in case the record equals a previous record, including the event units where they may have been broken.

 

It will also be triggered in the case of invalidating previously sent records (owing to DSQ, etc.).

 

Trigger also after any major change.

 

 


3.2.9.4  Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Level 6

Level 7

Level 8

Level 9

Level 10

Competition

 

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

 

Record (1,N)

 

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

 

RecordType (1,N)

 

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

 

Subcode

 

 

 

 

 

 

 

 

 

Equalled

 

 

 

 

 

 

 

 

 

TypeOrder

 

 

 

 

 

 

 

 

 

RecordEntries

 

 

 

 

 

 

 

 

 

 

RecordEntry (1,3)

 

 

 

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

 

RecordData

 

 

 

 

 

 

 

 

 

 

ResultType

 

 

 

 

 

 

 

 

 

Result

 

 

 

 

 

 

 

 

Competitor (1,N)

 

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

 

 

RecordData (0,1)

 

 

 

 

 

 

 

 

 

 

Historical

 

 

 

 

 

 

 

 

 

RSC

 

 

 

 

 

 

 

 

 

Country

 

 

 

 

 

 

 

 

 

Place

 

 

 

 

 

 

 

 

 

Date

 

 

 

 

 

 

 

 

 

Time

 

 

 

 

 

 

 

 

 

Confirmed

 

 

 

 

 

 

 

 

 

Event

 

 

 

 

 

 

 

 

Composition (0,1)

 

 

 

 

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

 

 

Order

 

 

 

 

 

 

 

 

 

RecordData (0,1)

 

 

 

 

 

 

 

 

 

 

Historical

 

 

 

 

 

 

 

 

 

RSC

 

 

 

 

 

 

 

 

 

Country

 

 

 

 

 

 

 

 

 

Place

 

 

 

 

 

 

 

 

 

Date

 

 

 

 

 

 

 

 

 

Time

 

 

 

 

 

 

 

 

 

Confirmed

 


3.2.9.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

Unique ID for competition

 

Record

Attribute

M/O

Value

Comments

Code

M

CC @RecordCode

Record code. Send several record codes in case several record codes were broken for the current event unit.

 

Record /RecordType

Send several elements when several records were broken for the current event unit (specified in ODF header).

It is possible to have more than one element with the same type (as in the case of National Records).

Attribute

M/O

Value

Comments

Code

M

CC @RecordType

Record type.

Subcode

O

-  NOC if Code=”NR” or “NB”

-  Rank if Code=”BOP”, “ALL” or “SBP”

-  WRC order if Code=”WRC”

It will be mandatory in case of Code=”NR”, “NB”, “BOP”, “WRC”, “ALL” and “SBP”

Equalled

M

Y, N

Y-There are more than one competitor sharing the record

N-There is just one competitor holding the record

TypeOrder

M

CC @RecordType

CC @RecordType, column Order

Record Order. It indicates the hierarchy (priority) for types of records

 

Record /RecordType /RecordEntries /RecordEntry

Send the following elements ‘RecordEntry’:

 

     • New record(s) – send C & P record entries;

     • Invalidated record(s) – send C, P & I record entries

 

For invalidated records, P (previous record) will only be sent when previous records are known.

Attribute

M/O

Value

Comments

Type

M

C, P, I

C – It indicates that the record entry will include the list of current records

 

P – It indicates that the record entry will include the list of the previous record holders (now they should have been beaten)

 

I – It indicates that the record entry will include the list of the invalidated  records holders (not valid anymore)

Code

O

CC @RecordType

Record type.

In case that of RecordEntry@Type=I and if the record type code of the record to invalidate is different to the current record type code.

 

Record /RecordType /RecordEntries /RecordEntry /RecordData

Attribute

M/O

Value

Comments

ResultType

M

CC @ResultType

It will be time.

Result

M

MM:SS.mmm

99:90.000

The result of the competitor for the record

MM is minutes, SS is seconds, mmm is milliseconds.

 

Record /RecordType /RecordEntries /RecordEntry /Competitor

Competitor to whom the record is assigned.

Athlete’s or team’s information should be in DT_PARTIC (Historic) if Competitor @Type=”A” or DT_PARTIC_TEAMS (Historic) if Competitor @Type=”T”.

Attribute

M/O

Value

Comments

Code

M

S(20) with no leading zeroes

Competitor’s ID

Type

M

T, A

T for team

A for athlete

 

Record /RecordType /RecordEntries /RecordEntry /Competitor /RecordData

If Competitor @Type=”T”, always send.

If Competitor @Type=”A”, do not use.

Attribute

M/O

Value

Comments

Historical

M

Y, N

Send ‘Y’ if the record for competitor being listed in the message was not achieved during the current competition.

 

Send ‘N’ if the record for the competitor being listed in the message was achieved during the current competition

RSC

O

Concatenation of the following:

CC @Discipline

CC @DisciplineGender

CC @Event

CC @Phase

CC @Unit

Send always (Mandatory) in the case Historical=’N’.

 

Include the event unit in the current competition where the record was broken (as the event unit code is being sent in ODF header).

Country

M

CC @Country

Country code where the record was broken

Place

M

S(40)

Place (town or city) where the record was broken (example: “Salt Lake City”).

Date

M

YYYYMMDD

Date when the record was broken (for the current competition, the date will be assumed to be the date scheduled for the @RSC attribute)

Time

O

MillisTime

Send always (Mandatory) in the case of Historical=’N’.

Confirmed

O

Y, N

Send in the case Historical=’Y’ and if it is being requested by the specific discipline, since some historical records / record types may not be confirmed

Event

O

S(40)

Send in the case Historical=’Y’.

 

Send the text of the event name where the record was broken (example: “World Championships”, “Olympic Games”, etc.).

 

Record /RecordType /RecordEntries /RecordEntry /Competitor /Composition /Athlete

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

Order attribute used to sort team members in a team if Competitor @Type=”T” or 1 if Competitor @Type=”A”.

 

Record /RecordType /RecordEntries /RecordEntry /Competitor /Composition /Athlete /RecordData

Individual athlete’s record data, according to competitors’ rules.

 

If Competitor @Type=”A”, always send.

If Competitor @Type=”T”, do not use.

Attribute

M/O

Value

Comments

Historical

M

Y, N

Send ‘Y’ if the record for competitor being listed in the message was not achieved during the current competition.

 

Send ‘N’ if the record for the competitor being listed in the message was achieved during the current competition

RSC

O

Concatenation of the following:

 

CC @Discipline

CC @DisciplineGender

CC @Event

CC @Phase

CC @Unit

Send always (Mandatory) in the case Historical=’N’.

 

Include the event unit in the current competition where the record was broken (as the event unit code is being sent in ODF header).

Country

M

CC @Country

The country code where the record was broken

Place

M

S(40)

The place (town or city) where the record was broken (example: “Salt Lake City”).

Date

M

YYYYMMDD

The date when the record was broken (for the current competition, the date will be assumed to be the date scheduled for the @RSC attribute)

Time

O

MillisTime

Send always (Mandatory) in the case Historical=’N’.

Confirmed

O

Y, N

Send in the case Historical=’Y’ and if it is being requested by the specific discipline, since some historical records / record types may not be confirmed

 

 

3.2.9.6  Message Sort

The following order applies:

 

•  RecordEntry-->     First C, second P

•  Competitor, in the case RecordEntry=’C’--> Send first the competitor whose Competitor /RecordData @RSC is the ODF header (latest achieved record).


 

 

3.2.10   Discipline Configuration

3.2.10.1    Description

The Discipline Configuration is a message containing discipline general configuration.

 

Ideally the configuration for the discipline should be provided before competition. However it may be possible that the configuration for one particular event, phase or event unit is not known in advance. In that case send the unknown attributes blank (Value=“”).

 

 

3.2.10.2    Header Values

3.2.10.2.1    PiT Header

The following table describes the ODF header attributes

 

Attribute

Value

Comment

DocumentCode

DD0000000

DD according to CC @Discipline

DocumentType

DT_CONFIG

Discipline Configuration 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.10.3    Trigger and Frequency

3.2.10.3.1    PiT Triggers

The message is sent when this information is available.

 

 


3.2.10.4    Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Competition

 

 

 

 

 

Code

 

 

 

 

Configs

 

 

 

 

 

Config (1,N)

 

 

 

 

 

Gender

 

 

 

 

Event

 

 

 

 

Phase

 

 

 

 

Unit

 

 

 

 

ExtendedConfig (1,N)

 

 

 

 

 

Type

 

 

 

 

Code

 

 

 

 

Pos

 

 

 

 

Value

 


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

Numeric

Gender code

Event

O

Numeric

Event code.

Phase

O

Numeric

Phase code.

Unit

O

Numeric

Unit code.

 

Configs /Config /ExtendedConfig

Type

Code

Pos

Value

Description

EC_ST

ST_RANK_QUALIFY_NEXT_ROUND

Numeric

Numeric

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

ST_TEXT_QUALIFY_NEXT_ROUND

 

S(100)

For @Type:

Send proposed type

For @Code:

Send the proposed code

For @Pos:

Do not send anything

For @Value:

Description of the qualification rule for next phase.

ST_LAPS_CONV

Numeric

Numeric

For @Type:

Send proposed type

For @Code:

Send the proposed code

For @Pos:

The number of laps to go (remaining laps)

For @Value:

The number of the lap related to the laps to go number. (for example for 10 laps, when the athlete remains with Laps to go 7, his passed lap is 3).This value should match the possible Pos of the ST_LAP attribute.

ST_LAP_COUNT

 

Numeric

For @Type:

Send proposed type

For @Code:

Send the proposed code

For @Pos:

Do not send anything

For @Value:

The total number of laps for each event e.g. 500m – the Pos will be 5

   QUALIFY_FINAL_A

Numeric

Numeric

For @Type:

Send proposed type

For @Code:

Send the proposed code

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:

indicates how many athletes will qualify from semifinal to Final A by rank

   QUALIFY_FINAL_B

Numeric

Numeric

For @Type:

Send proposed type

For @Code:

Send the proposed code

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:

indicates how many athletes will qualify from semifinal to Final B by rank

   QUALIFY_TIME

 

Numeric

For @Type:

Send proposed type

For @Code:

Send proposed code

For @Pos :

Do not send anything

For @Value:

indicates how many athletes will qualify by time

 

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

 

Type/Code

Description

Expected

EC_ST/ ST_RANK_QUALIFY_NEXT_ROUND

Qualification for next round base on rank

The information is sent at the phase level.

Always

EC_ST/ ST_TEXT_QUALIFY_NEXT_ROUND

Qualification rule description for next round

The information is sent at the phase level.

Always

EC_ST/ ST_LAPS_CONV

Create a conversion between the current lap and the remained Laps to go.

 

The information is sent at the event level.

Always

EC_ST/ ST_LAP_COUNT

The total number of laps for each event e.g 500m - the Pos will be 5. The information is sent at the event level

Always

EC_ST/ QUALIFY_FINAL_A

indicates how many athletes will qualify from semifinal to Final A by rank

Always

EC_ST/ QUALIFY_FINAL_B

indicates how many athletes will qualify from semifinal to Final B by rank

Always

EC_ST/ QUALIFY_TIME

indicates how many athletes will qualify by time

Always

 

 

 

 

3.2.10.6    Message Sort

There is no general message sorting rule.


 

 

3.2.11   Event Unit Weather Conditions

3.2.11.1    Description

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

 

 

3.2.11.2    Header Values

3.2.11.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_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.11.3    Trigger and Frequency

3.2.11.3.1    PiT Triggers

Send one hour before each competition day and in every major change

 

 


3.2.11.4    Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Competition

 

 

 

 

 

Code

 

 

 

 

Weather

 

 

 

 

 

Conditions (1,N)

 

 

 

 

 

Code

 

 

 

 

Humidity

 

 

 

 

Condition (0,3)

 

 

 

 

 

Code

 

 

 

 

Value

 

 

 

Pressure (0,N)

 

 

 

 

 

Unit

 

 

 

 

Value

 

 

 

Temperature (0,N)

 

 

 

 

 

Code

 

 

 

 

Unit

 

 

 

 

Value

 


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

CC @WeatherPoints

Weather Points

Humidity

O

N(3)

Humidity in %

 

Weather /Conditions /Condition

Send three times in the case of Winter conditions.

Attribute

M/O

Value

Comments

Code

M

ICE

Weather conditions type

Value

M

CC @SnowConditions

Codes that describe the Ice Condition.

 

Weather /Conditions /Pressure

Attribute

M/O

Value

Comments

Unit

M

Pa

Metric system unit for pressure

Value

M

N(4)

9990

Air pressure

 

Weather /Conditions /Temperature

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

Attribute

M/O

Value

Comments

Code

M

AIR, ICE

Air, Ice temperature.

Unit

M

CC @TemperatureUnit

Celsius and Fahrenheit unit for temperature

Value

M

-N(3).N(1) -990.0 or N(3).N(1) 990.0

Temperature in Celsius and Fahrenheit degrees (in case of positive temperature, do not send '+').

 

 

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

Message

DocumentCode

DocumentSubType

ResultStatus

Comments

DT_START_LIST

DDGEEEPUU

N/A

N/A

Start List for Heat n

DT_START_LIST

DDGEEEPUU

N/A

N/A

Start List for Heat n+1

DT_RESULT

DDGEEEPUU

N/A

LIVE_UPDAT

Real Time Results for Heat n

DT_RESULT

DDGEEEPUU

N/A

UNOFFICIAL

Unofficial Results for Heat n

DT_RESULT

DDGEEEPUU

N/A

LIVE_LAST

End of Real Time Results for Heat n

DT_RESULT

DDGEEEPUU

N/A

OFFICIAL

Official Results for Heat n

DT_PHASE_RESULT

DDGEEEP00

N/A

LIVE_UPDAT

Phase Results after Heat n

DT_RESULT

DDGEEEPUU

N/A

LIVE_UPDAT

Real Time Results for Heat n+1

DT_RESULT

DDGEEEPUU

N/A

UNOFFICIAL

Unofficial Results for Heat n+1

DT_RESULT

DDGEEEPUU

N/A

LIVE_LAST

End of Real Time Results for Heat n+1

DT_RESULT

DDGEEEPUU

N/A

OFFICIAL

Official Results for Heat n+1

DT_PHASE_RESULT

DDGEEEP00

N/A

LIVE_LAST

Phase Results after Heat n+1

DT_PHASE_RESULT

DDGEEEP00

N/A

OFFICIAL

Official Phase Results after Heat n+1

DT_RANKING

DDGEEE000

N/A

PARTIAL

Event Final Ranking  after the Heats

 

2. All events QF, SF and F

Message

DocumentCode

DocumentSubType

ResultStatus

Comments

DT_START_LIST

DDGEEEPUU

N/A

N/A

Start List for QF or SF or F n

DT_START_LIST

DDGEEEPUU

N/A

N/A

Start List for QF or SF or F n+1

DT_RESULT

DDGEEEPUU

N/A

LIVE_UPDAT

Real Time Results for QF or SF or F n

DT_RESULT

DDGEEEPUU

N/A

UNOFFICIAL

Unofficial Results for QF or SF or F n

DT_RESULT

DDGEEEPUU

N/A

LIVE_LAST

End of Real Time Results for QF or SF or F n

DT_RESULT

DDGEEEPUU

N/A

OFFICIAL

Official Results for QF or SF or F n

DT_PHASE_RESULT

DDGEEEP00

N/A

LIVE_UPDAT

Phase Results after QF or SF or F n

DT_RESULT

DDGEEEPUU

N/A

LIVE_UPDAT

Real Time Results for QF or SF or F n+1

DT_RESULT

DDGEEEPUU

N/A

UNOFFICIAL

Unofficial Results for QF or SF or F n+1

DT_RESULT

DDGEEEPUU

N/A

LIVE_LAST

End of RT Results for QF or SF or F n+1

DT_RESULT

DDGEEEPUU

N/A

OFFICIAL

Official Results for QF or SF or F n+1

DT_PHASE_RESULT

DDGEEEP00

N/A

LIVE_LAST

Phase Results after QF or SF or F n+1

DT_PHASE_RESULT

DDGEEEP00

N/A

OFFICIAL

Off. Phase Res.  after QF or SF or F n+1

DT_RANKING

DDGEEE000

N/A

PAR/OFF

Event Final Ranking  after the Phase

 

 

 

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 @SnowConditions

S(7)

Defined in ODF Common Codes Document

 

See entity Snow Conditions

• The entity’s attribute to be used is Id

Link

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 @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    Short Track Codes

Code Entity

Format

Entity Description

CC @IceConditions

S(6)

Bad : Used to define the bad status of the ice

Better : Used to define the better status of the ice

Normal : Used to define the normal status of the ice

CC @IRM

S(5)

DNF : Did not finish

DNS : Did not start

DQ : Disqualified (used only in case of doping)

PEN : Penalty

RC : Red Card

YC : Yellow Card

(The codes order provided is according to the sport rules. In case of several DNF, DNS or PEN, sort by organisation code).

CC @QualificationMark

S(7)

ADV : Advanced

ADVA : Advanced to final A (for semi-final results only)

ADVB : Advanced to final B (for semi-final results only)

Q : Qualified (for all phases before semi-final results only)

QA : Qualified for final A

QB : Qualified for final B

QT : Qualified by time (Qualified as a fastest third place skater)

CC @ResultPhase

S(3)

F : Finals

H : Heats

QF : Quarterfinals

SF : Semi-finals

CC @ResultType

S(13)

CODE : Code for the group (used in event final ranking)

IRM : Invalid Result Mark

TIME : Time (not used in event final ranking)

NO_TIME: No Time

CC @TemperatureUnit

S(1)

C : Celsius

F : Fahrenheit

CC @WeatherPoints

S(6)

ICE: ICE

 


 

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

M

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

M

S(20) with no leading zeroes

Competitor’s ID

 

Type

M

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.

 

<Competitor Code= “A1” Type=”A”>

<Composition>

  <Athlete Code=”A1”  Order=”1”/>

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

 

<Competitor Code= “T1” Type=”T”>

  <Composition>

     <Athlete Code=”A1”  Order=…/>

     <Athlete Code=”A2”  Order=…/>

     …

  </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/INT019 R3 v5.4 APP (ST)

 

7.2    Version history

Version

Date

Comments

R3 v1.0

12 Mar 2012

Submitted for review version.

R3 v2.0

08 May 2012

Submitted for approval.

R3 v2.1

25 May 2012

General changes.

R3 v3.0

29 Jun 2012

Pre-integration defects applied.

R3 v3.1

31 Jul 2012

After WNPA meeting changes: ODF light information deletion and new messages proposal (APP-DRAFT).

General changes in the document.

R3 v3.2

02 Aug 2012

Pre-integration defects applied.

R3 v3.3

13 Aug 2012

Pre-integration defects applied.

R3 v3.4

20 Aug 2012

Pre-integration defects applied.

R3 v4.0

20 Sep 2012

DRF applied.

CRs applied.

R3 v4.1

11 Oct 2012

DRF applied.

R3 v4.2

29 Oct 2012

CR and defects applied.

R3 v5.0

14 Dec 2012

APP version.

R3 v5.1

15 March 2013

Small corrections due to defects

R3 v5.2

9 August 2013

CR/defects applied

R3 v5.3

13 September 2013

CR/defects applies

R3 v5.4

12 December 2013

CR applied

 

 

7.3    Change Log

Version

Status

Changes on version

R3 v1.0

SFR

• First version.

R3 v2.0

SFA

• RF requirements- March 2012-included.

• InternationalFederationId attribute added (DRF SS).

• Chapter 5.1 updated with the DT_PDF, DT_RT_GM, DT_RT_GN, DT_PDF_SERIAL, DT_PHOTOFINISH messages (DRF SS).

R3 v2.1

SFA

• DT_Result_Summary header value updated.

• ST_LAPS_TGO attribute updated.

R3 v3.0

SFA

• Defect 77861 applied.

• ST_LAPS_TGO attribute updated: Pos option removed.

• Officials ‘functions list added in the Start List message description.

• UnitInfos /UnitInfo Element updated, no extensions available.

• ST_LAP_TGO removed from the Athlete extensions.

• ST Codes updated, QR removed from the CC @QualificationMark.

• Defect 79087 applied. ST_LAP_RANK atribute removed.

• Defect 78906 applied: ST_PHASE attribute value updated.

• Defect 78907applied: CC @ResultPhase Code Entity updated.

• Defects 78882 and 79062 applied: new trigger for the message DT_RANKING. The message now is expected at the end of each phase.

R3 v3.1

SFA (DRAFT)

• New messages proposal: Added the definition of DT_PHASE_RESULT and DT_RT_PHASE_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.

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

• DT_RANKING trigger updated: at the end of the event.

• DT_RANKING updated: code added in the ResultType of the Result element.

• DT_RESULT_SUMMARY trigger updated: the message is expected also at the end of the phase.

• DT_RT_RESULT_SUMMARY trigger updated: for the RT, there are codes expected at the end of the phase.

• The extensions of the DT_RANKING removed.

• Structure file of the message DT_RANKING updated.

• CumulativeResult /Competitor /Composition /Athlete /ExtendedResults/ExtendedResult Element added in the DT_RESULT_SUMMARY message.

• CumulativeResult /Competitor /ExtendedResults/ExtendedResult Element added in the DT_RESULT_SUMMARY message.

• Structure file of the message DT_RESULT_SUMMARY updated.

• CumulativeResult /Competitor /Composition /Athlete /ExtendedResults/ExtendedResult Element added in the DT_RT_RESULT_SUMMARY message.

• CumulativeResult /Competitor /ExtendedResults/ExtendedResult Element added in the DT_RT_RESULT_SUMMARY message.

• Structure file of the message DT_RT_RESULT_SUMMARY updated.

• New codes added in the extensions of the Result Summary message.

• PiT Result Summary Header Value updated: the document code is at the event level and the document subtype is at the phase and event unit level.

R3 v3.2

SFA (DRAFT)

• Defect 78906 applied: ST_PHASE attribute value updated.

• Defect 78586 applied: DT_CONFIG message updated (ST_TEXT_QUALIFY_NEXT_ROUND is sent at the phase level).

• Defect 78691 applied: DT_CONFIG message updated (ST_LAPS_CONV is sent at the event level).

• ST_ROUND_IRM added in the Result Summary extensions.

R3 v3.3

SFA (DRAFT)

• Defect 81099 applied: UI_RESULTS /ST_LAPS_TGO attribute updated. Attribute used also in the PiT message.

R3 v3.4

SFA (DRAFT)

• Defect 81099 applied: ER_ST/ST_LAP and ER_ST/ST_LAP / ST_LAP_TIME attributes updated. Attributes used also in the PiT message.

• More explanations added for the ST_LAPS_CONV attribute.

• DT_HIST_REC_UPDATE message removed from the ‘Applicable messages’ list

• More explanations added for the (RT) Result summary message.

R3 v4.0

SFR

• Light extension: ODF Light extensions from the DT_START_LIST and DT_PHASE_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_PHASE_RESULT and DT_RT_PHASE_RESULT messages. These messages should be used (instead of DT_RESULT_SUMMARY and DT_RT_RESULT_SUMMARY).

• DT_EXTRA_DATA renamed to Play by Play (PiT and RT).

• DT_CUMULATIVE_RESULT, DT_RT_CUMULATIVE_RESULT, DT_PHASE_RESULT and DT_RT_PHASE_RESULT messages structure merged:

- PhaseInfos and PhaseInfos/PhaseInfo elements of DT_PHASE_RESULT and DT_RT_PHASE_RESULT renamed to ExtendedInfos, ExtendedInfos/ExtendedInfo.

- Bib attribute added to Competitor and Athlete element of the DT_PHASE_RESULT and DT_RT_PHASE_RESULT messages.

• SortOrder attribute clarified so that any resultsort 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, DT_RT_CUMULATIVE_RESULT and DT_PHASE_RESULT message (this includes ranked, none-ranked and IRM athletes/team).

• DT_Ranking message updated: new codes added in the competitor extensions.

• DT_Ranking trigger updated: the message is expecting also at the end of the phase.

R3 v4.1

SFA

• EndDate made optional in the UnitDateTime Element.

• Sort rule updated for the Result message.

• ResultType is optional.

• DT_RESULT message. EndDate attribute set to Optional.

• DT_START_POSITION removed from the Start /Competitor /Composition /Athlete /EventUnitEntry Element.

• UnitDateTime with optional elements.

R3 v4.2

SFA

• SCODF001 implemented: DT_HIST_REC_UPDATE message removed from the 5.1 chapter.

R3 v5.0

APP

• APP version.

R3 v5.1

APP

•Defect 89631 applied: 'Confirmed' attribute set to O for both elements RecordData from the DT_Records message

•Small correctio applied:   Record /RecordType /Competitor /Composition /Athlete Element used for ST in the Records and Historical records messages (comment added due to defect 91797)

R3 v5.2

APP

• CR832 applied: IRM 'DSQ' replaced by 'DQ' (defect 92827)

• CR666 applied: Added Venue attribute as mandatory for DT_PARTIC / DT_PARTIC_UPDATE and DT_PARTIC_TEAMS_UPDATE / DT_PARTIC_TEAMS messages.

• CR906: Removed ODF Light elements from DT_START_LIST message.

• CR974 : Remove "+" symbol in weather attributes, when sending values above 0 degrees. Change applies to DT_WEATHER message.

• CR000971 applied: DT_WEATHER message added with the related ST specific codes.

R3 v5.3

APP

CR1179 applied:

- New ResultType created: No_Time.

- The Result/Result code form the Result messages should accept as value the 'No time' label.

- The note ‘DT_RANKING message could be blank in case no one is out of the competition after a phase’ should be added in the DT_RANKING definition.

-in the Configs /Config /ExtendedConfig element of the DT_CONFIG message should be added the following codes:

QUALIFY_FINAL_A: indicates how many athletes will qualify from semifinal to Final A by rank

QUALIFY_FINAL_B: indicates how many athletes will qualify from semifinal to Final B by rank

QUALIFY_TIME: indicates how many athletes will qualify by time

-in the Phase Results message, Result /Competitor /Composition /Athlete /ExtendedResults /ExtendedResult element add the code: ST_HEAT indicating in which heat the athlete competed.

- in the /Competitor /ExtendedResults /ExtendedResult and Result /Competitor /Composition /Athlete /ExtendedResults /ExtendedResult elements add the ST_RANK and ST_ERANK extensions for the ST_LAP code.

R3 v5.4

APP

CR002499 applied:

   Defect 100811: small update in the definition of the DT_weather/Temperature element. The temperature in F should be included in the description of the codes.

 

CR02041 applied:

1)   PiT trigger updated from event unit to discipline level.

‘Frequency is 1 hour before each competition day starts and update in every major change. ‘

 2)  Weather /Conditions /Condition-Values in "VALUE" attribute must take data from CC@snowconditions.

 

 

 

This page has been intentionally left blank