1 Goals
XBRL provides a set of standard roles and arc roles (hereinafter generally referred to as “roles”) that may appear in XBRL instances and linkbases. As XBRL applications emerge, it is leading to the proposal of new, non-standard roles having common and useful semantics. The goal of the XBRL Link Role Registry (hereinafter “LRR”) is to be a public, online data set that documents these non-standard roles and their usage. Additions and other changes to the LRR, like other XBRL International work products, will proceed through a series of steps whose goal is to maximise the utility and longevity of the new roles and the taxonomies that use them.
1.1 Intended audience
This document is intended for those familiar with XBRL linkbases.
1.2 Document scope
The scope of this document encompasses both the structure of the LRR and the processes by which additions, changes, and removals are made.
1.3 Organisation of this document
This document consists of the following sections in addition to this introduction:
· Data model of the online resource;
· Process model for changes to the LRR;
· Criteria for inclusion;
· Normative status of roles recorded in the online resource and its effect on software.
1.4 Terminology and document conventions
Terminology used in XBRL frequently overlaps with terminology from other fields.
Figure 1. Terminology
|
abstract element, bind, concept, concrete element, context, Discoverable Taxonomy Set (DTS), duplicate items, duplicate tuples, element, entity, equal, essence concept, fact, instance, item, least common ancestor, linkbase, period, taxonomy, tuple, unit, taxonomy schema, child, parent, sibling, grandparent, uncle, ancestor, XBRL instance, c-equal, p-equal, s-equal, u-equal, v-equal, x-equal, minimally conforming XBRL processor, fully conforming XBRL processor and any other terms not specifically defined elsewhere in this document but which are used and defined in the XBRL 2.1 specification. |
As defined in XBRL |
||||
|
must, must not, required, shall, shall not,
should, should not, may, optional |
See http://www.ietf.org/rfc/rfc2119.txt for definitions of these and other terms. These include, in particular:
|
||||
|
FRTA |
Financial Reporting Taxonomy Architecture |
||||
|
LRR |
Link Role Registry |
||||
|
XBRL |
XBRL 2.1 recommendation [XBRL]. |
The following highlighting is used for non-normative examples in this document:
|
|
Non-normative editorial comments to be removed from final recommendations are denoted as follows:
WH: This highlighting is used to indicate editorial comments about the current draft, prefixed by the editor’s initials.
Italics are used for rhetorical emphasis only and do not convey any special normative meaning.
1.5 Language independence
All documentation supporting a role MUST be provided in English, and MAY be provided in additional languages. The official language of XBRL International is UK English.
2 Data Model
The data model of the LRR is merely a list of each role type and arc role type definitions augmented with additional indicators and information needed by developers and applications.
Figure 2. An LRR “role” entry
|
Field |
Type |
Explanation |
Example |
|
Role URI |
URI |
This is the role URI being defined. |
http://www.xbrl.org/2003/role/restatedLabel |
|
Role Type |
{arcrole, role} |
Defines whether arc role or role. |
arcrole |
|
Status |
{PWD, CR, REC, NIE, IWD} |
The XBRL International status of this role. |
PWD PWD = Public Working Draft; CR = Candidate Recommendation; REC = Recommendation; NIE = Not in effect (for whatever reason such as being withdrawn, superseded, found to be invalid etc.); IWD = Internal Working Draft (only
appears in internal working versions of the lrr). |
|
Authoritative Href |
URI |
Location of the schema where the definition resides. |
http://www.xbrl.org/2004/role/restatedLabel.xsd
(absolute) or role/restatedLabel-2004-11-07.xsd |
|
Version Date |
Date |
Effective date of this version of the role – all versions of the same role with earlier dates are effectively superseded |
2004-08-27 |
|
Requirements |
XHTML mixed |
A statement of the requirements that gave rise to this role. Requirements in different languages are distinguished using the xml:lang attribute and an ISO 639 language code [ISO]. |
<p>The role
<i>restatedLabel</i> is needed because of the frequent convention
when formatting financial statements, for
example:</p><table><tbody><tr><th></th></th>2003</th><tr><td>Expenses(restated)</td><td>2,000</td></tbody></table> |
|
Definition |
XHTML mixed |
The meaning of the role described in the same way as if it were in the specification. Definitions in different languages are distinguished using the xml:lang attribute and an ISO 639 language code [ISO]. |
The label for a concept
when one of the facts using that concept is presented to users as a
restatement of a previous period result. |
|
Elements |
List of QNames |
Identifies what elements may use this role. |
'label', in namespace 'http://www.xbrl.org/2003/linkbase' |
|
Attributes |
List of tokens |
Lists any special attributes that are allowed or required. |
'weight', for the summation‑item arc in the calculation linkbase. |
|
Cycles Allowed |
{none, any, undirected} |
For arc roles, the cycles that are allowed; otherwise empty. |
|
|
Abstract source |
{optional, prohibited, required} |
For arc roles, whether the “from” concept is abstract; otherwise empty. |
prohibited for a calculation arc of any kind or essence‑alias, optional in most other cases. |
|
Abstract target |
{optional, prohibited, required} |
For arc roles, whether the “to” concept is abstract; otherwise empty. |
prohibited for a calculation arc of any kind or essence‑alias, optional in most other cases. |
|
Version of XBRL |
Token |
The XBRL version for which this an extension. Note that a role could be “promoted” into a standard role in some future version of the specification. |
2.1 |
|
Minimum Erratum Level |
Nonnegative Integer |
The XBRL erratum date and beyond for which this is an extension. |
0 |
|
Instance Validation Impact |
{optional, required} |
Whether elements using this role impact XBRL instance validation. If so, then the role cannot appear in FRTA taxonomies [FRTA]. |
required (This value means that an instance could fail XBRL validation depending on whether the validator processes this role or not.) |
|
Validation |
XHTML mixed |
A textual or pseudocode specification of the intended impact on XBRL validation of instances. If Instance Validation Impact is “optional” this is empty. |
If an instance of the concept at the source of an arc with arcrole requires‑cEqual‑element occurs in an XBRL instance then an instance of the arc’s target concept MUST also occur in the XBRL instance in a c-equal context. This requirement does not impose requirements on relative locations of the concept instances in tuples. Fully conformant XBRL processors MUST detect and signal instances in which this relationship is violated. |
|
Conformance Suite |
URI |
A URI locating a testcases element containing testcase elements with relative URIs to files illustrating valid and invalid usage. |
http://www.this.com/xbrl/LRR/test/requires-cEqual-element.xml (The URI need not have www.xbrl.org as its host part.) |
3 Update Process
The process by which an entry is added to the LRR is depicted in Figure 3 below:
1. The submitter creates a working draft containing all of the information needed (as specified in Figure 2) and requests the Link Role Registry Approval Group (LRRAG) constituted of members from both the DWG and SWG to enter it into the LRR.
2. The DWG approve the requirements and then submit the request to the SWG for technical evaluation.
3. The Specification WG deliberates it in the form of an internal working draft.
4. LRRAG MAY suggest alternatives to the proposal and request to its editors that it be resubmitted as they see fit. In the event that there is more than one submission made for similar requirements the LRRAG may request the submitters to agree a common solution between themselves and resubmit a single joint request. If this is not acceptable to the submitters the ISC will be requested to arbitrate.
5. The Specification WG calls for two implementations if they do not already exist.
6. The Specification WG recommends to the Domain WG that it be published as a public working draft.
7. The Domain WG recommends to the ISC that it be published as a public working draft.
8. The Specification WG recommends to the ISC that it be published as a public working draft.
9. The ISC approves it as a public working draft.
10. The LRRAG enters it into the LRR with its status set to PWD. A notice of its addition is made to XBRL-INT and XBRL-public and feedback requested.
11. A minimum of forty-five days of public review follow.
12. The Specification WG verifies that the conformance suite tests are valid and that there are two separate implementations that pass them,
13. The Specification WG makes any necessary amendments pursuant to the PWD feedback and, unless it determines that a new PWD is necessary, the SWG and the DWG recommend to the ISC that it be published (as amended if appropriate) as a candidate recommendation.
14. The ISC approves the candidate recommendation. The ISC may choose to delegate this authority as it sees fit.
15. Two weeks pass during which only minor editorial changes MAY be made. Such changes MUST be approved by the Specification WG and the Domain WG. Substantive changes require a new CR (return to step 13). The SWG and the DWG recommend to the ISC that it be published as a recommendation
16. ISC approves the recommendation.
The process by which an entry may be updated in the LRR is analogous. If errata are discovered in any roles then a new version of the role will be entered into the registry following the same process as that used for errata corrections to the specification itself. The effective date of the errata corrected version will be later than that of the original and will thus supersede it.
One of the ways that a new entry may be added is when a new version of XBRL is issued. Individual roles might no longer be “extensions” in that newer version. Hence, only those extensions that are carried over as extensions to the new version will need a new entry that is identical other than the “XBRL Version” datum.
4 Hosting on the XBRL.org website
The latest version of the LRR will be placed at a fixed location on the xbrl.org website and will be the file that is displayed when a user types http://www.xbrl.org/lrr/. The actual file name will contain the date on which it became effective (e.g. http://www.xbrl.org/lrr/lrr-2004-08-26.xml). This is analogous to the archival mechanism for specification schemas.
5 Criteria
A role MUST meet these criteria to be approved by the LRRAG:
· Semantically distinct from existing standard and LRR roles;
· Of sufficient generality to be of likely use in multiple taxonomies;
· Sufficiently well documented so as to encourage correct usage.
In the case of a role that impacts validation, the criteria are much like that of extensions to the specification:
· Demonstration of two interoperable implementations via a conformance suite.
6 Normative Status of Roles in the LRR and Software
Once a role has the status of REC in the LRR it shall have the same normative status as any role documented in the version of the specification that it is extending.
Software vendors are NOT obliged to implement support for any REC role in order to continue to claim that they support the base specification.
It is expected that software vendors will make claims regarding which additional roles they support. They MUST point to successful exercising of the relevant conformance suite tests in order to substantiate such claims.
Figure 3. Approval process for LRR entries
