Linkbase Role Registry 1.0
Candidate Recommendation 2 of 2005-05-17
This version:
            XBRL-LRR-CR2-2005-05-17.rtf
 
is the NORMATIVE version of the Specification. All other versions and formats are non-normative.
Editors
Name	Contact	Affiliation	
Walter Hamscher	walter@hamscher.com	Standard Advantage / 
Consultant to PricewaterhouseCoopers	
Contributors
Name	Contact	Affiliation	
Hugh Wallis	hughwallis@xbrl.org 	Standard Dimensions/
XBRL International Inc.	
Abstract
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.
Status
The circulation of this Candidate Recommendation 2 is unrestricted.   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
Contributors
Abstract
Status
Table of Contents
Table of Figures
1	Goals
1.1	Intended audience
1.2	Document scope
1.3	Organisation of this document
1.4	Terminology and document conventions
1.5	Language independence
2	Data Model
3	Update Process
4	Hosting on the XBRL.org website
5	Criteria
6	Normative Status of Roles in the LRR and Software
A	Schema
A.1	lrr.xsd (normative)
B	Sample lrr document (non-normative)
C	References (non-normative)
G	Intellectual Property Status (non-normative)
H	Acknowledgements (non-normative)
I	Document History (non-normative)
J	Errata corrections incorporated in this document
K	Approval process (non‑normative)

Table of Figures
Figure 1.  Terminology
Figure 2.  An LRR “role” entry
Figure 3.  Approval process for LRR entries

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:
SHOULD	
Conforming documents and applications are encouraged to behave as described.	

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

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	Absolute URI fragment in the schema where the definition resides.	http://www.xbrl.org/2005/role/restatedLabel-2005-05-17.xsd#restatedLabel	
Version Date	Date	Effective date of this version of the role; all versions of the same role with earlier dates are effectively superseded	2005-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 NCNames with required namespace	Identifies what elements may use this role or arc role.	<elementsAllowedOn>
  <element namespaceURI="http://www.xbrl.org/2003/linkbase">label</element>
</elementsAllowedOn>	
Attributes	List of NCNames with optional namespace	For arc roles, identifies any attributes that are allowed or required; not present for roles.	<attributes>
<attribute
  use="required">weight</attribute>
</attributes>	
Cycles Allowed	{none, any, undirected}	For arc roles, the cycles that are allowed; not present for roles.		
Abstract source	{optional, prohibited, required}	For arc roles, whether the “from” concept is abstract; not present for roles.	prohibited for the summation‑item and essence‑alias arcs; optional in most other cases.	
Abstract target	{optional, prohibited, required}	For arc roles, whether the “to” concept is abstract; not present for roles.	prohibited for the summation‑item and essence‑alias arcs; optional in most other cases.	
Version of XBRL	Token	The XBRL version for which this an extension.  Note that a role or arc role could be “promoted” into a standard role in some future version of the specification.	2.1	
Minimum Edition Date	Date	The XBRL edition date and beyond for which this is an extension. 	2004-11-14	
Impacts Taxonomy Validation	Boolean	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 in FRTA taxonomies as a consequence of rule 3.1.4 [FRTA].	false

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 	Boolean	Whether elements using this role impact XBRL instance validation.  If so, then the role cannot appear in FRTA taxonomies as a consequence of rule 3.1.4  [FRTA].	true

True means that an instance could fail XBRL validation depending on whether the validator processes this role specially 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	An absolute URI locating a testcases element (or document whose root is a testcases element) containing testcase elements with relative URIs to files illustrating valid and invalid usage.	http://www.example.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 at the URL http://www.xbrl.org/lrr/lrr.xml.  Each version will also be permanently archived in a subdirectory whose name contains the date on which it became effective (e.g. http://www.xbrl.org/lrr/2005-05-17/lrr.xml). 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

