Linkbase Role Registry 1.0

RECOMMENDATION of 2006-02-21

Copyright © 2004, 2005, 2006, XBRL International Inc., All Rights Reserved


This version:



is the NORMATIVE version of the Specification. All other versions and formats are non-normative.





Walter Hamscher

Standard Advantage /

Consultant to PricewaterhouseCoopers





David Sheldon

DecisionSoft Ltd.

Hugh Wallis

XBRL International Inc.


This document describes the XBRL International Link Role Registry and the XBRL International process by which it is updated.  The Link Role Registry is an online listing of XLink role and arc role attribute values that may appear in XBRL International acknowledged and approved taxonomies, along with structured information about their purpose, usage and any intended impact on XBRL instance validation.


The circulation of this RECOMMENDATION is unrestricted. It received approval for publication by the International Steering Committee of XBRL International on 2006‑02‑21.   Recipients are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Table of Contents

Editors. i

Contributors. i

Abstract i

Status. i

Table of Contents. i

Table of Figures. ii

1      Goals. 1

1.1       Intended audience. 1

1.2       Document scope. 1

1.3       Organisation of this document 1

1.4       Terminology and document conventions. 1

1.5       Language independence. 2

2      Data Model 2

3      Update Process. 4

4      Hosting on the website. 5

5      Criteria. 5

6      Normative Status of Roles in the LRR and Software. 6

A      Schema. 8

A.1       lrr.xsd (normative) 8

B      Sample lrr document (non-normative) 11

C      References (non-normative) 13

G      Intellectual Property Status (non-normative) 13

H      Acknowledgements (non-normative) 14

I       Document History (non-normative) 14

J       Errata corrections incorporated in this document 15


Table of Figures

Figure 1.  Terminology. 1

Figure 2.  An LRR “role” entry. 2

Figure 3.  Approval process for LRR entries. 7

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 for definitions of these and other terms.  These include, in particular:


Conforming documents and applications are encouraged to behave as described.


Conforming documents and consuming applications are required to behave as described; otherwise they are in error.


Candidate Recommendation


Draft Candidate Recommendation


Domain Working Group


Financial Reporting Taxonomy Architecture


International Steering Committee


Internal Working Draft


Link Role Registry


LRR Advisory Group


Public Working Draft


Specification Working Group


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:

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.

Figure 2.  An LRR “role” entry





Role URI


This is the role URI being defined.

Role Type

{arcrole, role}

Defines whether arc role or role.




The XBRL International status of this role.


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 Location


URI of fragment in a schema where the definition resides.

Version Date


Effective date of this version of the role; all versions of the same role with earlier dates are effectively superseded



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>


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.


List of NCNames with optional namespace

For arc roles, identifies any attributes that are allowed or required; not present for roles.





Version of XBRL


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.


Minimum Edition Date


The XBRL edition date and beyond for which this is an extension.


Impacts Taxonomy Validation


Whether elements using this role impact XBRL taxonomy validation in ways not captured by roleType or arcRoleType declarations.  If so, then the role cannot appear on extended links in FRTA taxonomies as a consequence of rule 3.1.4 [FRTA].



False means that whether a validator processes this role specially or not will have no impact on the validity of the taxonomy.

Impacts Instance Validation


Whether elements using this role impact XBRL instance validation.  If so, then the role cannot appear on extended links in FRTA taxonomies as a consequence of rule 3.1.4 [FRTA].



True means that an instance could fail XBRL validation depending on whether the validator processes this role specially or not.


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


A URI locating a conformance suite illustrating valid and invalid usage. Only required if additional validation is specified.


The URI need not have 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 an IWD 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.      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 IWD. If this is not acceptable to the submitters the ISC will be requested to arbitrate.

3.      The DWG approve the requirements and then submit the IWD to the SWG for technical evaluation.

4.      The SWG deliberates the IWD.

5.      The SWG calls for two implementations if they do not already exist.

6.      The SWG recommends to the DWG that they approve release of the IWD as a PWD.

7.      The DWG approves the IWD produced by the SWG, in effect recommending to the ISC that it be released as a PWD.

8.      The SWG, with consent of the DWG thus obtained, recommends to the ISC that it be released as a PWD.

9.      The ISC approves it as a PWD 

10.  The LRRAG enters it into the LRR with its status set to PWD.  A notice of its addition is made to the XBRL-INT and XBRL-Public mailing lists and feedback requested.

11.  A minimum of forty-five days of public review follow.

12.  The SWG verifies that the conformance suite tests are valid and that there are two separate implementations that pass them.

13.  The SWG makes any necessary amendments pursuant to the PWD feedback and, unless it determines that a new PWD is necessary, the SWG recommends to the ISC that a DCR be published (as amended if appropriate) as a CR.

