Link Role Registry - Process 2.0

Supporting document for a Recommendation 31 July 2008

Copyright ©2008 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/lrr/REC-2008-07-31/lrr-process-REC-2008-07-31.html>
Editors:
Hugh Wallis, XBRL International Inc. <hughwallis@xbrl.org>
Walter Hamscher, Standard Advantage <walter@hamscher.com>
Contributor:
David Sheldon, DecisionSoft Ltd. <dws@decisionsoft.com>

Status

Circulation of this supporting document for a Recommendation is unrestricted. Recipients are invited to submit comments to lrrag@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This document describes the processes whereby entries may be added to, changed, or removed from the XBRL International Link Role Registry. The Link Role Registry is an online listing of XLink role and arc role attribute values that have been identified as potentially having wide utility. The Registry contains structured information about their purpose, usage and any intended impact on XBRL instance validation.

This document is an update to version 1.0 of the Link Role Registry, separating the structure of the registry itself from the definition of the process.

Table of Contents

1 Goals
1.1 Relationship to other work
1.2 Terminology
1.3 Language
1.4 Document conventions
1.4.1 Typographic conventions
1.4.1.1 Definition notation
1.4.1.2 Footnote notation
1.4.1.3 Element and attribute notation
1.4.2 Formatting conventions
2 Update Process
2.1 Steps to achieve Acknowledged status
2.2 Steps to achieve RECOMMENDATION status
2.3 Withdrawing a Role
2.4 Rescinding a RECOMMENDED Role

Appendices

A References
B Intellectual property status (non-normative)
C Acknowledgements (non-normative)
D Document history (non-normative)
E Errata corrections in this document

Figures

1 Acknowlegment Process (Non-Normative)
2 Recommendation Process (Non-Normative)

Examples

1 A normative example
2 A non-normative example
3 An example of poor usage

Definitions

BPB
CR
ISC
IWD
LRR
LRRAG
PWD
SIPWG
SWG
TAPWG
TRTF
XSB
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.
referee
rfc2119 terminology


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. These include those specified in [XBRL 2.1], [DIMENSIONS] and any additional modules that are XBRL RECOMMENDATIONs. As XBRL applications emerge, new, non-standard roles having common and useful semantics are peing proposed. The goal of the XBRL Link Role Registry 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, are processeed through a series of steps detailed in this document. The goal is to maximise the utility and longevity of the new roles and the taxonomies that use them.

1.1 Relationship to other work

This document pertains to XBRL as defined in the XBRL Specification [XBRL 2.1] and additional modules such as [DIMENSIONS].

The processes in this document are partially modelled on those in [TECH-WG-PROCESSES]

1.2 Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in [IETF RFC 2119].

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. are as defined by [XBRL 2.1] .

BPB refers to the XBRL International Best Practices Board .

CR refers to a Candidate Recommendation of XBRL International.

ISC refers to the XBRL International Steering Committee .

IWD refers to an Internal Working Draft of XBRL International.

LRR refers to the Link Role Registry that is the subject of this specification.

LRRAG refers to the Link Role Registry Approval Group.

PWD refers to a Public Working Draft of XBRL International.

Referee is either the SWG, TRTF, SIPWG, or TAPWG when performing an evaluation requested by the LRRAG.

SIPWG refers to the Software interoperability Practice Working Group set up by the BPB.

SWG refers to the XBRL International Base Specification and Maintenance Working Group .

TAPWG refers to the Taxonomy Architecture Practice Working Group set up by the BPB.

TRTF refers to the Taxonomy Review Task Force set up by the XSB.

XSB refers to the XBRL International Standards Board .

1.3 Language

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

All documentation supporting a role MUST be provided in English, and MAY be provided in additional languages.

1.4 Document conventions

1.4.1 Typographic conventions

1.4.1.1 Definition notation

Definitions are highlighted with green text.

1.4.1.2 Footnote notation

Comments which are informative, but not essential to the understanding of the point at hand, are provided in footnotes. All footnotes are non-normative.

1.4.1.3 Element and attribute notation

When referring to a specific element, it will be identified by its namespace prefix and local name. For example, the root element for a specification container element would be referred to as <variable:generalVariable> .