1	
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:
 http://www.xbrl.org/lrr/lrr.xsd 
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:
http://www.xbrl.org/lrr/2005-05-17/lrr.xsd 
A.1	lrr.xsd (normative)
<?xml version="1.0" encoding="US-ASCII"?>
<!-- (c) XBRL International.  See www.xbrl.org/legal -->
<xs:schema xmlns:lrr="http://www.xbrl.org/2005/lrr" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.xbrl.org/2005/lrr" elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:simpleType name="useType">
    <xs:annotation>
      <xs:documentation>Three possible values of use</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:NMTOKEN">
      <xs:enumeration value="optional"/>
      <xs:enumeration value="required"/>
      <xs:enumeration value="prohibited"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="cycleType">
    <xs:annotation>
      <xs:documentation>Three possible values of cycle</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:NMTOKEN">
      <xs:enumeration value="any"/>
      <xs:enumeration value="undirected"/>
      <xs:enumeration value="none"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:complexType name="DocumentationType" mixed="true">
    <xs:annotation>
      <xs:documentation>Definition of a type to contain mixed text and XHTML markup</xs:documentation>
    </xs:annotation>
    <xs:complexContent mixed="true">
      <xs:restriction base="xs:anyType">
        <xs:sequence minOccurs="0" maxOccurs="unbounded">
          <xs:any namespace="http://www.w3.org/1999/xhtml" processContents="lax"/>
        </xs:sequence>
        <xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:simpleType name="absoluteURI">
    <xs:annotation>
      <xs:documentation>
      A URI type conforming strictly to absolute URIs as defined in RFC2396.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:anyURI">
      <xs:pattern value="[a-z][a-z\.\+\-]*:.*"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:group name="roleGroup">
    <xs:sequence>
      <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:elementsAllowedOn"/>
      <xs:element ref="lrr:versionOfXBRL"/>
      <xs:element ref="lrr:minimumEditionDate"/>
      <xs:element ref="lrr:impactsTaxonomyValidation"/>
      <xs:element ref="lrr:impactsInstanceValidation"/>
      <xs:element ref="lrr:conformanceSuiteURI"/>
      <xs:element ref="lrr:validation" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:group>
  <xs:element name="lrr">
    <xs:annotation>
      <xs:documentation>Root element of the XBRL Linkbase Role Registry</xs:documentation>
    </xs:annotation>
    <xs:complexType>
      <xs:sequence>
        <xs:element name="roles">
          <xs:complexType>
            <xs:sequence minOccurs="0" maxOccurs="unbounded">
              <xs:element name="role">
                <xs:complexType>
                  <xs:group ref="lrr:roleGroup"/>
                </xs:complexType>
              </xs:element>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
        <xs:element name="arcroles">
          <xs:complexType>
            <xs:sequence minOccurs="0" maxOccurs="unbounded">
              <xs:element name="arcrole">
                <xs:complexType>
                  <xs:sequence>
                    <xs:group ref="lrr:roleGroup"/>
                    <xs:element ref="lrr:attributes"/>
                    <xs:element name="cyclesAllowed" type="lrr:cycleType" default="any">
                      <xs:annotation>
                        <xs:documentation>For arc roles, the cycles that are allowed; otherwise empty.</xs:documentation>
                      </xs:annotation>
                    </xs:element>
                    <xs:element name="sourceAbstract" type="lrr:useType" default="optional">
                      <xs:annotation>
                        <xs:documentation>For arc roles, whether the "from" concept is abstract; otherwise empty.</xs:documentation>
                      </xs:annotation>
                    </xs:element>
                    <xs:element name="targetAbstract" type="lrr:useType" default="optional">
                      <xs:annotation>
                        <xs:documentation>For arc roles, whether the "to" concept is abstract; otherwise empty. </xs:documentation>
                      </xs:annotation>
                    </xs:element>
                  </xs:sequence>
                </xs:complexType>
              </xs:element>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
      <xs:attribute name="version" type="xs:token" fixed="1.0"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="roleURI" type="lrr:absoluteURI">
    <xs:annotation>
      <xs:documentation>This is the role URI being defined.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="status">
    <xs:annotation>
      <xs:documentation>The XBRL International status of this role.  PWD, CR, REC, IWD or NIE.</xs:documentation>
    </xs:annotation>
    <xs:simpleType>
      <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:restriction>
    </xs:simpleType>
  </xs:element>
  <xs:element name="versionDate" type="xs:date">
    <xs:annotation>
      <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:annotation>
  </xs:element>
  <xs:element name="elementsAllowedOn">
    <xs:annotation>
      <xs:documentation>Identifies what elements may use the role.</xs:documentation>
    </xs:annotation>
    <xs:complexType>
      <xs:sequence maxOccurs="unbounded">
        <xs:element name="element">
          <xs:complexType>
            <xs:simpleContent>
              <xs:extension base="xs:NCName">
                <xs:attribute name="namespaceURI" type="lrr:absoluteURI" use="required" />
              </xs:extension>
            </xs:simpleContent>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="attributes">
    <xs:annotation>
      <xs:documentation>Lists any attributes that are allowed or required.</xs:documentation>
    </xs:annotation>
    <xs:complexType>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
        <xs:element name="attribute">
          <xs:complexType>
            <xs:simpleContent>
              <xs:extension base="xs:NCName">
                <xs:attribute name="namespaceURI" type="lrr:absoluteURI" use="optional" />
                <xs:attribute name="use" type="lrr:useType" use="required"/>
              </xs:extension>
            </xs:simpleContent>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="versionOfXBRL" type="xs:token">
    <xs:annotation>
      <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:annotation>
  </xs:element>
  <xs:element name="minimumEditionDate" type="xs:date">
    <xs:annotation>
      <xs:documentation>The XBRL edition date and beyond for which this is an extension. </xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="impactsTaxonomyValidation" type="xs:boolean">
    <xs:annotation>
      <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:annotation>
  </xs:element>
  <xs:element name="impactsInstanceValidation">
    <xs:annotation>
      <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:annotation>
  </xs:element>
  <xs:element name="validation" type="lrr:DocumentationType">
    <xs:annotation>
      <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:annotation>
  </xs:element>
  <xs:element name="conformanceSuiteURI" type="lrr:absoluteURI">
    <xs:annotation>
      <xs:documentation>A URI locating a testcases element containing testcase elements with relative URIs to files illustrating valid and invalid usage.</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="requirement" type="lrr:DocumentationType">
    <xs:annotation>
      <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:annotation>
  </xs:element>
  <xs:element name="definition" type="lrr:DocumentationType">
    <xs:annotation>
      <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:annotation>
  </xs:element>
  <xs:element name="authoritativeHref" type="lrr:absoluteURI">
    <xs:annotation>
      <xs:documentation>The absolute URI where the schema defition of the role or arc role is found.</xs:documentation>
    </xs:annotation>
  </xs:element>