14.  The ISC approves the CR. 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 SWG.  Substantive changes require a new DCR (return to step 13).  The SWG recommends 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 website

The latest version of the LRR will be placed at a fixed location on the website and will be the file at the URL  Each version will also be permanently archived in a subdirectory whose name contains the date on which it became effective (e.g. This is analogous to the archival convention 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

A       Schema

The following is the XML schema corresponding to the data model of section 2 above.  It is normative. Non-normative versions (which should be identical to these except for appropriate comments indicating their non-normative status) are also provided as separate files for convenience of users of the specification.  Following the schema maintenance policy of XBRL International, it is the intent (but is not guaranteed) that the location of non-normative versions of these schemas on the web will be as follows:

1)         While any schema is the most current RECOMMENDED version and until it is superseded by any additional errata corrections a non-normative version will reside on the web at:

2)         A non-normative version of each schema as corrected by this update to the RECOMMENDATION will be archived in perpetuity on the web at:

Note that some of the data model of section 2 is not explicitly contained in the LRR document. This information is available as part of the authoritative arcrole/roleType definition. Also note that although the URIs in the attributes of these elements are not required to be absolute, they will be in the official LRR. This is required as it is available from two locations (see section 4 above).

To accomodate possible future expansion of the information in the registry, both the role and arcrole elements have an open content model that allows them to have any number of additional child elements in any namespace.

A.1    lrr.xsd (normative)

<?xml version="1.0" encoding="US-ASCII"?>

<!-- (c) XBRL International.  See -->

<xs:schema xmlns:lrr="" xmlns:xs="" targetNamespace="" elementFormDefault="qualified" attributeFormDefault="unqualified">

  <xs:simpleType name="useType">


      <xs:documentation>Three possible values of use</xs:documentation>


    <xs:restriction base="xs:NMTOKEN">

      <xs:enumeration value="optional"/>

      <xs:enumeration value="required"/>

      <xs:enumeration value="prohibited"/>



  <xs:complexType name="DocumentationType" mixed="true">


      <xs:documentation>Definition of a type to contain mixed text and XHTML markup</xs:documentation>


    <xs:complexContent mixed="true">

      <xs:restriction base="xs:anyType">

        <xs:sequence minOccurs="0" maxOccurs="unbounded">

          <xs:any namespace="" processContents="lax"/>


        <xs:anyAttribute namespace="" processContents="lax"/>




  <xs:group name="roleGroup">


      <xs:element ref="lrr:roleURI"/>

      <xs:element ref="lrr:status"/>

      <xs:element ref="lrr:versionDate"/>

      <xs:element ref="lrr:authoritativeHref"/>

      <xs:element ref="lrr:requirement" maxOccurs="unbounded"/>

      <xs:element ref="lrr:definition" maxOccurs="unbounded"/>

      <xs:element ref="lrr:versionOfXBRL"/>

      <xs:element ref="lrr:minimumEditionDate"/>

      <xs:element ref="lrr:impactsTaxonomyValidation"/>

      <xs:element ref="lrr:impactsInstanceValidation"/>

      <xs:sequence minOccurs="0" maxOccurs="1">

        <xs:element ref="lrr:conformanceSuiteURI"/>

        <xs:element ref="lrr:validation" minOccurs="1" maxOccurs="unbounded"/>


      <xs:any processContents="lax" namespace="##other" minOccurs="0" maxOccurs="unbounded"/>



  <xs:element name="lrr">


      <xs:documentation>Root element of the XBRL Linkbase Role Registry</xs:documentation>




        <xs:element name="roles">


            <xs:sequence minOccurs="0" maxOccurs="unbounded">

              <xs:element name="role">


                  <xs:group ref="lrr:roleGroup"/>






        <xs:element name="arcroles">


            <xs:sequence minOccurs="0" maxOccurs="unbounded">

              <xs:element name="arcrole">



                    <xs:group ref="lrr:roleGroup"/>

                    <xs:element ref="lrr:attributes"/>

                    <xs:element name="sourceAbstract" type="lrr:useType" default="optional">


                        <xs:documentation>For arc roles, whether the "from" concept is abstract; otherwise empty.</xs:documentation>



                    <xs:element name="targetAbstract" type="lrr:useType" default="optional">


                        <xs:documentation>For arc roles, whether the "to" concept is abstract; otherwise empty. </xs:documentation>










      <xs:attribute name="version" type="xs:token" fixed="1.0"/>



  <xs:element name="roleURI" type="xs:anyURI">


      <xs:documentation>This is the role URI being defined.</xs:documentation>



  <xs:element name="status">


      <xs:documentation>The XBRL International status of this role.  PWD, CR, REC, IWD or NIE.</xs:documentation>



      <xs:restriction base="xs:token">

        <xs:enumeration value="PWD"/>

        <xs:enumeration value="CR"/>

        <xs:enumeration value="REC"/>

        <xs:enumeration value="NIE"/>

        <xs:enumeration value="IWD"/>




  <xs:element name="versionDate" type="xs:date">


      <xs:documentation>Effective date of this version of the role; all versions of the same role with earlier dates are effectively superseded</xs:documentation>



  <xs:element name="attributes">


      <xs:documentation>Lists any attributes that are allowed or required.</xs:documentation>



      <xs:sequence minOccurs="0" maxOccurs="unbounded">

        <xs:element name="attribute">



              <xs:extension base="xs:NCName">

                <xs:attribute name="namespaceURI" type="xs:anyURI" use="optional" />

                <xs:attribute name="use" type="lrr:useType" use="required"/>








  <xs:element name="versionOfXBRL" type="xs:token">


      <xs:documentation>The XBRL version for which this an extension.  In principle, a role could be "promoted" into a standard role in some future version of the specification.</xs:documentation>



  <xs:element name="minimumEditionDate" type="xs:date">


      <xs:documentation>The XBRL edition date and beyond for which this is an extension. </xs:documentation>



  <xs:element name="impactsTaxonomyValidation" type="xs:boolean">


      <xs:documentation>Whether elements using this role impact XBRL instance validation.  If so, then the role cannot appear in FRTA taxonomies [FRTA].</xs:documentation>



  <xs:element name="impactsInstanceValidation">


      <xs:documentation>Whether elements using this role impact XBRL instance validation.  If so, then the role cannot appear in FRTA taxonomies [FRTA].</xs:documentation>



  <xs:element name="validation" type="lrr:DocumentationType">


      <xs:documentation>A textual or pseudocode specification of the intended impact on XBRL validation of instances.  If Instance Validation Impact is "optional" then this would be empty.</xs:documentation>



  <xs:element name="conformanceSuiteURI" type="xs:anyURI">


      <xs:documentation>A URI locating a testcases element containing testcase elements with relative URIs to files illustrating valid and invalid usage.</xs:documentation>



  <xs:element name="requirement" type="lrr:DocumentationType">


      <xs:documentation>A statement of the requirements that gave rise to this role.  Requirements in different languages are distinguished using the xml:lang attribute.</xs:documentation>



  <xs:element name="definition" type="lrr:DocumentationType">


      <xs:documentation>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.</xs:documentation>



  <xs:element name="authoritativeHref" type="xs:anyURI">


      <xs:documentation>The URI where the schema defition of the role or arc role is found.</xs:documentation>




