MA Standards Software - Data Exchange Standard - Core V2

1

2

3

4

5

6

7

8

9

10

11

MA Standards Software - Data Exchange Standard - Core V2 12

13

14

15

16

17

18

Distribution: 19 FIFA: IT 20 21

22

Authors: 23 Patrick Steger 24 Zühlke Engineering – Software Engineering Consultant 25 [email protected] 26 27

Thomas Memmel 28 Zühlke Engineering – Usability Engineer 29 [email protected] 30

31

32

Maturity Level: 33

FIFA Standard 34

35

36

Version: 37

V 2.0 / December 2011 38

39

- 2 -

General information 40

Document identification Title: MA Standards Software – Data Exchange Standard – Core V2

File name: MA Standards Software - Data Exchange Standard - Core V2.doc

File format: MS Word 2003

Document status In progress X Final (ready for acceptance)

Document history 41

Version Reason for change Created by Date

0.1 Initial version created based on workshop input P.Steger 01.10.2009

0.2 Document review Th.

Memmel

01.10.2009

0.3 Updated enumeration values based on input from FirstSports, DFB and

Analytica and slightly changed implementation of ContractDateType. Added

Team as distinct type.

P. Steger 15.10.2009

0.4 Document Review, Applied FIFA Document Template Ch.Michels 16.10.2009

0.5 Updated contents based on feedback of the expert group. The most

important changes were:

ExportingOrganizationId is now mandatory Format of Identifier defined

Unique id generation defined

Removed semi-professional level

Added other to AddressUsageType

Renamed AddressUsageType to UsageType

Added email and phone number types and added them to PersonType and

OrganizationType Added date of death to PersonType

Added licence information to CoachType and RefereeType

Added referee role to RefereeType

Removed agent (will become an independent entity in a later phase)

Removed ITC-ID (according to TMS this should not be used)

Removed alternative ID (use custom extensions instead)

Enhanced contract information on player registration. Added PictureUsageType to PictureType.

Added FIFA to OfficalLicenceType

Extended OrganizationNatureType

Replaced unbounded multiplicities with meaningfull upper boundry to help

preventing DoS attacks for most of the types but FootbalData.

P. Steger 24.11.2009

0.6 Document Review Th.

Memmel

26.11.2009

- 3 -


0.7 Updated contents based on feedback of the expert group for the proposed

standard. The most important changes were:

ExportingOrganizationId is switched back to optional

Tax is now a type consisting of a tax id and a country code

Clarified unique id generation mechanism and changed unique identifier format to xxxxx-xxxxxxxxxx

Attributes containing only international (English) text are switched to accept

Latin characters only

Referee role is mandatory now

Renamed attribute ShortName to Alias on organization

FIFA decided that Coach and Referee Licences are just strings for the first

release so that every implementation can write there what fits her best.

P. Steger 16.12.2009

1.0 Consolidated version, release candidate Th. Memmel,

Ch. Michels

18.12.2009

1.1 Update based on Confederations input Ch. Michels 01.04.2010

1.2 Reworked based on FIFA Data Exchange Standard Workshop (18.-20.

January 2011). The most fundamental extensions and changes are:

Renamed Referee to RefereeRegistration, Coach to CoachRegistration, Fixed

Person to PersonType (as used in the xsd), renamed role (in

PlayerRegitsration, CoachRegistration, RefereeRegistration) to registration or association. Added CoachRoleType, PlayerRoleType, RefereeRoleType,

TeamColourType, PassportType, AchievementType, FingerprintType,

RefereeRankingtype, RefereeQualificationType, PositionNatureType,

AgentType. Added AlsoKnownAs to all Entities. Moved

TeamNatureTypefrom team.xsd to generic-types.xsd. Moved

RefereeRoleType from referee-registration.xsd to generic-types.xsd. Moved

CoachRoleType from coach.xsd to generic-types.xsd. Added ISO currency codes.

P. Steger 28.1.2011

1.3 Reworked based on input of PoC’s. Splitted document into two parts: Core