Attributes are also identified by their local name and, where appropriate, their namespace prefix. Attributes are distinguished from elements by prefixing them by an @ symbol. Thus, @id refers to the attribute with the name id.

When referring to any attribute, so long as it has a specific namespace, the local name is replaced by an asterisk ( *). Thus, the notation @xml:* specifies any attribute in the namespace http://www.w3.org/XML/1998/namespace.

1.4.2 Formatting conventions

The following highlighting is used for normative technical material in this document:

Example 1: A normative example

Text of the normative example.

The following highlighting is used for non-normative examples in this document:

Example 2: A non-normative example

Text of the helpful example.

Next paragraph of the helpful example.

Example 3 shows the formatting for non-normative examples of poor, discouraged or disallowed usage.

Example 3: An example of poor usage

The example itself.

2 Update Process

The process by which an entry is added to the LRR is described below. This is modelled on [TECH-WG-PROCESSES] but is shortened to reflect the fact that the nature of an LRR entry is significantly less pervasive than that of a specification or other work product that is the usual output of a Working Group.

In addition a "fast track" process is provided whereby roles that do not necessarily have general applicability (and so are unlikely to qualify for RECOMMENDED status) can nevertheless be included in the LRR as "Acknowledged".

The process starts when the submitter creates a submission containing all of the information needed (as specified in [LRR STRUCTURE]) and requests the LRRAG to enter it into the LRR. The submitter MUST indicate whether they are seeking Acknowledged or RECOMMENDATION status. If they are seeking Acknowledged status then the subsequent steps are as detailed in Section 2.1, if they are seeking RECOMMENDATION status then the subsequent steps are as detailed in Section 2.2.

Submitters should note that the initial status of their submission MUST be "PROPOSED" (see [LRR STRUCTURE]).

2.1 Steps to achieve Acknowledged status

A "fast track" process is provided to facilitate the inclusion of a role in the LRR which may not have general applicability but which the submitter would, nevertheless, like to have documented in a publicly accessible fashion. A role that successfully follows this "fast track" process will have an ending status of "ACK". As such it does not carry the same normative weight as a role with "REC" status.

  1. The 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, or if the submission is substantially similar to an entry that is already present in the LRR the LRRAG may request the submitters to agree a common solution between themselves and resubmit a single joint submission. If this is not acceptable to the submitters the XSB will be requested to arbitrate.
  2. The LRRAG approve the requirements and conduct a technical evaluation. If the LRRAG determine that wider technical evaluation is necessary they MAY then refer the submission to any or all (at their discretion) of the SWG, the TRTF, the SIPWG or the TAPWG (hereinafter the referee) for such technical evaluation.
  3. If there are significant objections or problems arising as a result of this evaluation the LRRAG MAY request the submitter to address such issues. The submitter may then either modify the submission and resubmit, withdraw the submission, or appeal to the XSB.
  4. If there are no significant objections or problems arising as a result of this evaluation the role is entered into the LRR with a status of "ACK" and the process is complete.
Figure 1: Acknowlegment Process (Non-Normative)
Swimlane Diagram of Acknowledgement Process

2.2 Steps to achieve RECOMMENDATION status