B       Sample lrr document (non-normative)

The following is an example of an lrr (as defined by the schema in appendix A above).  It contains only a single entry each to illustrate the definition of a role and an arcrole.

<?xml version="1.0" encoding="US-ASCII"?>

<?xml-stylesheet type="text/xsl" href="lrr2html.xsl"?>

<lrr:lrr xmlns:lrr="" version="1.0" xmlns:xsi=""  xsi:schemaLocation="" xmlns:xhtml="">







      <lrr:requirement xml:lang="en">At times an entity may restate certain account balances for financial reporting purposes. This may only occur according to specific reporting rules.  For example, an entity may restate an equity account balance, say "Reserves", due to an accounting change or fundamental error under International Financial Reporting Standards (IFRS).  A separate label role is provided for such reporting of restated balances, should they occur.  The restated balance within a financial statement might provide a label such as "Reserves, Restated Balance" to which this label role would be assigned to identify this type of label.  Taxonomy creators would use this label role and provide a label which could be used on concepts that could be restated.  Typically, these would be used on equity accounts.


      <lrr:definition xml:lang="en">The label for a concept when presenting values that have been restated from their value as originally reported.</lrr:definition>













      <lrr:requirement xml:lang="en">An instance document author may want to indicate that the facts in the instance are known to be inconsistent with a certain network of arcs in the instance's DTS.


      <lrr:definition xml:lang="en">On an arc using the expected-inconsistency arc role, the from label will reference a set of locators to elements in the item substitution group.  The to label will reference a resource whose content is an extended link role used in the DTS of the instance for a calculation link.







      <lrr:validation xml:lang="en">The existence of arcs using the <xhtml:i>expected-inconsistency</xhtml:i> arc role does not affect the validity of the instance document. However, if validation does detect an inconsistency in a calculation link network of arcs which involves one of the elements of the facts participating in this arc acting as a summation item and the other elements acting as contributing items, the presence of this footnote arc is a signal to the validating application that this particulat inconsistency was expected to occur by the instance author.  Therefore the validating application <xhtml:b>may</xhtml:b> choose to handle the inconsistency signal for this particular summation in a different way than it handles signals arising from other inconsistencies.



        <lrr:attribute namespaceURI="" use="optional">importance</lrr:attribute>







