xsd.rr-cdf-v1-1.xsd Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of lei Show documentation
Show all versions of lei Show documentation
JAXB Bindings for LEI schemas
Introduction
Documentation updated: 2017-03-16
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
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
The first release.
Change Management
Changes to this standard that affect the data schema SHALL be
made by approval and publication of a new version of this document. A new version SHALL
be one of the following:
Errata Version An errata version makes corrections to the normative content
of the standard (excluding corrections which would change the data schema) and/or makes
changes to non-normative content such as explanatory material. An errata version does
not change the XML schema definitions, only the documentation parts, and so does not
affect the interoperability of systems implementing the standard. An errata version is
indicated by incrementing the third version number; e.g., 1.0 to 1.0.1, or 1.0.1 to 1.0.2.
Minor Version
A minor version may include all changes permitted in an errata
version, and in addition adds one or more data elements and/or adds one or more codes to
a code list (“enum” data type). A minor version changes the XML schema. Minor version
changes to schema MUST provide for forward and backward compatibility. This allows
existing implementations to continue to interoperate even if they are using different
minor versions. A minor version is indicated by incrementing the second version number;
e.g., 1.0 to 1.1 or 1.1.3 to 1.2.
Major Version
A major version may make any change at all, including
incompatible changes to the XML schema. Major version changes to schema require that the
new version uses a different XML namespace. This requires existing implementations to
separately understand both the old and new versions during a period of transition. A
major version is indicated by incrementing the first version number; e.g., 1.1 to
2.0.
The release of a new minor or major version shall always be accompanied
by a transition plan for LOUs and GLEIF, to ensure a smooth and time-bounded migration
to the new version.
Minor Version Changes to the XML Schema
A minor version may introduce new XML
elements and/or adds one or more codes to a code list (“enum” data type). Minor version
changes to schema SHALL be made as specified below, in order to achieve forward and
backward compatibility.
Forward compatibility means that an Relationship
Data File which is valid according to the older version’s schema is also valid according
to the newer version’s schema.
Backward compatibility means that an
Relationship Data File which is valid according to the newer version’s schema is also
valid according to the older version’s schema.
New data elements may be
added at pre-defined extension points within the schema, each with an optional XML
element NextVersion. New data elements are always added within a NextVersion element.
When a minor version adds a new data element to a NextVersion element, a
new NextVersion element is also added inside the previously added
NextVersion element, to accommodate additional data elements in
subsequent minor versions. Each successive NextVersion element set is contained directly
within the previous minor version's NextVersion set.
As can be seen from the
full XML schema presented here, the following rules SHALL be observed to ensure forward
and backward compatibility:
- 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
A major version may make any change to
the XML schema whatsoever, including incompatible changes.
A schema
introduced in a new major version SHALL use an XML namespace URI that is different from
the XML namespace URI defined in any other major version of this standard. The namespace
URI for a new major version SHOULD be the same as the namespace URI specified in this
standard, with the year at the end changed to the year in which the new major version is
introduced. If more than one major version is introduced in the same year, a letter “a”,
“b”, “c”, etc., may be appended to the year as needed.
A new major version
MUST be accompanied by an implementation plan which explains how implementations will
make the transition from the old major version to the new major version. Generally
speaking, such a plan typically provides for a period of transition in which an
implementation capable of receiving the new major version is required to also receive
the old major version.
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
MUST 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 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.
Contains the file structure for the whole relationship records file as
specified in the XML datatypes below.
Contains the file upload information for this RelationshipData
file.
Container for all of the RelationshipRecord
container elements submitted with this file.
The date and time as of which the data contained in the file
is valid.
The LEI of the entity that created the content of this file.
A code describing the content of this relationship record
file.
The date and time of the baseline relative to which this file
contains new or changed Relationship Records.
The number of relationship records in the file.
A structure for adding further elements in to the LEI data
file header in anticipation of a new version, by nesting a series of XML
elements with this content model within the NextVersion
element, one for each new minor version of the schema, postpending a serial
number (1,2,3...) to the element name upon each
iteration.
This Extension element may contain any additional
elements required to extend the Header container element.
An element of this type has minimum length of one character and may
not contain any of: the carriage return (#xD), line feed (#xA) nor tab (#x9)
characters, shall not begin or end with a space (#x20) character, or a sequence of
two or more adjacent space characters.
The file contains all relationship records created for
internal use by an LOU (all internal relationship records for which the LOU
is the ManagingLOU) as of the date/time the file is
created.
The file contains those relationship records created by an LOU
for internal use (all internal relationship records for which the LOU is the
ManagingLOU) which are new or changed since the
DeltaStart specified in the Header, as of the
date/time the file is created.
The file contains all relationship records published by an LOU
(all relationship records for which the LOU is the ManagingLOU)
as of the date/time the file is created.
The file contains those relationship records published by an
LOU (all relationship records for which the LOU is the
ManagingLOU) which are new or changed since the
DeltaStart specified in the Header, as of the
date/time the file is created
The file contains all relationship records GLEIF manages
internally to the GLEIS (including all internal relationship records from
all LOUs) as of the date/time the file is created.
The file contains those relationship records GLEIF manages
internally to the GLEIS (including all internal relationship records from
all LOUs) which are new or changed since the DeltaStart date
specified in the Header, as of the date/time the file is
created.
The file contains all relationship records published by GLEIF
(including all relationship records from all LOUs) as of the date/time the
file is created.
The file contains those relationship records published by
GLEIF (including all relationship records from all LOUs) which are new or
changed since the DeltaStart date specified in the
Header, as of the date/time the file is
created.
The file contains records matching criteria specified in a
query.
Contains all relationship information including identifiers
referring to the related entities, the specific type and other attributes of
the relationship itself, and details of the relationship's registration with
the ManagingLOU.
The Relationship container element contains the
identifiers of the two entities related by the reported relationship, as
well as the type of relationship, dates related to the relationship and
other relationship quantifiers and qualifiers.
The Registration container element contains
information specifying the LOU's administration of the relationship report.
A structure for adding further elements in to the
Registration section of the Relationship Record in
anticipation of a new version, by nesting a series of XML elements with this
content model within the NextVersion element, one for each new
minor version of the schema, postpending a serial number (1,2,3...) to the
element name upon each iteration.
This Extension element may contain any additional
elements required to extend the RelationshipRecord.
An LEI or ISO 17442-compatible ID for the entity at the
"start" of a directional relationship.
An LEI or ISO 17442-compatible ID for the entity at the "end"
of a directional relationship.
A unique code designating the specific category of a
directional relationship between two legal entities.
A collection of paired beginning and end dates relating to:
the relationship itself, periods (e.g. accounting cycles) covered by
documents demonstrating the relationship, or the filing date(s) of those
documents.
The status of the legal entities' relationship itself:
ACTIVE or INACTIVE.
Any additional qualitative attributes that help to categorize
the relationship.
Any additional quantitative attributes that help to categorize
the relationship.
A structure for adding further elements in to the
Registration section of the Relationship Record in
anticipation of a new version, by nesting a series of XML elements with this
content model within the NextVersion element, one for each new
minor version of the schema, postpending a serial number (1,2,3...) to the
element name upon each iteration.
This Extension element may contain any additional
elements required to extend the Relationship container element.
The identifier for the entity designated by this node.
The type of identifier used to designate this node's entity.
An LEI code taken from the LEI issuing prefix namespace of a
GLEIS LOU.
An ISO 17442-compatible code, not taken from the LEI issuing
prefix namespace of a GLEIS LOU.
StartNode is directly consolidated by
EndNode. The StartNode "child" entity has its
accounts fully consolidated by the EndNode "parent" entity, in
the sense given by the accounting standard(s) specified in
RelationshipQualifiers; the EndNode entity is the closest fully
consolidating parent to the StartNode entity in any applicable
hierarchical ownership structure.
StartNode is ultimately consolidated by
EndNode. The StartNode "child" entity has its
accounts fully consolidated by the EndNode "parent" entity, in
the sense given by the accounting standard(s) specified in
RelationshipQualifiers; the EndNode entity is the most distant
fully consolidating parent from the StartNode entity in any
applicable hierarchical ownership structure.
StartNode is an international branch of the legal
entity designated by EndNode (in jurisdiction country of
StartNode). The EndNode is the Head Office and
MUST be an LEI.
Contains one set of start and end dates for a particular type
of period, for example, the duration of the relationship itself, the filing
or validity period of any documents demonstrating the relationship, or the
accounting period they refer to.
The start date for a particular period relevant to the
relationship.
The end date for a particular period relevant to the
relationship.
The particular type of period, for example, the duration of
the relationship itself, the filing or validity period of any documents
demonstrating the relationship, or the accounting period they refer
to.
The dates in this instance of RelationshipPeriod
indicate the accounting period covered by the most recent validation
documents for this relationship.
The dates in this instance of RelationshipPeriod
indicate the duration of validity of the relationship itself, as distinct
from any administrative or reporting aspects.
The dates in this instance of RelationshipPeriod
indicate the validity period of a regulatory filing, accounting document, or
other document demonstrating the relationship's validity.
As of the last report or update, the reporting legal entity
reported that it is legally registered and/or operating, AND that the
relationship detailed in this RelationshipRecord is still
valid.
It has been determined that the relationship ended, e.g.
because entity that reported this relationship is no longer legally
registered and/or operating; or the relationship is no longer valid for
other reasons.
Container for all sets of relationship qualifier information.
Designates the optional list of additional qualitative
attributes that help to categorize the relationship.
Specifies the additional qualitative attributes that help to
categorize the relationship.
The accounting standard applied to determine the definition of
e.g. ultimate or direct accounting consolidating parent for the relationship
detailed in this RelationshipRecord. The relevant accounting
standard is that applicable to the EndNode (the "parent"
entity).
United States-Generally Accepted Accounting
Principles.
International Financial Reporting Standard (developed by the
International Accounting Standards Board – IASB see
http://www.ifrs.org).
A financial reporting (accounting) standard not otherwise
listed in the latest version of the relationship data file
format.
Specifies one additional quantitative attribute of the
relationship, according to a particular measurement method.
Specifies the method of measurement (or set of rules) used to
quantitatively categorize the relationship.
Specifies the quantity measured as a decimal (positive or
negative) number, using a . as the decimal point, with no
spaces, and without thousand delimiters (e.g. ,).
Specifies the units, where applicable, of a measurement made
on a relationship.
Accounting consolidation holds when "[in the] financial
statements of a group [...] the assets, liabilities, equity, income,
expenses and cash flows of the parent and its subsidiaries are presented as
those of a single economic entity (please see
http://www.iasplus.com/en/standards/ias/ias27-2011).
The date at which the relationship information was first
collected by the ManagingLOU.
The date at which the information was most recently updated by
the ManagingLOU.
The status of the legal entity's relationship record
registration with the ManagingLOU.
The next date by which the relationship information must be
renewed and re-certified by the legal entity.
The LEI of the LOU that is responsible for administering this
relationship record.
Level of relationship validation.
Type of source document(s) used for validating the
relationship.
A reference to a specfic document or other source used as the
basis of relationship validation for this relationship record.
A structure for adding further elements in to the
Registration section of the Relationship Record in
anticipation of a new version, by nesting a series of XML elements with this
content model within the NextVersion element, one for each new
minor version of the schema, postpending a serial number (1,2,3...) to the
element name upon each iteration.
This Extension element may contain any additional
elements required to extend the Registration container element.
A relationship data report that has been submitted to the LOU
and which is being processed and validated, prior to
publication.
A relationship data report that has been validated and
published, and which is reported by an entity that was an operating legal
entity as of the last update.
A relationship data report that has been determined to be a
duplicate registration of the same relationship. In many cases this will
mean more than one report with e.g. the same 2 entity IDs, the same
relationship type, certain status values and the same relationship date(s),
but this determination will depend on the relationship type in
question.
A relationship data report that has not been renewed by the
NextRenewalDate.
The relationship is considered to have ended, but the
relationship report is kept in publication for historical audit trail
purposes.
A relationship data report that was marked as erroneous or
invalid after it was published. The relationship report is kept in
publication for historical audit trail purposes only (so that data
recipients can correct their local data).
A relationship data report that has been transferred to a
different LOU as the ManagingLOU. A record in this state is not
published, but may be used internally by the prior LOU for audit trail
purposes.
A relationship data report for which a transfer to another LOU
has been requested. The request is being processed at the sending LOU. When
the receiving LOU is ready, the status will be changed to
PENDING_ARCHIVAL by the sending LOU prior to completion of
the transfer.
This relationship data report is about to be transferred to a
different LOU, after which its registration status will revert to a
non-pending status. The PENDING_ARCHIVAL status serves to
inform recipients of LOU-provided data files that a relationship record will
be removed from that LOU’s published file after the transfer is
complete
A consolidated financial (accounting) statement, prepared and
submitted to the relevant authority.
An annual regulatory filing providing public information on
parent relationships.
Other documents supporting the preparation of consolidated
financial statements.
Contract(s) attesting to the validity of the
relationship.
Other official document(s) attesting to the validity of the
relationship.
The validation of the relationship data provided by the
registrant has not yet occurred. Records with this
ValidationSources value MUST not be
published.
Based on the validation procedures in use by the LOU
responsible for the record, the information associated with this record has
significant reliance on the information that a submitter provided due to the
unavailability of corroborating information.
Based on the validation procedures in use by the LOU
responsible for the record, the information supplied by the submitter can be
partially corroborated by supporting sources (e.g. financial statements with
other definitions of the relevant relationship type; quarterly or annual
regulatory filings, contracts and other documents used in preparing
financial statements).
The relationship data provided by the registrant has been
validated against an explicit relationship statement found in key sources
(e.g. consolidated financial statements).
- Elements of base data type
rr:LEIDateTimeProfile use this
datatype to further restrict the ISO 8601 range of date and time format
to the single format:
YYYY-MM-DDThh:mm:ss.sssTZ
where the components of the above string are as follows:
- YYYY is the year
- MM is the month (01 = January, …, 12 = December)
- DD is the day of the month (01 = first day of the month)
- T is the single character ‘T’
- hh is the hour (00 – 23)
- mm is the minute
- ss.sss is the second and milliseconds. Two digits must be used
for the seconds. From one to three digits may be used for
milliseconds, or omitted entirely along with the decimal
point.
- TZ is the time zone specifier, which can be one of:
- Z the single character ‘Z’, denoting Coordinated Universal
Time (UTC); or
- +hh:mm denoting a positive offset from UTC; or
- -hh:mm denoting a negative offset from UTC
This pattern therefore adds the restrictions, beyond the ISO 8601
specification:
- Only the specified pattern of digits, indicators and separators
may be used (no spaces or other white space characters).
- The time zone (TZ) MUST be present, although it
may be zero (Z) if all
dates and times are expressed as UTC+00:00.
- Only 3 decimal places maximum are allowed in the seconds section
(ss.sss).