Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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 -
Version Reason for change Created by Date
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 -
Version Reason for change Created by Date
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 -
Version Reason for change Created by Date
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 <!-- Marks the Sallary of a new player registration of a transfer as mandatory --> 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
Type MUST be supported: No 389
390
Defines a mandatory element or attribute using XPath. 391
392 Pic. 2. MandatoryPartType 393
394 Attribute Type / Format Documentation Possible Values /
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
395 Element Type / Format
[Multiplicity]
Documentation Possible Values /
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 -
470 Attribute Type / Format Documentation Possible Values /
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
471 Element Type / Format
[Multiplicity]
Documentation Possible Values /
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 <!-- custom extension types --> 500 </fe:FootballData> 501 502
503
- 23 -
7. Contact Management messages 504
7.1. Person 505
ComplexType name: PersonType 506
Type MUST be supported: Yes 507
508
This represents a generic person that should be used for all international use cases. 509
510 Pic. 4. PersonType 511
512 Element Type / Format
[Multiplicity]
Documentation Possible Values /
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
Type MUST be supported: Yes 553
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
559 Element Type / Format
[Multiplicity]
Documentation Possible Values /
Example
Mand.
PersonName TraditionalPerson
NameType
[1]
The English (international) name
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
Type MUST be supported: No 574
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
581 Element Type / Format
[Multiplicity]
Documentation Possible Values /
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
Type MUST be supported: Yes 587
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
598 Attribute Type / Format Documentation Possible Values /
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
The English (international) name
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 -
Attribute Type / Format Documentation Possible Values /
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 -
Attribute Type / Format Documentation Possible Values /
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.
See general data types. No
599 Element Type / Format
[Multiplicity]
Documentation Possible Values /
Example
Mand.
Address fe:AddressType
[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.
See general data types. No
Phone fe:PhoneType
[0..20]
The phone number(s) of the
organization.
See general data types. No
- 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.
See general data types. No
Discipline fe:DisciplineType
[0..20]
The FIFA disciplines / sports the
organization supports.
See general data types. No
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.
See general data types. No
NativeAlias fe:LocalizedString
[0..100]
This is the localized alias of the
organization.
See general data types. No
NativeShortName fe:LocalizedString
[0..100]
This is the localized short name of
the organization.
See general data types. No
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
CustomExtension fe:CustomExtensio
nType
[0..100]
Custom extensions for the
organization. Note that you may
not duplicate any existing
attributes or elements using
custom extensions.
See general data types. No
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
Type MUST be supported: Yes 635
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
Type MUST be supported: No 646
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 -
Attribute Type / Format Documentation Possible Values /
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.
See general data types. Yes
Name fe:InternationalStri
ng50
The English (international) name
of the team.
/ Manchester United Yes
TeamType fe:TeamNatureTyp
e / enumeration
The nature / kind of team this is
(FIFA type).
See general data types. Yes
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.
See general data types. No
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.
See general data types. No
ReplacedBy fe:identifier The TeamId of the Team that
replaces this team.
No
656 Element Type / Format
[Multiplicity]
Documentation Possible Values /
Example
Mand.
Discipline fe:DisciplineType
[1..10]
The FIFA disciplines / sports the
team plays.
See general data types. Yes
TeamColour fe:TeamColourTyp
e
[0..20]
The possible colours of the Team. See general data types. No
Address fe:AddressType
[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.
See general data types. No
- 38 -
Element Type / Format
[Multiplicity]
Documentation Possible Values /
Example
Mand.
CustomExtension fe:CustomExtensio
nType
[0..100]
Custom extensions for the team.
Note that you may not duplicate
any existing attributes or
elements using custom extensions.
See general data types. No
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.
- 41 -
Type Type / Format Documentation Possible Values / Example Mand.
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 -
Type Type / Format Documentation Possible Values / Example Mand.
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 -
Type Type / Format Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 683
684
This is the English (international) name of a Person. 685
686 Pic. 11. PersonNameType 687
688 Element Type / Format
[Multiplicity]
Documentation Possible Values /
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
Type MUST be supported: Yes 706
707
This is the English (international) name of a Person. 708
709 Pic. 12. TraditionalPersonNameType 710
711 Element Type / Format
[Multiplicity]
Documentation Possible Values /
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
Type MUST be supported: Yes 726
727
This is the English (international) name of a Person. 728
729 Pic. 13. BasePersonNameType 730
731
- 47 -
Element Type / Format
[Multiplicity]
Documentation Possible Values /
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.
/ see CompositeNameType
No
ShortName fe:CompositeNameType Short writing form for
extremely long names (e.g.
Sri Lankan names).
/ see CompositeNameType
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).
/ see CompositeNameType
No
732
For examples, see PersonName and TraditionalPersonName. 733
734
- 48 -
9.5. NativePersonName 735
ComplexType name: NativePersonNameType 736
Type MUST be supported: Yes 737
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
743 Element Type / Format
[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).
/ see NativelCompositeNameType
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).
/ see NativelCompositeNameType
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
Type MUST be supported: Yes 753
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
758 Attribute Type / Format Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 767
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
774 Attribute Type / Format Documentation Possible Values / Example Mand.
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.
/ Arantes do Nascimento Yes
Example: 775 <fe:Name firstname="Diego Armando" Lastname="Maradona" /> 776
777
- 52 -
9.8. NativeCompositeName 778
ComplexType name: NativeCompositeNameType 779
Type MUST be supported: Yes 780
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
786 Attribute Type / Format Documentation Possible Values / Example Mand.
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.
/ Arantes do Nascimento Yes
Example: 787 <fe:Name Lastname="="ـــا�ك 788 </ " ب 789
790
- 53 -
9.9. Passport 791
ComplexType name: PassportType 792
Type MUST be supported: Yes 793
794
This type contains information about the Passport of a Person. 795
796 Pic. 5. Passport 797
798 Attribute Type / Format Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 804
805
This type contains information about an Achievement of a Person. 806
807 Pic. 6. Achievement 808
809 Attribute Type / Format Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 815
816
This type contains information about the colours of a team. 817
818 Pic. 7. TeamColour 819
820 Attribute Type / Format Documentation Possible Values / Example Mand.
PrimaryShirtColo
ur
fe:InternationalString50 The first colour of
the shirts. Yes
PrimaryShortColo
ur
fe:InternationalString50 The first colour of
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 -
Attribute Type / Format Documentation Possible Values / Example Mand.
PrimarySockColo
ur
fe:InternationalString50 The first colour of
the socks. No
SecondaryShirtCo
lour
fe:InternationalString50 The second colour of
the shirts. No
SecondaryShortC
olour
fe:InternationalString50 The second colour of
the shorts. No
SecondarySockCo
lour
fe:InternationalString50 The second colour of
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
Type MUST be supported: Yes 826
827
This type relates a string to a language. The string represents text in the related language. 828
829 Pic. 8. LocalizedString 830
831 Attribute Type / Format Documentation Possible Values / Example Mand.
Language ISO639-2Type The language of the
localized string.
One of the ISO language
codes defined in the schema
iso639-2-language-code.xsd. /
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
Type MUST be supported: Yes 837
838
This type relates a string to a language. The string represents text in the related language. 839
840 Pic. 9. LocalizedString 841
842 Attribute Type / Format Documentation Possible Values / Example Mand.
Language ISO639-2Type The language of the
localized string.
One of the ISO language
codes defined in the schema
iso639-2-language-code.xsd. /
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
Type MUST be supported: Yes 848
849
This type relates a string to a language. The string represents text in the related language. 850
851 Pic. 10. LongLocalizedString 852
853 Attribute Type / Format Documentation Possible Values / Example Mand.
Language ISO639-2Type The language of the
localized string.
One of the ISO language
codes defined in the schema iso639-2-language-code.xsd. /
ara
Yes
854 Element Type / Format
[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
Type MUST be supported: Yes 863
864
This represents a traditional (mail) address. 865
866
867 Pic. 11. AddressType 868
Attribute Type / Format Documentation Possible Values / Example Mand.
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
AddressLine2 fe:String50 This is the generic
line 2 of an address.
Often this is an
apartment, building,
floor etc.
/ Building Alpha, Floor 2 No
AddressLine3 fe:String50 This is the generic
line 3 of an address.
No
Region fe:String50 This is the state, province or region.
/ Zurich No
869 Element Type / Format
[Multiplicity]
Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 880
881
This represents an Email address. 882
883
884 Pic. 12. EmailType 885
Attribute Type / Format Documentation Possible Values / Example Mand.
Email EmailAddressType The email / [email protected] Yes
886 Element Type / Format
[Multiplicity]
Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 895
896
This represents a phone number. 897
898
899 Pic. 13. PhoneType 900
Attribute Type / Format Documentation Possible Values / Example Mand.
Phone fe:String50 The phone number. / +41 44 / 444 44 44 Yes
901 Element Type / Format
[Multiplicity]
Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 910
911
This represents a picture. 912
913
914 Pic. 14. PictureType 915
Attribute Type / Format Documentation Possible Values / Example Mand.
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 -
Attribute Type / Format Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 925
926
This type contains detailed information about a sanction. 927
928 Pic. 15. SanctionType 929
930 Attribute Type / Format Documentation Possible Values / Example Mand.
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
931 Element Type / Format
[Multiplicity]
Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 939
940
This type contains information about a season. 941
942 Pic. 16. SeasonType 943
944 Attribute Type / Format Documentation Possible Values / Example Mand.
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
945 Element Type / Format
[Multiplicity]
Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 954
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
Attribute Type / Format Documentation Possible Values / Example Mand.
Key fe:InternationalString50 The English
(international)
attribute name of
the custom
extension.
/ diet Yes
964 Element Type / Format
[Multiplicity]
Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 978
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 -
986 Attribute Type / Format Documentation Possible Values / Example Mand.
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
Type MUST be supported: Yes 999
1000
This represents a licence of a person. 1001
1002
1003 Pic. 19. LicenceType 1004
Attribute Type / Format Documentation Possible Values / Example Mand.
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
data exchange Standard.
[RDXS] MA Standards Software - Data Exchange Standard - Referee V2.doc. The FIFA Referee Management
data exchange Standard.
[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