</xs:schema>
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/html" href="http://www.xbrl.org/2005/lrr2html.xsl"?>
<lrr:lrr xmlns:lrr="http://www.xbrl.org/2005/lrr" version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.xbrl.org/2005/lrr http://www.xbrl.org/2005/lrr-2005-04-15.xsd" xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <lrr:roles>
    <lrr:role>
      <lrr:roleURI>http://www.xbrl.org/2004/role/restatedLabel</lrr:roleURI>
      <lrr:status>IWD</lrr:status>
      <lrr:versionDate>2005-05-17</lrr:versionDate>
      <lrr:authoritativeHref>http://www.xbrl.org/2005/role/restatedLabel-2005-05-17.xsd#restatedLabel</lrr:authoritativeHref>
      <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:requirement>
      <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:elementsAllowedOn>
        <lrr:element namespaceURI="http://www.xbrl.org/2003/linkbase">label</lrr:element>
      </lrr:elementsAllowedOn>
      <lrr:versionOfXBRL>2.1</lrr:versionOfXBRL>
      <lrr:minimumEditionDate>2004-11-14</lrr:minimumEditionDate>
      <lrr:impactsTaxonomyValidation>false</lrr:impactsTaxonomyValidation>
      <lrr:impactsInstanceValidation>false</lrr:impactsInstanceValidation>
      <lrr:conformanceSuiteURI>http://www.xbrl.org/2005/conf/role/205-restatedLabel.xml</lrr:conformanceSuiteURI>
    </lrr:role>
  </lrr:roles>
  <lrr:arcroles>
    <lrr:arcrole>
      <lrr:roleURI>http://www.xbrl.org/2005/arcrole/expected-inconsistency</lrr:roleURI>
      <lrr:status>IWD</lrr:status>
      <lrr:versionDate>2005-05-17</lrr:versionDate>
      <lrr:authoritativeHref>http://www.xbrl.org/2005/arcrole/expected-inconsistency-2005-05-17.xsd#expected-inconsistency</lrr:authoritativeHref>
      <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:requirement>
      <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:definition>
      <lrr:elementsAllowedOn>
        <lrr:element namespaceURI="http://www.xbrl.org/2003/linkbase">footnoteLink</lrr:element>
      </lrr:elementsAllowedOn>
      <lrr:versionOfXBRL>2.1</lrr:versionOfXBRL>
      <lrr:minimumEditionDate>2004-11-14</lrr:minimumEditionDate>
      <lrr:impactsTaxonomyValidation>false</lrr:impactsTaxonomyValidation>
      <lrr:impactsInstanceValidation>false</lrr:impactsInstanceValidation>
      <lrr:conformanceSuiteURI>http://www.xbrl.org/2005/conf/arcrole/expected-inconsistency.xml</lrr:conformanceSuiteURI>
      <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:validation>
      <lrr:attributes>
        <lrr:attribute namespaceURI="http://www.xbrl.org/2003/instance" use="optional">importance</lrr:attribute>
      </lrr:attributes>
      <lrr:cyclesAllowed>undirected</lrr:cyclesAllowed>
      <lrr:sourceAbstract>prohibited</lrr:sourceAbstract>
      <lrr:targetAbstract>prohibited</lrr:targetAbstract>
    </lrr:arcrole>
  </lrr:arcroles>
