Linkbase Role Registry 1.0

Candidate Recommendation 2 of 2005-05-17

This version:

            XBRL-LRR-CR2-2005-05-17.htm

 

is a NON-NORMATIVE version of the Specification. The NORMATIVE version will be found at http://www.xbrl.org/lrr/XBRL-LRR-CR2-2005-05-17.rtf.

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. 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 XBRL.org website. 5

5      Criteria. 6

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) 12

C      References (non-normative) 13

G      Intellectual Property Status (non-normative) 14

H      Acknowledgements (non-normative) 14

I       Document History (non-normative) 14

J       Errata corrections incorporated in this document 15

K      Approval process (non‑normative) 16

 

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 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-elementxml

 

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


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://wwwxbrl.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.


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