RR-CDF Version 2.1
Documentation last updated: 2021-03-04
Introduction
This XML schema defines a
reporting format for relationship records for Global Legal Entity Identifier System
(GLEIS) Local Operating Units (LOUs) to report relationships between two legal entities
(one relationship per relationship record).
Types of relationship supported:
- 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
Within this document, the terms, as will be SHALL and MAY, are to be interpreted as specified in Annex G of the ISO/IEC Directives, Part 2, 2001, 4th edition:
- SHALL (NOT): Requirement
- MAY: Permission / Possibility
When used in this way, these terms will always be shown in ALL CAPS; when these words appear in ordinary typeface, they are intended to have their ordinary English meaning.
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 SHALL 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 SHALL appear, exactly
once.
- Mandatory, repeatable:
{1,unbounded} - the element SHALL
appear at least once. It may be repeated any number of times.
- Optional, unique:
{0,1} - the element MAY be omitted; it
MAY appear once at most.
- Optional, repeatable:
{0,unbounded} - the element MAY be omitted. 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 2.1
- New or changed enumerated values:
-
QualifierCategoryTypeEnum
- Added
GOVERNMENT_ACCOUNTING_STANDARD.
Version 2.0
- New or changed enumerated values:
-
RelationshipType
- Added
IS_FUND-MANAGED_BY.
- Added
IS_SUBFUND_OF.
- Added
IS_FEEDER_TO.
-
RelationshipStatus
- Documentation notes:
- Several definitions of elements, attributes or enumerations have been updated and aligned with the State Transition and Validation Rules.
Version 1.1
- Corrections:
- Corrected
elementFormDefault="unqualified" to
elementFormDefault="qualified".
Version 1.0
The first release.
Abstract Data Content
This section specifies the abstract data content of a
data file conforming to this standard. A data file conforming to this standard SHALL
consist of:
- A Header.
- Zero or more Relationship Records.
Relationship Data File Header
The Relationship Data File Header describes the
context for the Relationship Records contained in the main body of the file. The header
exists to answer such questions as where the data came from, when it was collected into
this file, etc. The content of the header SHALL NOT be required to interpret the data
content of any Relationship Record; each Relationship Record is self-contained.
Relationship Record
An Relationship Record describes a single LEI
registration. Each Relationship Record in a file conforming to this standard SHALL
include data elements as described below: Relationship
The Relationship
container element identifies the two related entities and their relationship.
Related Entities
The ISO 17442-compliant identifiers of the legal entities
related by this Relationship Record. Relationship Attributes
Attributes
describing the dates, type, qualitative and quantitative aspects of the relationship
itself, as required. The data is supplied by the legal entity, and recorded and
published by the LOU. Registration
Attributes describing the registration of
this relationship information with an LOU. The Registration data is
maintained by the LOU. Extension
The optional Extension section of
a Relationship Record may be used to include additional data not defined in this
standard. This may include data specific to an LOU, data specific to a publisher of LEI
data, and so on.
For example, an LOU may use Extension to publish
additional data elements it collects as part of registration.
The following rules
SHALL be observed:
- 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 SHALL 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 SHALL be prepared to accept a file containing extensions and ignore any
it does not understand, provided that the file complies to this standard.