C       References (non-normative)

The hyperlinks to HTML format XBRL International documents are to the non-normative versions of those documents but are provided in this format for convenience. Those documents indicate the location of their relevant normative versions.


Walter Hamscher, Ron van Ardenne, Hugh Wallis


XBRL 2.1 Conformance Suite 1.0, Candidate Recommendation 2 of 2005-11-07




Walter Hamscher (editor).


Financial Reporting Taxonomies Architecture 1.0 Recommendation dated 2005-04-25




International Standards Organisation.


ISO 4217 Currency codes, ISO 639 Language codes, ISO 3166 Country codes, ISO 8601 international standard numeric date and time representations.




Scott Bradner


Key words for use in RFCs to Indicate Requirement Levels, March 1997




Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis.


Extensible Business Reporting Language (XBRL) 2.1 Recommendation 2003-12-31 + Corrected Errata - 2005-11-07

G       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 (


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 (

H        Acknowledgements (non-normative)

The participants in the XBRL Domain and Specification Working Groups and public commentators have all played a role.  The work of David vun Kannon (PwC) and Geoff Shuetrim (Galexy – formerly KPMG) on an extensive variety of proposed roles and arc roles first inspired the creation of a registry that would provide a framework for orderly XBRL extensions.  The XBRL International Domain working group is chaired by Marc van Hilvoorde (KPMG).  The XBRL International Specification working group is chaired by Cliff Binstock (UBmatrix). We also thank the following people for their comments and suggestions: Mark Goodhand (DecisionSoft), Masatomo Goto (Fujitsu), Charles Hoffman (UBmatrix) and John Turner (CoreFiling).

I            Document History (non-normative)






First draft of document prepared.



Various updates, changes and comments added, including the definition of the normative status of roles in the LRR.



Incorporated comments; added the Language, Minimum Erratum Level, Validation Impact and Conformance Suite fields while removing Ignorable and Instances.  Added reference to Conformance Suite Public Working Draft.



Added fields indicating whether Abstract elements may be at the head and tail of an arc.



Edited the text to avoid remarks about grammar.



Updated with input from the DWG F2F meeting in London



Updated figure and made formatting changes.



Updated figure and process to defer the requirement for two implementations until the CR phase, and to allow for multiple CRs.



Reformatted to conform to current pagination conventions.  Edited table.  Created a Schema and example lrr database.  Removed the language element and embedded with the xml:lang attribute.



Added href, so that the role definition has an authoritative location; added conformance tests to the sample files.



Typographical corrections; prepared Candidate Recommendation.



Correction of normative file location to



Correction to examples and schema relating to the lrr:element and lrr:attribute declarations, adding “use” attribute to the attribute declaration.  Miscellaneous changes to the schema, including the introduction of the roleGroup group, absoluteURI type, and removing spurious comments.  Edited the ‘abstract’ ‘cycles’ and other table entries to clarify that they apply only to arc roles.   Expanded the explanation of the “validation impact” entries, and added “taxonomy validation impact” and made these Booleans.   Edited schemas and sample to use 2005 dates.  Edited schemas and samples to limit definitions to US-ASCII encoding in anticipation of future use by legacy applications.  Repaired the description of what is returned from the canonical lrr location and repaired references locations.  Prepared a Draft Candidate Recommendation.



Made the namespace URI attribute mandatory when not empty.  Required the conformance URI and authoritative href to both be absolute, and updated schema accordingly.  Changed the authoritative href to a fragment.  Added approval procedure notice requiring a conformance suite.  Reorganized directory structure for sample files.



Updated references and acknowledgments.



Updated to reflect Draft Candidate Recommendation and appropriate normative statuses, corrected normative file locations to{xml,xsd}.



Updated to reflect Candidate Recommendation 2 status.



Use standard XBRL roleRef and arcroleRef elements. Remove duplication from the dataset, and remove requirement for absolute URIs.



Went back to using roleURI rather than roleRef and arcroleRef elements. Rephrased absolute URI discussion, and only require conformanceSuite if there is additional validation.



Edits to approval process explanation, and update to the approval process timeline.



Editorial changes including use of SWG, DWG, IWD, PWD, DCR and CR abbreviations and additions to glossary; renumbering of process steps; revised target dates to add another month.



Edited schema to allow for any other elements to appear in a role or arcrole entry.  Revised target dates.



Minor correction to lrr.xsd schema – editorial for Candidate Recommendation 4 publication



Editorial to reflect RECOMMENDATION Status

J         Errata corrections incorporated 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 appropriate XBRL International Working Group (WG) up to and including 2006-02-21. 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.

Erratum number

Brief description and link(s) to relevant discussion thread(s)

Affected section(s)

Date Correction Approved by the WG

There are no errata at this time for this RECOMMENDATION.