</lrr:lrr>
C	References (non-normative)
The hyperlinks to HTML format XBRL International documents are to the non-normative versions of those document but are provided in this format for convenience. Those documents indicate the location of their relevant normative versions.
[CONF]	Walter Hamscher, Ron van Ardenne, Hugh Wallis	
	XBRL 2.1 Conformance Suite 1.0, Candidate Recommendation of 2004-04-25	
	http://www.xbrl.org/2005/XBRL-CONF-CR1-2005-04-25.htm 	
		
[FRTA]	Walter Hamscher (editor).	
	Financial Reporting Taxonomies Architecture 1.0 Recommendation dated 2005-04-25	
	http://www.xbrl.org/technical/guidance/FRTA-RECOMMENDATION-2005-04-25.htm 	
		
[ISO]	International Standards Organisation.	
	ISO 4217 Currency codes, ISO 639 Language codes, ISO 3166 Country codes, ISO 8601 international standard numeric date and time representations.	
	http://www.iso.ch/	
		
[RFC2119]	Scott Bradner	
	Key words for use in RFCs to Indicate Requirement Levels, March 1997	
	http://www.ietf.org/rfc/rfc2119.txt	
		
[XBRL]	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-04-25	
	http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-04-25.htm	
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 (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).
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 and Geoff Shuetrim (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 Josef MacDonald (IASCF) and vice chaired by Marc van Hilvoorde (PwC).  The XBRL International Specification working group is chaired by Paul Warren (DecisionSoft) and vice chaired by Cliff Binstock (UBmatrix). We also thank the following people for their comments and suggestions: Mark Goodhand (DecisionSoft), Charles Hoffman (UBmatrix), David Sheldon (DecisionSoft) and John Turner (CoreFiling).
I	Document History (non-normative)
Date	Editor	Summary	
2004-03-01	Hamscher	First draft of document prepared.	
2004-03-02	Wallis	Various updates, changes and comments added, including the definition of the normative status of roles in the LRR.	
2004-03-16	Hamscher	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.	
2004-07-22	Hamscher	Added fields indicating whether Abstract elements may be at the head and tail of an arc.	
2004-07-25	Hamscher	Edited the text to avoid remarks about grammar.	
2004-08-27	Wallis	Updated with input from the DWG F2F meeting in London	
2004-09-03	Hamscher	Updated figure and made formatting changes.	
2004-09-11	Hamscher	Updated figure and process to defer the requirement for two implementations until the CR phase, and to allow for multiple CRs.	
2004-11-06	Hamscher	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.	
2004-11-07	Hamscher	Added href, so that the role definition has an authoritative location; added conformance tests to the sample files.	
2005-01-22	Hamscher	Typographical corrections; prepared Candidate Recommendation.	
2005-02-15	Hamscher	Correction of normative file location to http://www.xbrl.org/2005/lrr	
2005-04-15	Hamscher	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.	
2005-04-23	Hamscher	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.	
2005-05-05	Hamscher	Updated references and acknowledgments.	
2005-05-05	Wallis	Updated to reflect Draft Candidate Recommendation and appropriate normative stati, corrected normative file locations to http://www.xbrl.org/lrr/lrr.{xml,xsd}.	
2005-05-17	Hamscher	Updated to reflect Candidate Recommendation 2 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 2005-05-17. 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 Candidate Recommendation 2.
A.	
K	Approval process (non‑normative)
This section will be removed from the final recommendation.  WG = Specification Working Group; ISC = International Steering Committee.
Final recommendation of this specification requires at a minimum of two working independent and interoperable implementations, to be confirmed using a conformance suite that exercises the ability of FRTA validation tools to distinguish between registered and unregistered roles.
	Stage
(* - Current)	Party responsible for decision	Decision	Revisions needed	Target date for decision	
1	Internal WD	WG 	Recommend for Stage 2	Stay in Stage 1	2004-11-08	
2	Internal WD pending publication	ISC	Approve for Stage 3	Return to Stage 1	2004-11-14	
3	Public WD under 45 day review	WD Editors	Minor revisions – to Stage 4	Major revisions, Restart Stage 1	2004-12-31	
4	Draft Candidate Recommendation 1	WG	Recommend for Stage 5	Restart Stage 3	2005-01-22	
5*	Candidate Recommendation 1	ISC	Approve for Stage 6	Restart Stage 4	2005-02-15	
6	Draft Candidate Recommendation 2	WG	Recommend for Stage 7		2005-05-12	
7	Candidate Recommendation 2	ISC	Approve for Stage 8		2005-05-17	
8	Recommendation	ISC	Finalise		2005-06-21