A role that follows this track will have a status that is normative to the extent documented in Section 4 ("Normative Status of Roles in the LRR and Software") of [LRR STRUCTURE]. Thus the process is, necessarily, considerably more rigorous than a role that follows the"fast track" process leading to "Acknowledged status".

  1. The 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, or if the submission is substantially similar to an entry that is already present in the LRR the LRRAG may request the submitters to agree a common solution between themselves and resubmit a single joint submission. If this is not acceptable to the submitters the XSB will be requested to arbitrate.
  2. The LRRAG approve the requirements and conduct a technical evaluation. At this stage the entry is added to the LRR with a status of "PROPOSED". If the LRRAG determine that wider technical evaluation is necessary they MAY then refer the submission to any or all (at their discretion) of the SWG, the TRTF, the SIPWG or the TAPWG (hereinafter the referee) for such technical evaluation.
  3. If requested in the previous step the referee deliberates the submission. If they are satisifed then they recommend to the LRRAG that they approve release of the submission as a CR . If they are not satisfied they advise the LRRAG giving their reasons. The LRRAG in turn notifies the submitter who MAY then either modify the submission and resubmit, withdraw the submission, or appeal to the XSB.
  4. The LRRAG approves the submission and recommends to the XSB that it be released as a CR. (Note that, in the interests of a speedy process, this bypasses the PWD step of [TECH-WG-PROCESSES]).
  5. Upon approval of such publication by the XSB, the LRRAG updates its status in the LRR to CR. A notice of this change is made in the same way as such notices are published according to [TECH-WG-PROCESSES] and feedback requested.
  6. The LRRAG or, if it decides to delegate this step, the referee verifies that the conformance suite tests are valid and that there are two separate implementations that pass them. This step is only necessary if a conformance suite is required (i.e. if there are specific semantics associated with the entry that require software validation)
  7. If the submission affects validation of either taxonomies or instances the LRRAG calls for two implementations in the same way as a "Call for Implementations" is made according to [TECH-WG-PROCESSES]. This stage may be bypassed at the discretion of the LRRAG if it is known that two implementations already exist or if validation is not affected.
  8. A minimum of 45 days of public review follow.
  9. If a "Call for Implementations" has been issued this step MUST NOT begin until two such implementations are known to the LRRAG. The LRRAG or, if it decides to delegate this step, the referee makes any necessary amendments pursuant to the CR feedback and, unless it determines that a new CR is necessary, the LRRAG recommends to the XSB that it be published as a RECOMMENDATION who in turn recommend such to the ISC.
  10. The ISC approves the RECOMMENDATION and the status of the entry in the LRR is changed to "REC".
Figure 2: Recommendation Process (Non-Normative)
Swimlane Diagram of Recommendation Process

The process by which an entry may be updated in the LRR is analogous. If errata are discovered in any roles with "REC" status 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.

2.3 Withdrawing a Role

Unless a role has the status of "REC" it may be withdrawn from the LRR at any time upon request of the original submitter. Such request MUST be made to the LRRAG by e-mail to the address published at http://www.xbrl.org/lrr.

A role with the status "REC" MAY NOT be withdrawn in this manner but MUST follow the process in Section 2.4 for rescinding a RECOMMENDED role.

2.4 Rescinding a RECOMMENDED Role

The process of rescinding a role is not defined. If a situation arises whereby it becomes necessary to do so it will be defined following the model of [TECH-WG-PROCESSES].

Appendix A References

DIMENSIONS
XBRL International Inc.. "XBRL Dimensions 1.0"
Ignacio Hern√°ndez-Ros, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm)
IETF RFC 2119
IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.
(See http://www.ietf.org/rfc/rfc2119.txt)
LRR STRUCTURE
XBRL International Inc. "Link Role Registry - Structure 2.0"
Hugh Wallis, and Walter Hamscher.
(See http://www.xbrl.org/Specification/lrr/REC-2008-07-31/lrr-REC-2008-07-31.html)
TECH-WG-PROCESSES
XBRL International Inc. "Technical Working Groups - Processes and Procedures"
XBRL International Standards Board.
(See http://www.xbrl.org/XSB/XBRL_Technical_Working_Group_Processes-Approved-2007-04-17.htm)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2008-07-02"
Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm)

Appendix B Intellectual property status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

Appendix C Acknowledgements (non-normative)

This document could not have been written without the contributions of many people including the participants in the Link Role Registry Approval Group.

Appendix D Document history (non-normative)

DateAuthorDetails
22 July 2008Hugh Wallis

Split the LRR process documentation from the original RECOMMENDATION that included both the specification and the process by which entries were approved.

Converted to use the S4S publishing format.

Added other stati for entries so as to allow for a less rigorous approval processes to be applied to those entries that are not intended to carry the same normative status as those defined in XBRL RECOMMENDATIONS.

25 July 2008Walter Hamscher

Added definition of referee and corrected bibliography entries.

28 July 2008Walter Hamscher

Deleted comments and unwanted paragraph about specification defined roles.

29 July 2008Walter Hamscher

Changed "SUB" to "PROPOSED"

Added SIPWG to Referee definition

30 July 2008Hugh Wallis

Editorial for publication as REC

30 July 2008Walter Hamscher

Added figures. The text remains normative and figures are marked non-normative.

Appendix E Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Link Role Registry Approval Group up to and including 31 July 2008. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.