Introduction

• LEI to LEI relationships.
• LEI to (GLEIS-internal) Provisional Node Identifier (PNI) for reporting parent entities which do not yet have an LEI.

Status of this document

This section describes the status of this document at the time of its publication. Later versions may supersede this document. The most up to date version will always be available from www.gleif.org.

The file format references and honors the policy document published by the LEI ROC entitled "Collecting data on direct and ultimate parents of legal entities in the Global LEI System – Phase 1” (10 March 2016; available from www.leiroc.org).


Terminology and Typographical Conventions

The following typographical conventions are used throughout the document:
• ALL CAPS type is used for the special terms enumerated above.
• Monospace type is used to denote programming language, UML, and XML identifiers, as well as for the text of XML documents.

Cardinalities

• The cardinality of each element (the number of times it MUST or MAY appear in an XML data file conforming to this schema) is expressed as a number range in the format {minimum occurrences, maximum occurrences} in the XML examples shown below the notes of its containing element. This notation is equivalent to the following explanations in words:
• Mandatory, unique: {1,1} - the element MUST appear, exactly once.
• Mandatory, repeatable: {1,unbounded} - the element MUST appear at least once. It may be repeated any number of times.
• Optional, unique: {0,1} - the element NEED NOT appear; it MAY appear once at most.
• Optional, repeatable: {0,unbounded} - the element NEED NOT appear. It MAY be repeated any number of times.
Please note:
• The default cardinality is {1,1} (mandatory, unique). This document highlights when an element differs from this either by its minOccurs (minimum occurrences) or maxOccurs (maximum occurrences) value, or both.
• XML cardinalities apply in the context of any containing elements. This means that a contained element may have a cardinality of one or more even if its containing element may be omitted, because the contained element is mandatory given the presence of the container.
• XML cardinalities enforce a minimum data quality and standards conformance. Other business rules (as explained below) and data quality checks applied by GLEIF may encourage stricter cardinalities in live implementations.

Business Rules

The accompanying documentation in addition to this Technical Specification specifies business rules where applicable for each element. These are rules that are not enforced by validating against the XML schema, but are still mandatory for all Common Data File (CDF) format files.



XML Syntax

This section specifies the XML schema for an Relationship Data File conforming to this standard.



XML Design Rules

• The XSD schema conforms to W3C's XML Schema specification, version 1.0.
• The XML namespace is "http://www.gleif.org/data/schema/rr/2016".
• All interior XML elements are namespace-qualified (element form = qualified).
• All XML attributes are in the null namespace (attribute form = unqualified), with the exception of xml:lang.
• Element names are upper camel case.
• Attribute name are lower camel case.
• XSD type names are upper camel case.
• Enumeration code list values are all caps with underscores.
• Elements are used in preference to attributes except for language and type qualifiers.
• For a data element specified as having unbounded cardinality, the XML includes a single container element whose subelements are one or more instances of the data element whose cardinality is unbounded. The name of the container element is formed as the plural of the name of the contained elements.

XML Schema

An XML file conforming to this standard is valid according to the following XSD 1.0 schema.

Release Notes

Version 1.1

• Corrections:
  • Corrected elementFormDefault="unqualified" to elementFormDefault="qualified".

Version 1.0

Change Management

Minor Version

Major Version

Minor Version Changes to the XML Schema

• The initial XSD declaration for a NextVersion element SHALL use the element name "NextVersion", XML data type "lei:NextVersion1Type" and cardinality optional, unique {0,1}. The XML data type allows a sequence of any elements, each of cardinality optional, repeatable (unbounded) and with lax content processing, but in the target namespace.
• The minOccurs declaration on the NextVersion element allows it to be omitted in files conforming to the first minor version. The schema wildcard xsd:any allows for forward compatibility: a file conforming to a new minor version still validates in the old version because the wildcard matches any new elements introduced in the new minor version.
• New elements SHALL be introduced in a subsequent minor version by modifying the declaration for the above type declaration as follows:
  • A sequence of the new elements introduced in the previous version.
  • A subsequent NextVersionN element where N is an index number starting at 1 and incremented by 1 with each minor version.
• Each new element SHALL be declared minOccurs=”0”, to ensure backward compatibility: a file conforming to the old version still validates in the new version because the new schema does not require the presence of elements not defined in the old version. If a new element is mandatory for conformance to the new version, this MUST be enforced outside schema validation.
• The new definition of the NextVersion element SHALL include a declaration of an inner NextVersion element, as illustrated above, to provide for additional elements in subsequent minor versions. The nesting of NextVersion elements is required to satisfy the “unique particle attribution” constraint of XSD 1.0.
• Each code list (Enum types) is implemented in the XML schema simply as the XSD string data type. This provides for forward compatibility because the schema for an older minor version will validate any string, including codes defined in newer minor versions. The schema for each minor version includes the list of valid codes for that minor version as a documentation annotation to the type declaration for each Enum type.

Major Version Changes to the XML Schema

Abstract Data Content

• A Header.
• Zero or more Relationship Records.

Relationship Data File Header

Relationship Record

Relationship

Related Entities

Relationship Attributes

Registration

Extension

• Each XML element included in the content of the Extension element SHALL be in an XML namespace that is not null and not equal to the XML namespace of the Relationship Data File as specified in this standard.
• The XML namespace for an Extension element SHALL be a namespace which the creator of the extension element exclusively or jointly controls, or from which the creator re-uses existing elements and their definitions, e.g. a namespace derived from the Internet Domain Name of the creator, a namespace agreed upon by a group of trading partners, etc.
• An Extension element SHALL NOT be defined in such a way as to require the recipient of the file to recognize the Extension element in order to interpret the data elements specified in this standard. A recipient of the file MUST be able to ignore all Extension elements and still interpret the standard content correctly.
• A recipient of a data file conforming to this standard SHALL NOT reject a file solely because it contains extensions not understood by the recipient. A recipient MUST be prepared to accept a file containing extensions and ignore any it does not understand, provided that the file complies to this standard.