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.
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.
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.
|
|
|
CR
|
Candidate Recommendation
|
|
DCR
|
Draft Candidate Recommendation
|
|
DWG
|
Domain Working Group
|
|
FRTA
|
Financial Reporting Taxonomy Architecture
|
|
ISC
|
International Steering Committee
|
|
IWD
|
Internal Working Draft
|
|
LRR
|
Link Role Registry
|
|
LRRAG
|
LRR Advisory Group
|
|
PWD
|
Public Working Draft
|
|
SWG
|
Specification Working Group
|
|
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:
Italics are used for rhetorical emphasis only and
do not convey any special normative meaning.
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.
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
|
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 Location
|
URI
|
URI of fragment in a 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.
|
|
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>
|
|
Version of XBRL
|
Token
|
The XBRL version for which this an extension. Note that a
role could be “promoted” into a standard role in some future version of the
specification.
|
2.1
|
|
Minimum 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 on extended links 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 on extended links 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
|
A URI locating a conformance suite
illustrating valid and invalid usage. Only required if additional validation
is specified.
|
http://www.example.com/xbrl/LRR/test/requires-cEqual-element.xml
The URI need not have www.xbrl.org as its host part.
|
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.
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/2006-02-21/lrr.xml).
This is analogous to the archival convention for specification schemas.
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
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/2006-02-21/lrr.xsd
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.
<?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: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: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: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:sequence>
<xs:any
processContents="lax" namespace="##other"
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="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="xs:anyURI">
<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="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="xs:anyURI"
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="xs:anyURI">
<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="xs:anyURI">
<xs:annotation>
<xs:documentation>The URI where the schema defition of the role or arc
role is found.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:schema>
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="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.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>2006-02-21</lrr:versionDate>
<lrr:authoritativeHref>role/restatedLabel.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:versionOfXBRL>2.1</lrr:versionOfXBRL>
<lrr:minimumEditionDate>2004-11-14</lrr:minimumEditionDate>
<lrr:impactsTaxonomyValidation>false</lrr:impactsTaxonomyValidation>
<lrr:impactsInstanceValidation>false</lrr:impactsInstanceValidation>
</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>2006-02-21</lrr:versionDate>
<lrr:authoritativeHref>arcrole/expected-inconsistency.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:versionOfXBRL>2.1</lrr:versionOfXBRL>
<lrr:minimumEditionDate>2004-11-14</lrr:minimumEditionDate>
<lrr:impactsTaxonomyValidation>false</lrr:impactsTaxonomyValidation>
<lrr:impactsInstanceValidation>false</lrr:impactsInstanceValidation>
<lrr:conformanceSuiteURI>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: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 documents 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 2 of 2005-11-07
|
|
|
http://www.xbrl.org/2005/XBRL-CONF-CR2-2005-11-07.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-11-07
|
|
|
http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-11-07.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).
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).
|
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 statuses, corrected normative file locations to
http://www.xbrl.org/lrr/lrr.{xml,xsd}.
|
|
2005-05-17
|
Hamscher
|
Updated to reflect Candidate Recommendation 2 status.
|
|
2005-07-13
|
Sheldon
|
Use standard XBRL roleRef and arcroleRef elements. Remove
duplication from the dataset, and remove requirement for absolute URIs.
|
|
2005-07-29
|
Sheldon
|
Went back to using roleURI rather than roleRef and
arcroleRef elements. Rephrased absolute URI discussion, and only require
conformanceSuite if there is additional validation.
|
|
2005-07-30
|
Hamscher
|
Edits to approval process explanation, and update to the
approval process timeline.
|
|
2005-08-11
|
Hamscher
|
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.
|
|
2005-12-11
|
Hamscher
|
Edited schema to allow for any other elements to appear in
a role or arcrole entry. Revised target dates.
|
|
2006-01-05
|
Wallis
|
Minor correction to lrr.xsd schema – editorial for
Candidate Recommendation 4 publication
|
|
2006-02-21
|
Wallis
|
Editorial to reflect RECOMMENDATION Status
|
|
|
|
|
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.