and Player -> Moved alle player management related types to [PDXS] (into

the new namespace http://fifa.com/exchange/fep).

Removed Fingerprint based on feedback of workshop participants (“was not

decided to be included in this version).

Added DisplayName, renamed some attributes and fixed a documentation

bug in the naming area due to suggestion of Naming PoC. Enhanced Passport based on PoC registration for competition.

Enhanced CoachRoleType based on PoC registration for competition.

Added CompetitionnatureType based on PoC registration for competition.

Added MatchPhaseNatureType based on PoC MatchReport (replaces

PeriodType from building block competition).

P.Steger 6.4.2011

1.4 Changed PersonNameType and updated dependent entities (Person). Based

on Input from the Naming PoC.

P.Steger 29.4.2011

- 4 -


1.5 PoC Naming (high level):

- Labels: PrintName renamed to ShortName

- Native-Names: Using now similar construct like we use for PersonName.

- TraditionalPersonType - equal to PersonType BUT with a mandatory first

name to make sure DFB and other westerner use cases can be handled simpler.

- Popular Name now contains a firstname (optinal) and lastname part. This is

a requirement of PoC MatchReport.

PoC Naming (detail level):

- Added NativeCompositenameType for localized names

- Added NativePersonNameType to generic-types: Allows storing localized

naming information. Used to replace all Native* Attributes - Added NativePersonType to PersonType.

- Removed Native* Attributes from PersonType

- Added TraditionalCompositeNameType containing mandatory firstname

and lastname

- Added TraditionalPersonNameType: Same as PersonNameType but with

mandatory Firstname

- Added TraditionalPersonType: Same as PersonType but with TraditionalNameType. This Type will often be used by western world system

implementations instead of PersonType.

- Added BasePersonNameType as a parent for both the existing

PersonNameType and the new TraditionalPersonNameType

- Added BasePersonType as a parent for both the existing PersonType and

the new TraditionalPersonType

- Added TraditionalPersonType to all top level Messages that support PersonType.

PoC Competition Registration:

- added FIFANationality as new Type in fifa-nationality.xsd

- added FIFANationality Attribute to the MatchPlayer

- renamed CoachRoleType to TeamOfficialRoleType

- changed enumaration values of PositionType

- changed the enumeration values of TeamOfficialRoleType (ex. CoachRoleType) to the values suggested by the PoC

- changed the enumeration values of CompetitionNatureType to the ones

suggested by the PoC

- added FIFANationality to the PersonBase

P. Steger 20.5.2011

1.6 Intermediate version for PoC MatchReport:

- Added non UTC date and time formats.

- Added additional enumeration values for CompetitionType,

RefereeRoleType, TeamOfficialRoleType - RefereeRoleType renamed to MatchOfficalRoleType

P. Steger June 2011

1.7 Changes for CompetitionNatureType as requested by the community P.Steger 1.7.2011

1.8 Moved MatchPhaseNature to competition building block.

Moved OfficialLicence and LicenceType to player building block.

Moved RoleStatusType to player building block.

Added paragraph on security requirements.

P. Steger 22.07.2011

- 5 -


1.9RC Release Candidate Version:

- Set to maturity level PROPOSED.

- Changed format and definition of Unique ID (FIFA-ID) to be a UUID

represented in canonical form with a leading flag

- Changed content of Identifier generation mechanism section. - Added requirement to use FIFA unique ID-Generator

- Changed id format/id in all examples

- DisciplineType: Added "Indoor Football" Removed

"WomenFootball"

- MatchOfficialRoleType: Added Reserve Assistant Referee, Match

Commisioner, General Coordinator

- Added AlternativeId for Person and linked it to the an external definition document

P. Steger 3.9.2011

2.0 Release Version:

- Set maturity level to FIFA Standard

- Changed FIFA community to FIFA family

- Added “other interested parties” where FIFA family is used.

- Removed references to “FIFA certification”.

- Moved ISO code XML Schema files from the Appendix to The XML

Schema section. - Added short descriptions to the XML Schema filenames and added

a reference to the XML Schema files in the XML Schema section

instead of printing the content of the files and bloating the standard

document.

- Added “U20 Man” and “U20Woman” as possible TeamNatureTypes.

- Added shared types of building blocks Player-, Referee- and Coach

Management. - Added ShortName to Organization.

- Added GeographicCoordinateType.

- Made TeamColour optional because not all teams have defined

team colours.

- Changed Copyright based on FIFA legal requirements.

P. Steger 05.12.2011

Validity 42

This process description is valid with effect from:

43

44

- 6 -

Table of Contents 45

46

1. Abstract ............................................................................................................................................... 9 47

2. Acknowledgement .............................................................................................................................. 9 48

2.1. For the data exchange standard version 2................................................................................... 9 49

2.2. For the data exchange standard version 1 .................................................................................. 10 50

3. Terminology and notational conventions ........................................................................................... 11 51

4. Namespaces ....................................................................................................................................... 11 52

5. General requirements ......................................................................................................................... 12 53

5.1. Import mechanism..................................................................................................................... 13 54

5.2. Export mechanism ..................................................................................................................... 13 55

5.3. Identifier generation mechanism ............................................................................................... 14 56

5.4. Merge rules ................................................................................................................................ 14 57

5.5. Mandatory and non-mandatory fields ....................................................................................... 15 58

5.5.1. MandatoryData .....................................................................................................................16 59

5.5.2. MandatoryPart ...................................................................................................................... 17 60 5.6. Security Requirements .............................................................................................................. 18 61

5.6.1. Authentication and authorization .......................................................................................... 18 62

5.6.2. Confidentiality and Integrity ..................................................................................................19 63

6. Message Header ................................................................................................................................ 20 64

7. Contact Management messages......................................................................................................... 23 65

7.1. Person ....................................................................................................................................... 23 66

7.2. TraditionalPerson ......................................................................................................................25 67

7.3. BasePerson ................................................................................................................................ 27 68

8. Organization Management messages ................................................................................................ 30 69

8.1. Organization .............................................................................................................................. 30 70

8.1.1. Tax ........................................................................................................................................ 35 71

8.2. Team .........................................................................................................................................36 72

9. General data types ..............................................................................................................................39 73

9.1. Simple data types ......................................................................................................................39 74

9.2. PersonName ............................................................................................................................. 44 75

9.3. TraditionalPersonName............................................................................................................ 45 76

9.4. BasePersonName ..................................................................................................................... 46 77

9.5. NativePersonName .................................................................................................................. 48 78

9.6. CompositeName....................................................................................................................... 50 79

9.7. TraditionalCompositeName ...................................................................................................... 51 80 9.8. NativeCompositeName .............................................................................................................52 81

9.9. Passport .................................................................................................................................... 53 82

9.10. Achievement ............................................................................................................................ 54 83

9.11. TeamColour ............................................................................................................................... 55 84

9.12. LocalizedString ......................................................................................................................... 56 85

9.13. LocalizedString255 .................................................................................................................... 57 86

9.14. LongLocalizedString ................................................................................................................. 58 87

9.15. Address..................................................................................................................................... 59 88

9.16. Email .........................................................................................................................................61 89

- 7 -

9.17. Phone ....................................................................................................................................... 62 90

9.18. Picture .......................................................................................................................................63 91

9.19. Sanction ................................................................................................................................... 65 92

9.20. Season ...................................................................................................................................... 66 93

9.21. Custom extension ...................................................................................................................... 67 94

9.22. Geographic Coordinate ............................................................................................................. 68 95

9.23. Person management ................................................................................................................. 70 96

9.23.1. Simple data types .............................................................................................................. 70 97

9.23.2. Licence .............................................................................................................................. 71 98

10. Abbreviations ................................................................................................................................ 72 99

11. XML Schema .................................................................................................................................. 73 100 12. References ..................................................................................................................................... 74 101

13. Copyright ....................................................................................................................................... 76 102

103

104

- 8 -

List of Figures 105

106

Pic. 1. MandatoryDataType .................................................................................................................16 107

Pic. 2. MandatoryPartType .................................................................................................................. 17 108

Pic. 3. FootballData ............................................................................................................................. 20 109

Pic. 4. PersonType ............................................................................................................................... 23 110

Pic. 5. TraditionalPersonType ..............................................................................................................25 111

Pic. 6. PersonType ............................................................................................................................... 27 112

Pic. 7. OrganizationType – Elements ................................................................................................... 30 113

Pic. 8. OrganizationType - Attributes ................................................................................................... 31 114

Pic. 9. TaxType ..................................................................................................................................... 35 115

Pic. 10. TeamType .................................................................................................................................36 116

Pic. 11. PersonNameType ..................................................................................................................... 44 117

Pic. 12. TraditionalPersonNameType .................................................................................................... 45 118

Pic. 13. BasePersonNameType ............................................................................................................. 46 119

Pic. 1. NativePersonNameType .......................................................................................................... 48 120 Pic. 2. CompositeNameType ............................................................................................................... 50 121

Pic. 3. TraditionalCompositeNameType .............................................................................................. 51 122

Pic. 4. NativeCompositeNameType .....................................................................................................52 123

Pic. 5. Passport .................................................................................................................................... 53 124

Pic. 6. Achievement ............................................................................................................................ 54 125

Pic. 7. TeamColour ............................................................................................................................... 55 126

Pic. 8. LocalizedString ......................................................................................................................... 56 127

Pic. 9. LocalizedString .......................................................................................................................... 57 128

Pic. 10. LongLocalizedString ................................................................................................................. 58 129

Pic. 11. AddressType ............................................................................................................................. 59 130

Pic. 12. EmailType..................................................................................................................................61 131

Pic. 13. PhoneType ............................................................................................................................... 62 132

Pic. 14. PictureType ...............................................................................................................................63 133

Pic. 15. SanctionType ........................................................................................................................... 65 134

Pic. 16. SeasonType .............................................................................................................................. 66 135

Pic. 17. CustomExtensionType............................................................................................................... 67 136

Pic. 18. GeographicCoordinateType ..................................................................................................... 68 137

Pic. 19. LicenceType .............................................................................................................................. 71 138

139

140

- 9 -

1. Abstract 141

This document is part of the normative technical specification for the FIFA data exchange standard. It 142

defines the core types and XML messages to exchange football related data within the FIFA family and 143

other interested parties. 144

The purpose of this specification is to support the FIFA family and other interested parties in building 145

applications and processes that enable the exchange of core football data such as persons and 146

organizations in a defined and standardized way. It provides also the foundation for all the other standards 147

(e.g. player management, competition, etc). 148

In addition the FIFA family and other interested parties can leverage common understanding and 149

agreement within the community (on the data types) to create even more advanced data exchange 150 procedures in the future. 151

152

2. Acknowledgement 153

2.1. For the data exchange standard version 2 154

The extended version 2 of this standard was created on the initiative of FIFA with participation of the FIFA 155

family. 156

The case of this standard was substantially brought forward during a three-day workshop held at FIFA 157

during January 2011. The workshop participants were: 158

• Christian Michels (FIFA, IT manager, moderator) 159

• Urs Zanitti (FIFA, MA manager) 160

• Daniel Kieser(FIFA, participant) 161

• Alexis Schreiber (CONMEBOL, participant) 162

• Tarek (CAF, participant) 163

• Leo Peyton (First Sports, participant) 164

• Stefan Siig (Sportsys, participant) 165

• Ivica Pavic (Analytica Engineering, participant) 166

• Reinaldo Vidal (FA Brazil, participant) 167

• Steffen Iredi (FA Germany/DFB, participant) 168

• Ingo Thomann (FA Germany/DFB, participant) 169

• Bob Ray (The FA, participant) 170

• Daniel Gonteri (UEFA, participant) 171

• Yeow Mei Jyn (AFC, participant) 172

• James Holroyd (TMS, participant) 173

• Pablo Ibáñez (RFEF, participant) 174

• Izhar Mahjoub (Narsiltechnologies Africa, participant) 175

• Ahmad Bhadir (FA UAE, participant) 176

• Enrique Bonilla Barrutia (FA Mexico / CONCACAF, participant) 177

• Swen Reusser (FIFA, participant) 178

• Pieter Schoneveld (Dexel, participant) 179

• Jervis Richard (thefa, participant) 180

- 10 -

• Chris Laroche (FIFA, participant) 181

• Salvatore Bucolo (FIFA, participant) 182

• Adrian Popp (FIFA, participant) 183

• Marius Schneider (FIFA, participant) 184

• Fred De Jong (OFC, participant) 185

• Torulv Norbäck (Zühlke Engineering AG, moderator) 186

• Thomas Memmel (Zühlke Engineering AG, moderator) 187

• Patrick Steger (Zühlke Engineering AG, moderator) 188

189

2.2. For the data exchange standard version 1 190

This standard was created on the initiative of FIFA with participation of the FIFA family. 191

The case of this standard was substantially brought forward during a three-day workshop held at FIFA 192

during September 2009. The workshop participants were: 193

• Christian Michels (FIFA, IT manager, moderator) 194

• Urs Zanitti (FIFA, MA manager) 195

• Shaun Lucas (First Sports, participant) 196

• Leo Peyton (First Sports, participant) 197

• Satyajit Sadanandan (Carmik Technologies Pvt. Ltd, participant) 198

• Annette Andersen (FA Denmark, participant) 199

• Stefan Siig (Sportsys, participant) 200

• John C. Jensen (Sportsys, participant) 201

• Ivica Pavic (Analytica Engineering, participant) 202

• Reinaldo Vidal (FA Brazil, participant) 203

• Gabriele Pach (FA Germany/DFB, participant) 204

• Steffen Tredi (FA Germany/DFB, participant) 205

• Ingo Thomann (FA Germany/DFB, participant) 206

• Victor Julian Stanculescu (FA UAE, part time participant) 207

• Ahmad Bahir (FA UAE, participant) 208

• Izhar Majoub (Narsil Technologies, participant) 209

• Juan Carlos Hernández González (FA Mexico, participant) 210

• Enrique Bonilla Barrutia (FA Mexico, participant) 211

• Thomas Memmel (Zühlke Engineering AG, moderator) 212

• Patrick Steger (Zühlke Engineering AG, participant) 213

214

Afterwards numerous people were involved providing valuable comments and insights: 215

• Christian Michels (FIFA, , IT Manager) 216

• Daniel Kieser (FIFA, IT Architect) 217

• Thomas Memmel (Zühlke Engineering AG, Usability Engineer) 218

• Patrick Steger (Zühlke Engineering AG, Software Architect) 219

220

- 11 -

3. Terminology and notational conventions 221

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 222

NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in 223

[RFC 2119]. 224

225

The English version of this specification is the only normative version. 226

227

This specification uses a reader friendly table structure, a graphical representation and example XML code 228

to describe the standardized types and elements on a type by type basis. At the end of the normative 229

descriptive text, references to the separate XML schema files are listed. 230 231

Where there is disagreement between the XML Schema files and the more user-friendly representations 232

(tables, graphical representations, XML examples) the XML Schema files take precedence. 233

234

The maturity levels used for this document are defined as follows. 235 Maturity level Description

Draft Standard This is the first maturity level. A draft standard has received enough publicity

within FIFA and its associated organizations and partners that it is deemed to be

useful to improve the processes or collaboration within FIFA and/or its associated

organizations and partners to be specified in detail.

In addition a draft standard is based on substantial initial input of a representative

group of affected parties and FIFA has officially decided to specify a standard.

Proposed Standard This is the second maturity level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood and

has received significant community review. However, further experience might

result in a change of the specification before it advances.

FIFA Standard This is the highest maturity level. A FIFA Standard is officially patronized and

recommended for implementation by FIFA. A FIFA Standard (which may simply be

referred to as a Standard) is characterized by a high degree of technical maturity

and by a generally held belief that the specification provides significant benefit to

the FIFA family.

236

4. Namespaces 237

The following namespaces are used in this document: 238 Prefix Namespace

xsd http://www.w3.org/2001/XMLSchema

xmime http://www.w3.org/2005/05/xmlmime

fe http://fifa.com/exchange/fe. This is the namespace of the types defined in this standard.

239

240

- 12 -

5. General requirements 241

Software implementations MUST provide all data UTF-8 encoded. 242

243

Implementations MUST NOT fail when encountering standardized content, they do not support or custom 244

extensions they do not understand. In case of encountering such content, they MUST ignore it and process 245

the reminder of the document. 246

247

To be compliant with the data exchange standard and to guarantee smooth implementation, the following 248

general requirements MUST be fulfilled: 249

• Software implementations MUST support 250 o All mandatory import/export mechanisms 251

o All mandatory import/export requirements 252

o The mandatory identifier generation mechanism 253

o The mandatory merge rules if merging data is supported 254

o The message header and all mandatory child elements and attributes required by the 255

building block 256

o All mandatory entities of at least that building block 257

• Non software implementations MUST support 258 o Paper based forms that contain all mandatory data elements 259

o The mandatory identifier generation mechanism 260

o All mandatory entities 261

• Implementations MUST NOT 262

o Duplicate any attribute defined in this standard within a custom extension 263 o Duplicate any type defined in this standard within a custom extension 264

• Implementations SHOULD 265

o Support an automated process to detect potential duplicates of exchanged data. 266

o Provide a system integrated automated and/or manual process to merge duplicates. 267

• Implementations MAY SUPPORT the custom extension mechanism. 268 269

270

- 13 -

5.1. Import mechanism 271

Software implementations MUST support file-based import of XML documents containing a root element 272

FootballData as defined in this specification. 273

274

Software implementations MAY support XML over http based import of XML documents containing a root 275

element FootballData as defined in this specification. 276 277

Software implementations MAY support a web service based import mechanism based on the types 278

defined in this specification. 279

280

Software implementations MAY support other import mechanisms based on types defined in this 281

specification. 282

283

Software implementations MUST provide a user interface to choose the elements to import for manual 284

user driven data import. 285

286

Software implementations MAY provide an automated import mode. It MUST be possible to disable the 287

automated import mode. 288

289

Software implementations SHOULD support a user interface to resolve merge issues when manually 290

importing data of entities that already exist in the system. 291

292

Software implementations SHOULD provide an advanced automated resolve function. 293

294

Software implementations SHOULD support a mechanism to detect duplicates and provide a user 295

interface to resolve these issues or provide an advanced automated resolve function. 296

5.2. Export mechanism 297

Software implementations MUST support file-based export of XML documents containing a root element 298

FootballData as defined in this specification. 299

300

Software implementations MAY support XML over http based export of XML documents containing a root 301

element FootballData as defined in this specification. 302

303

Software implementations MAY support a web service based export mechanism based on the types 304

defined in this specification. 305

306

Software implementations MAY support other export mechanisms based on types defined in this 307

specification. 308

309

Software implementations MUST provide a user interface to choose the elements to export for manual 310

user driven data export. 311 312

Software implementations MAY provide an automated export mode. It MUST be possible to disable the 313

automated export mode. 314

- 14 -

5.3. Identifier generation mechanism 315

Implementations MUST support the format and method to generate the worldwide unique identifiers (also 316

known as FIFA ID) referenced in this specification: 317

• FIFA operates a central id generation service that MUST be used by all software implementations 318 to assign worldwide unique identifiers. Detailed requirements and specifications for this service 319

can be obtained from FIFA [IDGEN]. 320

• Non-software implementations MUST request a worldwide unique identifier from FIFA by means 321 of phone, email or another communications channel. 322

• Implementations MUST assign worldwide unique identifiers to the types defined in this 323

specification at the latest when: 324

o the type transferred to another organization (implementation of this standard) 325

o the type is a professional person (e.g. a professional player) 326

o the type is a person participating in an international competition. 327

• Implementations MAY assign worldwide unique identifiers as soon as the types are created. 328

• The worldwide unique identifier remains assigned to a type forever. This means that when a type is 329

transferred between organizations, the receiving organization MUST use the already assigned 330

worldwide unique identifier without any changes. Therefore, the receiving organization MUST 331

NOT generate a new worldwide unique identifier if one already exists. 332

333

The format of the unique identifier MUST be supported by all implementations and is specified as follows: 334

• A UUID as defined in [RFC4122] with a leading flag indicating whether the identifier was 335 generated by the central id generation service or is a temporary generated id (i.e. generated 336

because the central service was not available). 337

• As format of the UUID implementations MUST support the canonical representation of a UUID 338 that contains a leading flag: 339

Format: Fxxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx 340 where 341 F = L, 0 (L=local generated temporal id, 0=central service generated id) 342 N= 8,9,a,b (see [RFC 4122]) 343 M=1,2,3,4,5 (see [RFC 4122]) 344 x=0-9,a-f (see [RFC 4122]) 345

346

5.4. Merge rules 347

If an implementation allows merging duplicate data, the following rules MUST be applied: 348

• If one identifier is generated with the central generation service and the other identifier was 349

generated by other means, then the identifier generated using the central service has to be used 350

as identifier of the merged data and the other identifier SHOULD be added to the alsoKnownAs 351

list of the data. 352

• For all other cases the following rule MUST be applied too: 353

• The lexicographically smaller unique identifier MUST be used as the identifier of the merged data. 354

The lexicographically larger unique identifier SHOULD be added to the alsoKnownAs list of the 355

data. 356

357

- 15 -

5.5. Mandatory and non-mandatory fields 358

This standard specifies XML messages containing both, mandatory and optional attributes and elements. 359

While the standard only specifies those attributes as mandatory that are always required (i.e. required for 360

all business cases), some business cases might require additional attributes and elements to be 361

mandatory. In order to make this requirement clear, implementations MAY implement the messages 362

specified below to communicate this requirement to their clients. 363 Clients MAY support these messages. 364

365

366

- 16 -

5.5.1. MandatoryData 367

ComplexType name: MandatoryDataType 368

Type MUST be supported: No 369

370

Defines a list of mandatory elements and attributes that are required in addition to the mandatory 371

elements and attributes as specified in this specification to perform a business case. 372

373 Pic. 1. MandatoryDataType 374

375 Attribute Type / Format Documentation Possible Values /

Example Mand.

ServiceName fe:String50 The name of the service or message

that needs the additional mandatory

data.

Yes

ParameterName fe:String50 The name of the parameter/root

element in the service/message that

needs additional mandatory data.

Yes

376 Element Type / Format

[Multiplicity]

Documentation Possible Values /

Example

Mand.

MandatoryPart fe:MandatoryPartType

[1..500]

The mandatory element(s) or attribute(s).

See MandatoryPartType.

Yes

377

Example: 378 <fe:MandatoryData ServiceName="PlayerRegistration" ParameterName="Transfer"> 379  380 <fe:MandatoryPart IsAttribute="true"> 381 <fe:Path>/PlayerRegistrationId</fe:Path> 382 <fe:SubPath IsAttribute="true"> <fe:Path>/Contract/Salary</fe:Path> 383 </fe:SubPath> 384 </fe:MandatoryPart> 385 </fe:MandatoryData> 386

- 17 -

5.5.2. MandatoryPart 387

ComplexType name: MandatoryPartType 388


390

Defines a mandatory element or attribute using XPath. 391

392 Pic. 2. MandatoryPartType 393


Example

Mand.

IsAttribute xsd:boolean True if the XPath references a

mandatory attribute or another entity. False if the XPath references

a mandatory element.

Yes


[Multiplicity]


Example

Mand.

Path fe:LongString

[1]

The XPath (V2.0) to the

mandatory attribute or element.

see [XPATH] Yes

SubPath fe:MandatoryPart

[0..1]

If the Path references an

fe:Identifier of another entity (that

may be passed in) the SubPath specifies what data has to be

mandatory in that entity.

No

396

Example: 397 <fe:MandatoryPart IsAttribute="true"> 398 <fe:Path>/PlayerRegistrationId</fe:Path> 399 </fe:MandatoryPart> 400

- 18 -

5.6. Security Requirements 401

When confidential data is exchanged / transmitted over non-private connections, these data MUST be 402

protected. This section defines acceptable protection methods and mechanisms. 403

5.6.1. Authentication and authorization 404

5.6.1.1. Definition 405

Authentication is the act of confirming the identity of a user (e.g. verifying username and password). 406

Authorization is the function of specifying access rights to resources (aka access control). 407

5.6.1.2. General requirement 408

Both authentication and authorization MUST be implemented when a user requests confidential data or 409

provides data for processing within a system compliant to this standard. 410 Credentials (i.e. passwords) MUST never be transmitted unencrypted. See section 5.6.2 (Confidentiality) 411

for more information on encryption requirements. 412

5.6.1.3. Authentication mechanism 413

Depending on the protocol and technology used different authentication mechanisms can be used to 414

authenticate users. 415

The following table lists acceptable authentication mechanisms for some of the most common protocols 416

and technologies the ones written in bold are the most suggested. 417 Protocol WSS HTTP Authentication Product based solution

SOAP X

SOAP over http(s) X X

RESTfull web service X

http(s) based solutions X

FTP X

418

WSS: Using one of the WSS Token Profiles such as Username Token Profile, X509 Token Profile, Kerberos 419

Token Profile, SAML Token Profile. See also [WSS]. 420

421

HTTP Authentication: One of the standardized HTTP Authentication mechanisms such as Basic 422

Authentication, Digest Authentication, Form authentication, Kerberos/SPNEGO based authentication, 423

HTTPS Client Authentication. See also [HTTP]. 424

425

Product based solution: The authentication mechanism that is provided by the used product (i.e. the FTP 426

server). 427

428

For other protocols and service implementations, the following rules of thumb SHOULD be applied: 429

• Standardized authentication mechanisms SHOULD be used if such are available. 430

• The platform or framework provided authentication mechanism SHOULD be used. 431

• Authentication information SHOULD be transported in message headers and not be mixed with 432 regular content. 433

434

- 19 -

5.6.1.4. Authorization mechanism 435

The selection of an appropriate authorization mechanism is in the responsibility of the implementation 436

and has no impact on communication partners. 437

5.6.2. Confidentiality and Integrity 438

5.6.2.1. Definition 439

Confidentiality is ensuring that information is accessible only to those authorized to have access. 440

Integrity is the assurance that only those authorized to do so can modify information 441

5.6.2.2. General requirement 442

Both, the integrity and confidentiality of exchanged / transmitted confidential data MUST be protected by 443

systems implementing this standard. 444

5.6.2.3. Protection mechanism 445

Depending on the protocol and technology used different protection mechanisms can be used to 446

guarantee the confidentiality and integrity of confidential data. 447

The following table lists acceptable protection mechanisms for some of the most common protocols and 448 technologies the ones written in bold are the most suggested. 449 Protocol WSS SSL Product based solution

SOAP X X

RESTfull web service X

http based solutions X

FTP X

other protocols X

450

WSS: Using WSS defined encryption mechanisms based on XML Encryption [XMLENC] and XML 451

Signature [XMLSIG]. See also [WSS] for the core specification of WSS. 452

453

SSL: Using SSL / TLS as underlying secure transport channel. See also [TLS]. 454

455

Product based solution: A product or protocol based non-standardized solution. 456

457

458

- 20 -

6. Message Header 459

Element name: FootballData 460

ComplexType name: FootbalDataType 461

Type MUST be supported: Yes 462

463

When performing file based import/export this is the root element of the xml document. It contains 464

information about the exporting party and the time when the export took place. This is the Envelop that 465

contains any of the standardized FIFA data records. 466

467

468 Pic. 3. FootballData 469

- 21 -


Example

Mand.

ExportingOrganizati

onName

fe:String50 The English (international) name of

the organization that created the

containing xml document.

/ FIFA Yes

ExportDate fe:DateTime The date and time when the data in the document was current.

/ 2009-10-01T11:12:12Z

Yes

ExportingOrganizati

onId

fe:Identifier The worldwide unique id of the

organization that created the

containing xml document.

No


[Multiplicity]


Example

Mand.

Organization fe:OrganizationTy

pe

[0..*]

The organization(s). See OrganizationType. No

Person fe:PersonType [0..*]

The person(s) in international format.

See PersonType. No

TraditionalPerson fe:TraditionalPers

onType

[0..*]

The person(s) in western world

format.

See

TraditionalPersonType

No

Team feTeamType

[0..*]

The team(s). See TeamType. No

any [0..*] Any custom entity.

Implementations MAY support

this element. If implementations do not support this element they

MUST ignore all content within

this element.

No

CustomExtension fe: CustomExtensionT

ype

[0..100]

To support simple key/value

custom extensions for the

FootballData type. Note: Do not

add custom extensions that

duplicate data that is defined in any other element of this

specification.

See

CustomExtensionType.

No

472

473

- 22 -

474

Example: 475 <?xml version="1.0" encoding="UTF-8"?> 476 <fe:FootballData ExportingOrganizationId=" 010000000-0000-4000-9000-000000000000" ExportDate="2001-12-477 17T09:30:47Z" ExportingOrganizationName="FIFA" 478 xsi:schemaLocation="http://fifa.com/exchange/fe football-data-1.0.xsd" 479 xmlns:fe="http://fifa.com/exchange/fe" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 480 xmlns:xmime="http://www.w3.org/2005/05/xmlmime"> 481 482 <fe:Organization Status="active" Name="FIFA" 483 OrganizationType="InternationalFederation" ... .> 484 ... 485 </fe:Organization> 486 ... 487 <fe:Person...> 488 ... 489 </fe:Person> 490 … 491 <fe:TraditionalPerson ...> 492 ... 493 </fe:TraditionalPerson> 494 ... 495 <fe:Team ShortName="Bayern" …> 496 … 497 </fe:Team> 498 … 499  500 </fe:FootballData> 501 502

503

- 23 -

7. Contact Management messages 504

7.1. Person 505

ComplexType name: PersonType 506


508

This represents a generic person that should be used for all international use cases. 509

510 Pic. 4. PersonType 511


[Multiplicity]


Example

Mand.

PersonName PersonNameType

[1]

The English (international) name

of a Person.

/ see PersonNameType

Yes

513

514

- 24 -

515

Example: 516 <fe:Person PlaceOfBirth="Três Corações, Minas Gerais" Status="active" AlternativeId="UEFA-EDAR1940000" 517 PersonId="060000000-0000-4000-9000-000000000001" Gender="male" Birthdate="1940-10-23Z" 518 CountryOfBirth="BR"> 519 <fe:Nationality>BR</fe:Nationality> 520 <fe:Nationality>CH</fe:Nationality> 521 <fe:Passport PassportNumber="CH87367435-54325345" ValidTo="2012-01-30Z" IssueDate="2010-01-30Z" /> 522 <fe:NativePersonName Language="gsw" > 523 <fe:PopularName Lastname="Péle"/> 524 </fe:NativePersonName> 525 <fe:Address AddressLine1="Weilandstrasse 22" PostalCode="8952" Town="Schlieren" Region="Zurich" 526 Country="CH"> 527 <fe:AddressUsage>default</fe:AddressUsage> 528 <fe:AddressUsage>business</fe:AddressUsage> 529 </fe:Address> 530 <fe:Email Email="[email protected]"> 531 <fe:EmailUsage>default</fe:EmailUsage> 532 </fe:Email> 533 <fe:Phone Phone="+41 44 / 444 44 44"> 534 <fe:PhoneUsage>other</fe:PhoneUsage> 535 </fe:Phone> 536 <fe:Photo xmime:contentType="image/jpeg" 537 PictureUsage="passport">YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYW538 FhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY539 WFhYWFhYQ==</fe:Photo> 540 <fe:AlsoKnownAs>060000000-0000-4000-9000-0000000000aa</fe:AlsoKnownAs> 541 <fe:PersonName> 542 <fe:Title>Dr.</fe:Title> 543 <fe:CallName Lastname="Nascimento" Firstname="Edi"/> 544 <fe:ShortName Lastname="E. A. d. Nascimento"/> 545 <fe:PopularName Lastname="Pelé" /> 546 <fe:Name Lastname="Arantes do Nascimento" Firstname="Edison"/> 547 </fe:PersonName> 548 </fe:Person> 549

550

- 25 -

7.2. TraditionalPerson 551

ComplexType name: TraditionalPersonType 552


554

This represents a generic person that can be used for western world use cases only. It features a 555

mandatory first name for convenience. Whenever possible use the PersonType instead. 556

557 Pic. 5. TraditionalPersonType 558


[Multiplicity]


Example

Mand.

PersonName TraditionalPerson

NameType

[1]


of a Person. Including a

mandatory firstname in the

official name.

/ see

TraditionalPersonNam

eType

Yes

560

561

- 26 -

Example: 562 <fe:TraditionalPerson Status="active" AlternativeId="UEFA-KUME1940000" PersonId=" 060000000-0000-4000-563 9000-000000000003" Gender="male" Birthdate="1940-10-23Z" > 564 <fe:Nationality>DE</fe:Nationality> 565 <fe:PersonName> 566 <fe:Title>Lic. Jur.</fe:Title> 567 <fe:Name Lastname="Meier" Firstname="Kurt"/> 568 </fe:PersonName> 569 </fe:TraditionalPerson> 570

571

- 27 -

7.3. BasePerson 572

ComplexType name: BasePersonType 573


575

This represents a generic person and its attributes. Every human is a person: Players, Referees, Coaches, 576

Agents, Officials, etc. This is the base definition for Person and TraditionalPerson. Do not use this type 577

directly. 578

579 Pic. 6. PersonType 580

- 28 -

Attribute Type / Format Documentation Possible Values /

Example

Mand.

PersonId fe:Identifier The worldwide unique id of the

person. The id is never changed

and accompanies a person for its

whole life. Id's are never reused.

Yes

Birthdate fe:Date The date of birth of this person. / 1972-11-21Z Yes

Gender fe:GenderType /

enumeration

The sex of the person. male

female

unspecified

Yes

Status fe:PersonStatusTy

pe / enumeration

The vitality status of the person. active (Active and alive

person, this should be

taken as default if

unknown.)

inactive (Person is no longer relevant but not

deceased)

deceased (A dead

person.)

Yes

AlternativeId xsd:string(16) The alternative id is a human

readable person id that may be

used for example in the player

passport. This id SHOULD be used whenever a person's id has to be

used in printed form and worked

with by humans.

Details of how to generate and

assign this id as well as the format

of the id can be obtained from

FIFA [IDPERS].

See [IDPERS]. Yes

DateOfDeath fe:Date The date the person died. / 2008-11-21Z No

PlaceOfBirth fe:String50 The location (town, village or

similar) where the person was

born.

/ Schlieren No

CountryOfBirth ISO3166CountyCo

de

The country where the person was

born in. Note that this is NOT the

nationality but simply where this

person was born.

One of the ISO country

codes defined in the

XML schema iso3166-

country-code.xsd. / CH

No


[Multiplicity]


Example

Mand.

Nationality ISO3166CountyCo

de

[1..10]

The nationality of the person. Or

more strictly the country code

where the person is a citizen.

One of the ISO country

codes defined in the

XML schema iso3166-

country-code.xsd. / CH

Yes

FIFANationality FIFANationalityTy

pe

[0..10]

The FIFA Nationality code. See fifa-nationality.xsd No

Passport fe:PassportType

[0..10]

Information about the Passport of

a Person.

See general data types No

- 29 -

NativePersonName fe:NativePersonNa

meType

[0..100]

The localized name of the person. See general data types. No

Address fe:AddressType

[0..20]

The address(es) of a person. See general data types. No

Email fe:EmailType [0..20]

The email address(es) of a person. See general data types. No

Phone fe:PhoneType

[0..20]

The phone number(s) of a person. See general data types. No

Photo fe:PictureType

[0..20]

The photo(s) of a person. See general data types. No

AlsoKnownAs fe:Identifier

[0..100]

The unique identifiers that are

known to be duplicates of this

Person. Note that according to

the specification all these Identifiers MUST be

lexicographically smaller than the

PersonId.

No

CustomExtension fe:CustomExtensio

nType

[0..100]

Custom extensions for the Person. See general data types. No

See Person and TraditionalPerson for examples. 582

583

- 30 -

8. Organization Management messages 584

8.1. Organization 585

ComplexType name: OrganizationType 586


588

This represents a generic organization and its attributes. All kind of organizations and companies belong 589

to this type: The FIFA, FA's, Clubs, Companies etc. 590

Organizations may be part of other (larger) organizations. In these cases an organization has a parent 591

organization. The FIFA is for example the parent organization of the DFB. 592

593

594 Pic. 7. OrganizationType – Elements 595

- 31 -

596 Pic. 8. OrganizationType - Attributes 597


Example

Mand.

OrganizationId fe:Identifier The worldwide unique id of the organization. The id is never

changed and accompanies an

organization for its whole life. Id's

are never reused.

Yes

Name fe:InternationalStri

ng50


of the organization. This is the full

name of the organization. For a

club this is for example Ballsportverein Borussia

Dortmund e.V.

/ Brazilian football

association

Yes

- 32 -


Example

Mand.

OrganizationType fe:OrganizationNa

tureType /

enumeration

The nature / kind of organization

this is. The typical hierarchy of

football related associations is:

InternationalAssociation (i.e. FIFA), Confedartion (e.g. AFC),

NationalAssociation (e.g. DFB),

RegionalAssociation(s) , Club

InternationalFederatio

n (This is the

NatureType of FIFA.)

Confederation (The NatureType of

confederations such as

UEFA or AFC.)

NationalAssociation

(The NatureType of

national associations /

federations such as the DFB.)

RegionalAssociation

(The NatureType of

first level regional

associations within a

NationalAssociation.)

RegionalAssociation2 (The NatureType of

second level regional

associations (below a

RegionalAssociation).)

RegionalAssociation3

(The NatureType of

third level regional associations (below a

RegionalAssociation2).

)

RegionalAssociation4

(The NatureType of

fourth level regional

associations (below a

RegionalAssociation3).)

RegionalAssociationN

(The NatureType of

fifth or lower level

regional associations

(below a

RegionalAssociation4 or another

RegionalAssociationN).

)

Club (The NatureType

of clubs such as Club

Américana.)

Company (The NatureType of all

commercial

companies.)

Yes

- 33 -


Example

Mand.

Other (The NatureType

of all other non football

related organizations.)

Status fe:OrganizationStatusType /

enumeration

The status of this organization. active (An active organization)

inactive (An inactive

organization)

suspended (A discipline

action stops

participation within the

world of football)

dissolved (The organization is no

longer financially

viable)

Yes

Alias fe:InternationalStri

ng50

This is the English (international)

alias of the organization. The Alias

should be a distinct unique name

that is used when unofficially talking about the organization.

This attribute is most often used

in the context of clubs. As an

example take the club with name

Ballsportverein Borussia

Dortmund e.V.: Borussia

Dortmund would be the alias

there. As another example take the club Dynamo located in

Moscow: Dynamo Moscow would

be the Alias.

/ Dynamo Bukarest No

ShortName fe:InternationalStri

ng50

This is the English (international)

short name (or abbreviation) of

the Organization. As an example,

this could be the short name FIFA

or BVB.

/ BVB

ValidFrom fe:Date The date when the Organization

was founded.

See general data types. No

ValidTo fe:Date The date when the Organization

was dissolved or superseded by

another Organization.



[Multiplicity]


Example

Mand.


[1..20]

The address(es) of the

organization.

See general data types. Yes

Email fe:EmailType [0..20]

The email address(es) of the organization.


Phone fe:PhoneType

[0..20]

The phone number(s) of the

organization.


- 34 -

ParentOrganizationI

d

fe:Identifier

[0..20]

If this organization is a child of

(an)other organization(s), this

element points to the parent

organization.


Discipline fe:DisciplineType

[0..20]

The FIFA disciplines / sports the

organization supports.


Tax fe:TaxType

[0..100]

The tax id or a similar

official/alternative id of the

organization.

see TaxType. No

NativeName fe:LocalizedString

[0..100]

The localized name of the

organization.


NativeAlias fe:LocalizedString

[0..100]

This is the localized alias of the

organization.


NativeShortName fe:LocalizedString

[0..100]

This is the localized short name of

the organization.


Language ISO639-2Type [0..20]

The language this Organization communicates in.

See Appendix. No

Logo fe:PictureType

[0..20]

The logo of the Organization. See general data types. No

Sanction fe:SanctionType

[0..100]

The sanctions against this

organization.

See SanctionType No

Season fe:SeasonType The seasons of this organization. See SeasonType No

AlsoKnownAs fe:Identifier

[0..100]

The unique identifiers that are

known to be duplicates of this

Organization. Note that according

to the specification all these Identifiers MUST be

lexicographically smaller than the

OrganizationId.

No


nType

[0..100]

Custom extensions for the

organization. Note that you may

not duplicate any existing

attributes or elements using

custom extensions.


600

601

Example: 602 <fe:Organization Alias="FIFA" OrganizationId="010000000-0000-4000-9000-000000000001" Status="active" 603 Name="Fédération Internationale de Football Association" ShortName=”FIFA” 604 OrganizationType="InternationalFederation" ValidFrom="1904-05-21Z"> 605 <fe:Address Region="a" AddressLine1="a" AddressLine2="a" AddressLine3="a" PostalCode="a" Town="a" 606 Country="AF"> 607 <fe:AddressUsage>default</fe:AddressUsage> 608 </fe:Address> 609 <fe:Address Region="a" AddressLine1="a" AddressLine2="a" AddressLine3="a" PostalCode="a" Town="a" 610 Country="AF"> 611 <fe:AddressUsage>default</fe:AddressUsage> 612 </fe:Address> 613 <fe:Address Region="a" AddressLine1="a" AddressLine2="a" AddressLine3="a" PostalCode="a" Town="a" 614 Country="AF"> 615 <fe:AddressUsage>default</fe:AddressUsage> 616 </fe:Address> 617

- 35 -

<fe:Email Email="[email protected]"> 618 <fe:EmailUsage>default</fe:EmailUsage> 619 </fe:Email> 620 <fe:Phone Phone="+41 44 / 444 44 44"> 621 <fe:PhoneUsage>other</fe:PhoneUsage> 622 </fe:Phone> 623 <fe:Discipline>Football</fe:Discipline> 624 <fe:Discipline>Football</fe:Discipline> 625 <fe:Discipline>Football</fe:Discipline> 626 <fe:Tax TaxCountry="DE" TaxId="GHFthdf56456-2454"/> 627 <fe:Tax TaxCountry="AF" TaxId="dffr564463445764676465476"/> 628 <fe:NativeName Language="abk" Value="a"/> 629 <fe:Language>ger</fe:Language> 630 <fe:Language>eng</fe:Language> 631 </fe:Organization> 632

8.1.1. Tax 633

ComplexType name: TaxType 634


636

This is the tax information for the organization. It is a combination of tax id and country. 637

638 Pic. 9. TaxType 639

640 Attribute Type / Format Documentation Possible Values / Example Mand.

TaxId fe:String50 The tax id of a

country.

Yes

TaxCountry ISO3166CountyCode The ISO country

code the tax id

belongs to.

/ DE Yes

Example: 641 <fe:Tax TaxCountry="DE" TaxId="GHFthdf56456-2454"/> 642

643

- 36 -

8.2. Team 644

ComplexType name: TeamType 645


647

This represents a generic team and its attributes. A Team always belongs to an organization. As of now 648

implementations MAY or may not support this type. However all implementations MUST NOT fail to 649

import data that contains team elements, but they MAY ignore these entries. 650

It is expected, that future enhancements to the team will occur with the introduction of 651

competitions/events in later versions/extensions of this standard. 652

653 Pic. 10. TeamType 654

655

- 37 -


Example

Mand.

TeamId fe:Identifier The worldwide unique id of the

team. The id is never changed and

accompanies a team for its whole

life. Id's are never reused.


Name fe:InternationalStri

ng50


of the team.

/ Manchester United Yes

TeamType fe:TeamNatureTyp

e / enumeration

The nature / kind of team this is

(FIFA type).


OrganizationId fe:Identifier The id of the organization where

this team belongs to.

Yes

Status fe:TeamStatusTyp

e / enumeration

The status of a team. active (An active team)

inactive (An inactive

team) suspended (A discipline

action stops

participation within the

world of football)

dissolved (The team is

no longer financially

viable)

Yes

ShortName fe:InternationalString50

The English (international) short name or the alias of the

organization.

/ ManU No

ValidFrom fe:Date The first date from which this

Team is valid.


ValidTo fe:Date The last date when this Team is

valid. After this date the Team

does no longer exist because it

was closed or

superseded/replaced by another Team.


ReplacedBy fe:identifier The TeamId of the Team that

replaces this team.

No


[Multiplicity]


Example

Mand.

Discipline fe:DisciplineType

[1..10]

The FIFA disciplines / sports the

team plays.


TeamColour fe:TeamColourTyp

e

[0..20]

The possible colours of the Team. See general data types. No


[0..20]

The address(es) of the team. See general data types. No

NativeName fe:LocalizedString

[0..100]

The localized name of the team. See general data types. No

NativeShortName fe:LocalizedString

[0..100]

The localized short name of the

team.


- 38 -

Element Type / Format

[Multiplicity]


Example

Mand.


nType

[0..100]

Custom extensions for the team.

Note that you may not duplicate

any existing attributes or

elements using custom extensions.


657

Example: 658 <fe:Team ShortName="Bayern" OrganizationId=" 010000000-0000-4000-9000-000000000002" TeamType="Man" 659 Status="active" Name="1st Team" TeamId=" 040000000-0000-4000-9000-000000000001" ValidFrom="1900-02-660 27Z"> 661 <fe:Discipline>Football</fe:Discipline> 662 <fe:TeamColour PrimaryShirtColour="Black" ColourUsage="default" PrimaryShortColour="White" /> 663 <fe:Address AddressLine1="somewhere 12" PostalCode="30300" Town="Munich" Country="DE"> 664 <fe:AddressUsage>default</fe:AddressUsage> 665 </fe:Address> 666 <fe:NativeName Language="ger" Value="1. Mannschaft"/> 667 <fe:NativeShortName Language="ger" Value="Bayern"/> 668 <fe:CustomExtension Key="Mascot"> 669 <fe:Value>Berni</fe:Value> 670 </fe:CustomExtension> 671 </fe:Team> 672

673

- 39 -

9. General data types 674

This section contains the documentation of general types. A type is considered a general type if it is used 675

by multiple ComplexTypes or Elements. 676

9.1. Simple data types 677

This section contains the documentation of general data types of type SimpleType. 678 Type Type / Format Documentation Possible Values / Example Mand.

fe:Identifier xsd:string(37) / Fxxxxxxxx-xxxx-Mxxx-Nxxx-

xxxxxxxxxxxx

where

F=L, 0

N= 8,9,a,b (see RFC4122)

M=1,2,3,4,5 (see RFC4122)

x=0..9,a..f (see RFC4122)

A worldwide unique identifier. Format as

specified by FIFA.

/ 010000000-0000-4000-9000-000000000000

Yes

fe:GenderType xsd:string / enumeration The sex of a person

or the sex of the

players of a

discipline.

male

female

unspecified

Yes

fe:Date xsd:date / .*Z A date in UTC. / 2009-11-13Z Yes

fe:DateTime xsd:dateTime / .*Z A date and time in

UTC.

/ 2009-12-31T12:00:00Z Yes

fe:DateLocal xsd:date / [0-9]*-[0-9]*-[0-

9]*

A local date. / 2010-12-31 Yes

fe:TimeLocal xsd:time / [0-9]*:[0-9]*:[0-9]*(\.[0-9]*)?

A local time. / 14:22:20 Yes

fe:String50 xsd:string / 1 <= length <=

50

A 50 character string. / Maradona Yes

fe:InternationalSt

ring50

fe:String50 / Latin

characters #x0020 to

#x027F

A 50 character string

allowing only Latin

characters.

/ Pelé Yes

fe:String255 xsd:string / 1 <= length <=

255

A 255 character

string.

/ Maradona Yes

fe:InternationalSt

ring255

fe:String255 / Latin

characters #x0020 to #x027F

A 255 character

string allowing only Latin characters.

/ Pelé Yes

fe:LongString xsd:string A very long string

with up to 1M of

characters.

/ Any string Yes

fe:InternationalLo

ngString

fe:LongString / / Latin

characters #x0020 to

#x027F

A very long string

with up to 1M of

Latin characters.

/ Any string Yes

fe:DisciplineType xsd:string / enumeration A FIFA supported

sport / competition.

Football

Futsal BeachSoccer

IndoorFootball

Yes

- 40 -

Type Type / Format Documentation Possible Values / Example Mand.

fe:UsageType xsd:string / enumeration Describes for what a

piece of information

should be used.

Default being the

peace of information to take if there is no

better matching

definition.

default (This is the default or

main peace of information

(e.g. Address). If an

application does not know

what information to use for a particular case, it selects the

information marked as

default. Wherever a

UsageType is attached to a

peace of information, exactly

one MUST be marked as

default.) business (A business

information.)

private (A private

information.)

contact (This information

should be taken to contact

the person or organization.) shipping (This information

should be used for shipping.)

billing (This information

should be taken for billing

purposes.)

mailing (This information

should be taken when mailing information.)

other (None of the other

types apply.)

Yes

ISO639-2Type xsd:string / enumeration Three-letter (alpha-

3) ISO 639-2

language code for

known languages.

See [ISO3166] Yes

ISO3166CountyC

ode

xsd:string / enumeration Two-letter (alpha-2)

ISO 3166-1 code for the countries.

See [ISO639] Yes

FIFANationalityTy

pe

xsd:string / enumeration The FIFA defined

Nationality codes.

See FIFA. Yes

EmailAddressTyp

e

fe:String50 /

[^@]+@[^\.]+\..+

The Format of an

Email address.

[email protected] Yes

- 41 -


TeamColourUsag

eType

fe.String50 / enumeration Specifies different

usage types for team

colours.

default (If no better match is

found the assosiated colours

should be taken.)

home (The assosiated colours

should be taken if this is the home team.)

guest (The assosiated colours

should be taken if this is the

guest team.)

international (The colour set

to take for international

competitions.) other (Alternative colour set if

none of the others are

possible.)

Yes

TeamNatureType fe:String50 / enumeration The nature / kind of

team this is (FIFA

type).

Woman

Man

U21 Man

U21 Woman

U20 Man U20 Woman

U19 Man

U19 Woman

U17 Man

U17 Woman

Junior Boy (All other male

junior teams) Junior Girl (All other female

junior teams)

Yes

PositionNatureTy

pe

fe:String50 / enumeration Marks the position

where the Player is

playing.

goalkeeper (Goalkeeper)

defender (Defender)

midfielder (Midfielder)

forward (Forward)

pivot (Pivot (Beach Soccer))

wing (Wing (Beach Soccer)) undefined (No position

defined or assigned yet.)

Yes

- 42 -


MatchOfficialRole

Type

fe:String50 / enumeration Possible roles of a

referee / match

official.

Referee

Assistant Referee 1

Assistant Referee 2

Reserve Assistant Referee

Referee Assistant Additional Assistant Referee 1

Additional Assistant Referee

2

Local Referee Assistant

Observer

4. Official

5. Official 6. Official

Delegate

Referee Liaison Officer

Venue Director

Venue Manager

Venue Coordinator

Venue Data Coordinator Stadium Inspector

Stadium Officer Assistant

Doping Control Officer

Security Officer

Match Reporter

Media Officer

Delegate Liaison Officer Doping Control Liaison

Officer

Timekeeper

Reserve Official

Appeal Body

Disciplinary Commision

Disciplinary Inspector

Team Liaison Officer Mentor for Delegate

Mentor for Referee Observer

Mentor for Security Officer

Fairplay Observer

Tournament Administrator

Match Commissioner

General Coordinator other

Yes

- 43 -


TeamOfficialRole

Type

fe:String50 / enumeration The possible roles for

a team official.

Coach

Assistant Coach

Goalkeeper Coach

Team Manager

Physiotherapist Kit Manager

Doping Control Liaison

Officer

other

Cook

Equipment Manager

Goalkeeper Coach Head of Administration

Head of Delegation

Interpreter

Kinesiologist

Liaison Officer for Security

Matters

Masseur Member of Delegation

Physical Trainer

Player

Team Doctor

Team Media Officer

Team Official

Translator Director

2nd Assistant Coach

Assistant Physiotherapist

Statistician / Assistant Coach

Technical Director

Observer

Store-Keeper

Waiter Website Editor

Scouting Coordinator

Exercise Scientist

Video Technician

Yes

679

680

- 44 -

9.2. PersonName 681

ComplexType name: PersonNameType 682


684

This is the English (international) name of a Person. 685

686 Pic. 11. PersonNameType 687


[Multiplicity]


Example

Mand.

Name fe:CompositeNameTy

pe

The official (international)

name of the person. A

container to hold first name

and last name. .

/ see CompositeNameType

Yes

689 Example: 690 <fe:PersonName> 691 <fe:Title>Shaikh</fe:Title> 692 <fe:CallName Lastname="SH. SALMAN EBRAHIM ALKHALIFA" /> 693 <fe:Name Lastname="SALMAN BIN EBRAHIM BIN HAMAD AL-KHALIFA" /> 694 </fe:PersonName> 695 696 <fe:PersonName> 697 <fe:Title>Dr.</fe:Title> 698 <fe:CallName Lastname="Nascimento" Firstname="Edi"/> 699 <fe:ShortName Lastname="E. A. d. Nascimento"/> 700 <fe:PopularName Lastname=“Pelé”/ > 701

- 45 -

<fe:Name Lastname="Arantes do Nascimento" Firstname="Edison"/> 702 </fe:PersonName> 703

9.3. TraditionalPersonName 704

ComplexType name: TraditionalPersonNameType 705


707


709 Pic. 12. TraditionalPersonNameType 710


[Multiplicity]


Example

Mand.

Name fe:TraditionalComposi

teNameType

The English (international)

name of a Person with a

mandatory first name as official

name. Manly used for western

world only use cases.

/ see TraditionalCompositeNameType

Yes

712

713 Example: 714 <fe:PersonName> 715 <fe:Title>Dr.</fe:Title> 716 <fe:CallName Lastname="Nascimento" Firstname="Edi"/> 717 <fe:ShortName Lastname="E. A. d. Nascimento"/> 718 <fe:PopularName Lastname=”Pelé” /> 719 <fe:Name Lastname="Arantes do Nascimento" Firstname="Edison"/> 720 </fe:PersonName> 721 722

723

- 46 -

9.4. BasePersonName 724

ComplexType name: BasePersonNameType 725


727


729 Pic. 13. BasePersonNameType 730

731

- 47 -

Element Type / Format

[Multiplicity]


Example

Mand.

Title fe:InternationalString50 The (international) Title of the

person. This can be for

example Dr., Shaikh or DATO'

DR.

/ Dato Dr. No

CallName fe:CompositeNameType Defines how the person

wants to be called.


No

ShortName fe:CompositeNameType Short writing form for

extremely long names (e.g.

Sri Lankan names).


No

PopularName fe:CompositeNameType The English (international)

alias, common or popular

name of this person. Also

known as Football name and often only the lastname field

is used (e.g. Péle).


No

732

For examples, see PersonName and TraditionalPersonName. 733

734

- 48 -

9.5. NativePersonName 735

ComplexType name: NativePersonNameType 736


738

This is the localized name of a Person. 739

740 Pic. 1. NativePersonNameType 741

- 49 -

Attribute Type / Format Documentation Possible Values / Example Mand.

Language fe:ISO639-2Type The language this

localized name is

written in.

One of the ISO language

codes defined in the schema

iso639-2-language-code.xsd. /

ara

Yes

742


[Multiplicity] Documentation Possible Values /

Example Mand.

Name fe:NativeCompositeNa

meType

The localized name of a Person. / see NativelCompositeNameType

No

Title

fe:String50 The localized Title of the

person. This can be for example

Dr., Shaikh or DATO' DR..

/ Dato Dr. No

CallName fe:NativeCompositeNa

meType

Defines how the person wants

to be called.

/ see NativelCompositeNameType

No

ShortName fe: NativeCompositeNam

eType

Short writing form for extremely long names (e.g. Sri

Lankan names).


No

PopularName fe:

NativeCompositeNam

eType

The localized alias, common or

popular name of this person.

Also known as Football name

and often only the lastname

field is used (e.g. Péle).


No

744

Example: 745 <fe:NativePersonName Language="ara" > 746 <fe:Name Lastname="747 </ "بـــا�ك </fe:NativePersonName> 748 749

750

- 50 -

9.6. CompositeName 751

ComplexType name: CompositeNameType 752


754

This is the English (international) name of a Person. It is composed out of a First Name and Last Name. 755

756 Pic. 2. CompositeNameType 757


Firstname fe:InternationalString50 The English

(international) first

name of the person.

/ Edison No

Lastname fe: InternationalString255 The English (international) last

name(s) (family

name(s)) of the

person.

/ Arantes do Nascimento Yes

Example: 759 <fe:Name firstname="Diego Armando" Lastname="Maradona" /> 760 761 <fe:Name Lastname="Diego Armando Maradona" /> 762 763

764

- 51 -

9.7. TraditionalCompositeName 765

ComplexType name: TraditionalCompositeNameType 766


768

This is the English (international) name of a Person. It is composed out of a mandatory First Name and a 769

mandatory Last Name. This Name is manly used in western countries where official names are required to 770

have a firstname part. If possible use CompositeName instead. 771

772 Pic. 3. TraditionalCompositeNameType 773


Firstname fe:InternationalString50 The English

(international) first

name of the person.

/ Edison Yes

Lastname fe: InternationalString255 The English

(international) last

name(s) (family

name(s)) of the person.


Example: 775 <fe:Name firstname="Diego Armando" Lastname="Maradona" /> 776

777

- 52 -

9.8. NativeCompositeName 778

ComplexType name: NativeCompositeNameType 779


781

This is the localized name of a Person. It is composed out of an optional First Name and a mandatory Last 782

Name. 783

784 Pic. 4. NativeCompositeNameType 785


Firstname fe:String50 The localized first name (given name)

of the person.

/ Edison Yes

Lastname fe:String255 The localized last

name (family name)

of the person.


Example: 787 <fe:Name Lastname="="ـــا�ك 788 </ " ب 789

790

- 53 -

9.9. Passport 791

ComplexType name: PassportType 792


794

This type contains information about the Passport of a Person. 795

796 Pic. 5. Passport 797


PassportNumber fe:InternationalString50 The passport number / CH2734-67 Yes

ValidTo fe:Date The date when this

passport stops to be

valid.

Yes

IssueDate fe:Date The date when this

passport was issued. Yes

Example: 799 <fe:Passport PassportNumber="CH2367-3467" ValidTo="2012-01-30Z" IssueDate="2010-01-30Z" /> 800

801

- 54 -

9.10. Achievement 802

ComplexType name: AchievementType 803


805

This type contains information about an Achievement of a Person. 806

807 Pic. 6. Achievement 808


Title fe:String50 The title of the

achievement. Yes

AwardDate fe:Date The Date when the

Achievement was

awarded to the

person.

see generic data types. No

Example: 810 <fe:Achievement Title="Player of the Year" AwardDate="2010-01-30Z" /> 811

812

- 55 -

9.11. TeamColour 813

ComplexType name: TeamColourType 814


816

This type contains information about the colours of a team. 817

818 Pic. 7. TeamColour 819


PrimaryShirtColo

ur

fe:InternationalString50 The first colour of

the shirts. Yes

PrimaryShortColo

ur


the shorts.

Yes

ColourUsage fe:TeamColourUsageType Defines when this

colour schema should be selected.

At least one shirt

colour entry MUST

be default. The

default usage type

specifies the colours

to use if no better match was found.

See simple general types. Yes

- 56 -


PrimarySockColo

ur


the socks. No

SecondaryShirtCo

lour

fe:InternationalString50 The second colour of

the shirts. No

SecondaryShortC

olour


the shorts. No

SecondarySockCo

lour


the socks. No

Example: 821 <fe:TeamColour PrimaryShirtColour="Black" ColourUsage="default" PrimaryShortColour="White" 822 SecondaryShirtColour="White"/> 823

9.12. LocalizedString 824

ComplexType name: LocalizedString 825


827

This type relates a string to a language. The string represents text in the related language. 828

829 Pic. 8. LocalizedString 830


Language ISO639-2Type The language of the

localized string.




ara

Yes

Value fe:String50 The localized native

string.

Yes اكبـــال /

Example: 832 <fe:NativeLastName Language="ara" Value="ـــا�ك 833 </"ب

834

- 57 -

9.13. LocalizedString255 835

ComplexType name: LocalizedString255 836


838


840 Pic. 9. LocalizedString 841



localized string.




ara

Yes

Value fe:String255 The localized native

string.

ـــا�ك / Yes ب

Example: 843 <fe:NativeFullName Language="ara" Value="844 </"بـــا�ك

845

- 58 -

9.14. LongLocalizedString 846

ComplexType name: LocalizedString 847


849


851 Pic. 10. LongLocalizedString 852



localized string.


codes defined in the schema iso639-2-language-code.xsd. /

ara

Yes


[Multiplicity]

Documentation Possible Values / Example Mand.

Value fe:LongString

[1]

The localized native

string.

ـــا�ك / Yes ب

855

Example: 856 <fe:NativeValue Language="ara"> 857 <fe:Value>ـــا�ك fe:Value> 858/>ب</fe:NativeValue> 859

860

- 59 -

9.15. Address 861

ComplexType name: AddressType 862


864

This represents a traditional (mail) address. 865

866

867 Pic. 11. AddressType 868


Country ISO3166CountyCode The country of the address.

/ CH Yes

Town fe:String50 The town, village or

location name of the

address.

/ Schlieren Yes

- 60 -

PostalCode fe:String50 The postal code or a

similar construct.

/ 8952 No

AddressLine1 fe:String50 This is the generic

line 1 of an address.

Often this is a street

and building number, P.O. Box or similar.

/ Wiesenstrasse 10a No



Often this is an

apartment, building,

floor etc.

/ Building Alpha, Floor 2 No



No

Region fe:String50 This is the state, province or region.

/ Zurich No


[Multiplicity]


AddressUsage fe:UsageType

[1..10]

This is the code

describing what the

address is used for.

Each address needs

at least one AddressUsage.

Exactly one address

in a list MUST have

UsageType default.

see UsageType. Yes

870

Example: 871 <fe:Address AddressLine1="Weilandstrasse 22" PostalCode="8952" Town="Schlieren" Region="Zurich" 872 Country="CH"> 873 <fe:AddressUsage>default</fe:AddressUsage> 874 <fe:AddressUsage>business</fe:AddressUsage> 875 </fe:Address> 876

877

- 61 -

9.16. Email 878

ComplexType name: EmailType 879


881

This represents an Email address. 882

883

884 Pic. 12. EmailType 885


Email EmailAddressType The email / [email protected] Yes


[Multiplicity]


EmailUsage fe:UsageType

[1..10]

This is the code

describing what the

email is used for. Each email needs at

least one

EmailUsage. Exactly

one email in a list

MUST have

UsageType default.

see UsageType. Yes

887

Example: 888 <fe:Email Email="[email protected]" > 889 <fe:EmailUsage>default</fe:EmailUsage> 890 </fe:Email> 891

892

- 62 -

9.17. Phone 893

ComplexType name: PhoneType 894


896

This represents a phone number. 897

898

899 Pic. 13. PhoneType 900


Phone fe:String50 The phone number. / +41 44 / 444 44 44 Yes


[Multiplicity]


PhoneUsage fe:UsageType

[1..10]

This is the code

describing what the

phone number is

used for. Each phone number needs at

least one

PhoneUsage. Exactly

one phone number in

a list MUST have

UsageType default.

see simple data types /

default

Yes

902

Example: 903 <fe:Phone Phone="+41 44 / 444 44 44"> 904 <fe:PhoneUsage>other</fe:PhoneUsage> 905 </fe:Phone> 906

907

- 63 -

9.18. Picture 908

ComplexType name: PictureType 909


911

This represents a picture. 912

913

914 Pic. 14. PictureType 915


contentType xsd:string as defined in

[XMLMIME].

This is the code

describing what type

of picture is stored.

The discrete-type image and

an IANA registered ietef-

token as defined in [RFC2045]

and [IANA] are acceptable.

Implementations MUST

support at least the following types:

• image/gif

• image/jpeg

• image/tiff

• image/png Implementations MAY

support other types too.

/ image/jpeg

Yes

- 64 -


PictureUsage fe:PictureUsageType /

enumeration

This is the usage

type of a photo

(picture).

passport (A passport picture)

official (The picture to use for

official purposes (such as

public descriptions of the

person/organization).) thumbnail (A generic preview

(small) picture.)

signature(A picture of the

Signature of the person)

other (if none of the others

matches)

Yes

ValidFrom fe: Date If the picture is only

valid for a fixed period this date

specifies the earliest

valid date.

see general data types. No

ValidTo fe: Date If the picture is only

valid for a fixed

period this date

specifies the latest valid date.

see general data types. No

The element content is the base64-encoded picture. Up to 5*10^6 characters are accepted. 916

Example: 917 <fe:Photo xmime:contentType="image/jpeg" PictureUsage=”passport” ValidTo="2015-11-21Z"> 918 YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYW919 FhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ== 920 </fe:Photo> 921

922

- 65 -

9.19. Sanction 923

ComplexType name: SanctionType 924


926

This type contains detailed information about a sanction. 927

928 Pic. 15. SanctionType 929


SanctionType fe:InternationalString50 Short description of the sanction.

Yes

SanctionDate fe:Date Date when the

sanction was

imposed.

Yes

ValidFrom fe: Date First day when the

sanction is in effect.

No

ValidTo fe: Date Last day when the

sanction is in effect.

No


[Multiplicity]


Description fe:InternationalLongString

[0..1]

Detailed description

of the sanction

No

932

Example: 933 <fe:Sanction SanctionDate="2010-01-01Z" SanctionType="Penalty for aggressive transfer contracting: 5000$" > 934 <fe:Description>Transfered Player before he was 18 years old.</fe:Description> 935 </fe:Sanction> 936

- 66 -

9.20. Season 937

ComplexType name: SeasonType 938


940

This type contains information about a season. 941

942 Pic. 16. SeasonType 943


StartDate fe: Date The first day of the

season.

Yes

EndDate fe: Date The last day of the

season.

Yes

Name fe:InternationalString50 The name of the

season.

No

RegistrationStart

Date

fe: Date The first day when

players and teams

can be registered for

the season.

No

RegistrationEndD

ate

fe: Date The last day when players and teams can be registered for the season.

No


[Multiplicity]


Description fe:InternationalLongString [0..1]

Detailed description of the season

No

- 67 -

946

Example: 947 <fe:Season Name="FIFA Cup" StartDate="2011-04-04Z" EndDate="2011-11-21Z" RegistrationStartDate="2010-12-948 01Z" RegistrationEndDate="2011-04-01Z"> 949 <fe:Description>The FIFA main Season.</fe:Description> 950 </fe:Season> 951

9.21. Custom extension 952

ComplexType name: CustomExtensionType 953


955

This represents a custom extension. A custom extension is one or more key/value pairs. Where a key is a 956

custom attribute and a value is its value. 957

Implementations MUST NOT duplicate any attributes or elements defined in this specification. 958

Implementations MAY add any none standardized key value pairs. 959

Implementations MAY ignore the content of custom extensions completely. 960

961

962 Pic. 17. CustomExtensionType 963


Key fe:InternationalString50 The English

(international)

attribute name of

the custom

extension.

/ diet Yes


[Multiplicity]


Value fe:InternationalLongString [1]

The English (international) value

of the custom

attribute.

/ vegetarian Yes

NativeValue fe:LongLocalizedString

[0..100]

Localized values of

the custom attribute.

See LongLocalizedString. No

965

- 68 -

Example: 966 <fe:CustomExtension Key="diet"> 967 <fe:Value>vegetarian</fe:Value> 968 <fe:NativeValue Language="ger"> 969 <fe:Value>vegetarisch</fe:Value> 970 </fe:NativeValue> 971 <fe:NativeValue Language="gsw"> 972 <fe:Value>vegi</fe:Value> 973 </fe:NativeValue> 974 </fe:CustomExtension> 975

9.22. Geographic Coordinate 976

ComplexType name: GeographicCoordinateType 977


979

This represents a coordinate in a geographic coordinate system. A geographic coordinate system is a 980

coordinate system that enables every location on the Earth to be specified by a set of numbers. 981

982

983 Pic. 18. GeographicCoordinateType 984

985

- 69 -


Latitude xsd:double / -90.0 … +90.0 The latitude of a

location on the Earth

is the angular

distance of that location south or

north of the Equator.

The equator has a

latitude of 0°, the

North pole has a

latitude of 90°

(written 90 or +90),

and the South pole has a latitude of -90°

(written −90). The

latitude is in decimal

degrees.

/ -42.6578 Yes

Longitude xsd:double

/ -180.0 … +180.0

The longitude of a

location on the Earth

is the angular distance of that

location east or west

of the prime

meridian. The prime

meridian has a

longitude of 0°. The

longitude of other

places is measured as an angle east

(ranging from 0 to

180) or west (ranging

from -0 to -180) from

the Prime Meridian.

The longitude is in

decimal degrees.

/ +122.4387545 Yes

987

988

- 70 -

9.23. Person management 989

The types in this section MUST be supported if any of the building blocks Player Management [PDXS], 990

Referee Management [RDXS] or Coach Management [CODXS] is supported. If none of these building 991

blocks is supported, the types in this section are optional. 992

9.23.1. Simple data types 993

This section contains the documentation of general data types of type SimpleType. 994 Type Type / Format Documentation Possible Values / Example Mand.

OfficialLicenceTy

pe

fe:String50 The type of licence a

person holds. This is

free text. Insert here

the name of the

licence the person

holds.

/ A-Licence Yes

RoleStatusType xsd:string / enumeration The status of a role a

person can have.

Roles are referee-,

coach-, player

registration.

Typically this is

active.

active (the role is valid)

banned (The role is no longer

valid. the person was banned

from taking the role. Banned

persons are not allowed to

execute the role any more for

the organization within the validity period.)

suspended (he role is no

longer valid. the person was

suspended from taking the

role. suspended persons are

not allowed to execute the

role at the moment.)

inactive (The role is no longer active.)

pending (There is a pending

legal case running against the

person in this role.)

resigned (The role is

resigned.)

retired (The person has retired from this role)

Yes

995

996

- 71 -

9.23.2. Licence 997

ComplexType name: LicenceType 998


1000

This represents a licence of a person. 1001

1002

1003 Pic. 19. LicenceType 1004


OfficialLicence fe:OfficialLicenceType The type of licence

the person holds.

This is free text. Insert here the name

of the licence the

person holds.

See simple data types. Yes

LicenceNumber fe:String50 The licence number. No

PlaceOfIssue fe:String50 The place where the

licence was issued.

No

DateOfIssue fe:Date The date when the

licence was issued.

No

Example: 1005 <fe:Licence OfficialLicence="A-Licence" DateOfIssue="2009-10-12Z" PlaceOfIssue="Zurich" 1006 LicenceNumber="23454657u68"/> 1007 1008

1009

1010

- 72 -

10. Abbreviations 1011

Abbreviation Description

FIFA Fédération Internationale de Football Association.

HTTP(S) Hypertext Transfer Protocol (using SSL/TLS)

IANA Internet Assigned Numbers Authority.

IETF Internet Engineering Task Force.

ISO International Organization for Standardization.

Mand. Mandatory. In the context of this document used as header in tables. The element or attribute

MUST be provided in the XML document if the value is “Yes”.

MIME Multipurpose Internet Mail Extensions.

REST Representational State Transfer.

RFC Request for Comments by the IETF.

SSL/TLS Secure Sockets Layer / Transport Layer Security.

SOAP Simple Object Access Protocol.

UCS Universal Character Set.

UTF-8 8-bit UCS/Unicode Transformation Format.

WSS Web Service Security

XML Extensible Markup Language.

1012

1013

- 73 -

11. XML Schema 1014

The XML types and elements used in this specification are defined in the following XML Schema 1015

documents: 1016

• generic-types-2.0.xsd – General data types. 1017

• person-2.0.xsd – Person and Person related types. 1018

• organization-2.0.xsd – Organization and organization related types. 1019

• team-2.0.xsd – Team and team related types. 1020

• mandatory-2.0.xsd – MandatoryData and related types. 1021

• football-data-2.0.xsd – The Message Header. 1022

• fifa-nationality.xsd – The three letter FIFA nationality codes. 1023

• iso639-2-language-code.xsd – The ISO 639-2 three letter language codes. 1024

• iso3166-country-code.xsd – The ISO 3166-1:2006 alpha-2 two letter country codes. 1025

• iso4217-currency-code.xsd – The ISO 4217:2008 two letter currency codes 1026

All these XML Schema documents are part of the standard and can be obtained from [DSSchema]. 1027

1028

- 74 -

12. References 1029

Reference Description

[CODXS] MA Standards Software - Data Exchange Standard - Coach V2.doc. The FIFA Coach Management

data exchange Standard.

[DSSchema] The data exchange standard schema definition files. They can be obtained from the FIFA MA

Software Standard Team that is a part of the FIFA MA professionalization programme or from the FIFA extranet: https://extranet.fifa.com/MA-

Software/FIFA/Templates/DocLibrary/Pages/UserLoginFromEmail.aspx?id=28015&epslanguage=en

&vpath=/ma-software/Files/Publications/all_xsd.zip.

[EBNF] ISO 14977:1996, Information technology -- Syntactic metalanguage -- Extended BNF

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26153

http://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form (non normative)

[HTTP] RFC 2616 – HTTP: http://tools.ietf.org/html/rfc2616.

RFC 2617 - Basic and Digest authentication: http://tools.ietf.org/html/rfc2617 RFC 4559 – Kerberos and SPNEGO: http://tools.ietf.org/html/rfc4559

[IANA] IANA, Image Media Types.

http://www.iana.org/assignments/media-types/image/

[IDGEN] The FIFA defined service that generates worldwide unique identifiers and defines the detailed

requirements on how to integrate/implement the worldwide unique identifier generation

mechanism.

The document can be obtained from the FIFA MA Software Standard Team that is a part of the FIFA

MA professionalization programme.

[IDPERS] The definition of the format and generation requirements for the alternative person id. The document can be obtained from the FIFA MA Software Standard Team that is a part of the FIFA

MA professionalization programme.

[ISO3166] ISO 3166-1:2006, Codes for the representation of names of countries and their subdivisions -- Part 1:

Country codes.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39719

http://www.iso.org/iso/english_country_names_and_code_elements (non normative)

[ISO4217] ISO 4217:2008, Codes for the representation of currencies and funds

http://www.iso.org/iso/catalogue_detail.htm?csnumber=46121 http://en.wikipedia.org/wiki/ISO_4217

[ISO639] ISO 639-2:1998, Codes for the representation of names of languages -- Part 2: Alpha-3 code.

http://www.iso.org/iso/catalogue_detail?csnumber=4767,

http://www.loc.gov/standards/iso639-2/php/code_list.php (non normative)

[PDXS] MA Standards Software - Data Exchange Standard - Player V2.doc. The FIFA Player Management


[RDXS] MA Standards Software - Data Exchange Standard - Referee V2.doc. The FIFA Referee Management


[RFC2119] RFC 2119, S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, IETF RFC 2119,

March 1997. http://www.ietf.org/rfc/rfc2119.txt

[RFC4045] RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message

Bodies, N. Freed, N. Borenstein, November 1996.

http://www.ietf.org/rfc/rfc2045.txt

[RFC4122] RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace, July 2005.

http://www.ietf.org/rfc/rfc4122.txt

- 75 -

Reference Description

[TLS] RFC5246 The Transport Layer Security (TLS) Protocol, August 2008.

http://tools.ietf.org/html/rfc5246

[XMLMIME] W3C, Describing Media Content of Binary Data in XML.

http://www.w3.org/TR/xml-media-types (Draft)

http://www.w3.org/2005/05/xmlmime (XML Schema)

[WSS] OASIS, Web Services Security. http://www.oasis-open.org/committees/wss/ (contains links to all Token Profiles)

[XMLENC] W3C Working Draft, "XML Encryption Syntax and Processing," 04 March

2002.

[XMLSIG] D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. XML-

Signature Syntax and Processing, W3C Recommendation, 12 February

2002.

[XPATH] W3C, XML Path Language (XPath) 2.0 (Second Edition).

http://www.w3.org/TR/xpath20/

1030

1031

- 76 -

13. Copyright 1032

The FIFA Data Exchange Standard document (“Document”) including all images and text therein (the 1033

"Content") is exclusively owned by FIFA. 1034

1035

FIFA asks any interested user to sign an Authorisation Letter in order to be authorised to implement the 1036

Content (“Permitted Users”). In the implementation Permitted Users are allowed to modify, amend, 1037

extend, enhance and/or adjust the Contents provided that the respective Permitted User submits to FIFA 1038

any suggested change it has made to the Contents. For the avoidance of doubt, Permitted Users are not 1039

allowed to copy, modify, change, distribute and/or display the Document itself in any way. 1040

1041 For more information, consult your copyright attorney. 1042

1043

Non-permitted users who are interested to receive the Document and/or implement or use the Content 1044

should contact FIFA directly. 1045

FIFA takes no position regarding the validity or scope of any intellectual property or other rights that might 1046

be claimed to the implementation or use of the Document described in the Content or to the extent to 1047

which any licence under such rights might not be available; neither does it represent that it has made any 1048

effort to identify such rights. 1049

1050

FIFA invites any interested parties to bring to its attention any copyright works, patents or patent 1051

applications, or other proprietary rights which may cover technology that may be required to practice or 1052

implement the FIFA Data Exchange Standard. 1053

1054

© 2011 FIFA. All Rights Reserved. 1055

1056

Documents

MA Standards Software - Data Exchange Standard - Core V2