LRR 1.0 Conformance Suite

Public Working Draft of 2005-06-21

Corresponding to LRR (Link Role Registry) 1.0 Candidate Recommendation 2 of 2005-05-17

This document:


is non-normative. The normative version will be found in the file


Source files:

Unzip the latter into file:///c:/temp/conf to create a directory hierarchy.  Open the file file:///c:/temp/conf/lrr/conf/index.xml in a browser.  This yields a hypertext navigable tree view of test set lists, and a test list in each set of tests (the absolute location file:///c:/temp/conf is used because the LRR requires an absolute URI as an authoritative location for all registered roles).





Walter Hamscher

Standard Advantage /

Consultant to PricewaterhouseCoopers

Hugh Wallis

XBRL International


This document describes a set of conformance tests for processors that check conformance of XBRL documents to the FRTA [FRTA] or FRIS [FRIS] and which, in doing so, check whether linkbase roles and arc roles that are not defined by the XBRL specification [XBRL] have been registered in the XBRL Link Role Registry [LRR].

Status of this document

This is a Public Working Draft whose circulation is unlimited. It was approved for publication by the International Steering Committee on 2005-06-21. Recipients of this document are invited to submit comments to the editor, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Table of contents

Editor i

Abstract i

Status of this document i

Table of contents. ii

1     Introduction. 1

1.1     Purpose  1

1.2     Scope  1

1.3     Terminology  1

1.4     Documentation conventions 2

2     Changes from the previous recommendation. 2

3     Overview of the tests. 2

4     Technical details. 3

4.1     Directory Structure  3

4.2     Authoritative Locations of Test roles 3

4.3     Testing coverage  4

4.4     Structure and content of test case files 4

4.5     To report errors in the test cases 4

4.6     How to submit tests 4

A     References (non-normative). 5

B     Intellectual property status (non‑normative). 5

C     Document history and acknowledgments (non-normative). 6

D     Errata corrections incorporated in this document 6

E     Approval process (non‑normative). 7


1         Introduction

The Link Role Registry ([LRR]) is an online listing of XLink role and arc role attribute values that may appear in XBRL International acknowledged and approved taxonomies, along with structured information about their purpose, usage, and any intended impact on XBRL instance validation.

The Financial Reporting Taxonomies Architecture 1.0 document ([FRTA]) documents the recommended architecture for taxonomies designed for the purpose of Financial Reporting. It establishes rules and conventions that assist in comprehension, usage and performance among different financial reporting taxonomies.  FRTA 1.0 rules 3.1.2, 3.1.3 mandate (and 3.1.11 advises) which elements may only have roles and arc roles that are defined either in XBRL or appear in the LRR.

The Financial Reporting Instance Standards [FRIS] aim to facilitate the analysis and comparison of XBRL financial reporting data by computer applications and human readers.  FRIS 1.0 PWD rules 2.9.2 and 2.9.3 mandate that footnote related elements appearing in instances may only have roles and arc roles defined either in XBRL or appearing in the LRR.

This document describes the normative conformance suite for processors that claim to check XBRL documents for compliance with [FRTA] or with [FRIS], and that additionally are able to access the XBRL International normative LRR, a private LRR, or a local copy of a published LRR.  Such processors are LRR-enabled Compliance Processors.

1.1        Purpose

The purpose of the conformance suite is to facilitate consistency among LRR-enabled Compliance Processors.  The conformance suite is normative in the same sense that the LRR specification [LRR] is normative. An application is an LRR-enabled Compliance Processor if and only if it passes all of the conformance suite tests.  That is, processors MUST correctly identify compliance or lack thereof with the LRR related rules in FRTA and/or FRIS.

1.2        Scope

Testing of applications that consume XBRL instances and the taxonomies used by those instances is included in the scope of this conformance suite.

Testing of applications that produce XBRL taxonomies is not within the scope of this conformance suite.

[XBRL], [FRTA] and [FRIS] are in scope. Other work products of XBRL International, whether public or internal, are not in scope.

1.3        Terminology

The terminology used in XBRL frequently overlaps with terminology from other fields, and the following list is provided to reduce the possibility of ambiguity and confusion.  For definitions of the following terms see the XBRL 2.1 Specification [XBRL].

·         abstract element, alias concept, alias item, c‑equal, child, parent, sibling, grandparent, uncle, ancestor, concept, concrete element, CWA, duplicate items, duplicate tuples, element, entity, error, essence concept, essence item, fatal error, instance namespace, item, least common ancestor, linkbase namespace, must, must not, required, shall, shall not, should, should not, may, optionaL, non-numeric item, numeric item, period, p‑equal, s‑equal, taxonomy, tuple, u-equal, v‑equal, XBRL instance, x‑equal.

For definitions of the following terms see [FRTA]:

·         DTS, base DTS, extension DTS, extended-type link, FRTA, GAAP, LRR, source, target, taxonomy status (acknowledged, approved, recommended), version control.

For definitions of the following terms see [LRR]:

·         LRRAG.

Unless indicated otherwise, references to ‘XBRL’ and ‘the specification’ in this document mean ‘XBRL 2.1’ and ‘the XBRL 2.1 specification recommendation’, respectively.  Unless indicated otherwise, references to ‘FRTA’ in this document mean ‘FRTA 1.0’.  Unless indicated otherwise, references to ‘LRR’ in this document mean ‘LRR 1.0’.

1.4        Documentation conventions

The following highlighting is used to present literal code fragments:


The following highlighting is used for non-normative examples:


Non-normative editorial comments are denoted as follows, and will be removed from the final recommendation:

WcH: 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.

2         Changes from the previous recommendation

There has been no previous recommendation, hence no changes.

3         Overview of the tests

The structure of the test suite is the same as that of the FRTA conformance suite [CONF].  Sets of files are organised into individual “variants” in a list comprising a “test case” and then the test cases are organised into a list.  XML files are used to represent the individual tests and relationships among the files.

Implementers develop their own test harness, which uses these XML files to successively apply their processor to each set of files thus described and compare the result to the expected output.  In each case the input may either be valid or invalid, and the test harness produces a report showing the pass/fail status of the implementation on each test.  In general, a test harness does not stop at its first mismatch or failure, but attempts to perform all of the tests.

The two main sets of tests are the linkbase and the footnote tests.  The objectives of each are described at a high level in this document.

To see the tests themselves, unzip the package and open file:///c:/temp/conf/lrr/conf/index.xml in a browser.  In general each test may have zero or more of these different types of file:

·         Instance: CamelCase style file name, suffix .xbrl;

·         Schema: CamelCase style file name, suffix .xsd;

·         Linkbase: CamelCase style file name, suffix .xml;

A numbering scheme that extends that used in [CONF] organises the test sets and variations as detailed below.

4         Technical details

4.1        Directory Structure

The conformance suite has a hierarchical tree structure.  The structure segregates tests in to sections for comprehensibility.  It provides an individual subdirectory for each test case in which the test case summary file is provided and all files for all variations of each test case:


·         300-Relationships – tests relating to the rules about relationships in [FRTA] chapter 3 and in [FRIS] chapter 2; these are the only rules that mention the LRR.

·         lib – the directory where the core XBRL and supporting schemas are found.  Other than the XBRL schema files themselves, the files are:

o        lrr-2005-05-06.xml – a special lrr file containing declarations of two roles and two arc roles used in all the LRR tests.

o        lrr-conf-2005-05-06.xsd – a small taxonomy consisting of only two elements in namespace, “Castor” and “Pollux,” used in all the LRR tests.

o        lrr-conf-2005-05-06-label.xml – an XBRL label linkbase for the items Castor and Pollux, which appears only so that no unwanted and irrelevant FRTA conformance violations appear.

Test cases themselves have their own subdirectory and are located within a parent subdirectory, viz. 300-Relationships.  Subdirectory names are a concatenation of the test ID number and a human readable name.  For example, all the files related to test case with ID “T-377”, which has a name “ElementID”, are in the subdirectory “377-ElementID”.

4.2        Authoritative Locations of Test roles

Normally, each role (or set of related roles) is defined in an XBRL Taxonomy Schema file hosted appears at an authoritative location on the web.  However, the LRR conformance suite must be usable in standalone mode, in particular, before the LRR on the XBRL web site goes live.  The test roles are defined in these two locations so as to mimic the way in which they would be published on the web site:



4.3        Testing coverage

In the FRTA conformance suite [CONF] there are two test cases that cover the FRTA rules governing the LRR (rules 3.1.2 and 3.1.3).  These tests (variations 302 and 303) assume that because any role or arc role that is used must be declared using roleType or arcroleType elements, that the converse is true, that is, the tests assume that any role ore arc role that is declared is also used.  The wording of the 2005-04-25 edition of FRTA 1.0 could be interpreted to mean that taxonomies only violate the rule if a non-LRR role or arc role is used.  But given the assumption, which is a reasonable one in practice, it is only necessary for a FRTA compliance processor to test whether a role or arc role is declared. 

The tests in this, the LRR conformance suite, do not rely on this assumption and instead simply cover all of the different elements where roles and arc roles registered in the LRR may appear.  The LRR tests cover roles and arc roles appearing both in taxonomy linkbases and in instances.  Roles or arc roles can appear on nine role and arc elements and there are two tests for each element giving a total of 18 tests.


Role in LRR

Role not in LRR

Arcrole in LRR

Arcrole not in LRR














































4.4        Structure and content of test case files

The naming scheme, structure and details of the test case files is the same as that of the FRTA conformance suite, but there are no ptvi output files.

4.5        To report errors in the test cases

Errors in the test cases can be reported to the XBRL-FRTA-Conformance mailing list by XBRL International members, or to one of the editors or authors of the document.

4.6        How to submit tests

To submit new or updated test cases or variations, you will need to be an XBRL International member with access to the CVS repository where the Conformance suite is stored. If you wish to submit tests please contact the editor or one of the editors or authors of this document.

A        References (non-normative)

The URL of the non-normative web versions of the documents is listed for convenience.



Hugh Wallis (editor)


Financial Reporting Taxonomies Architecture 1.0 Conformance Suite  




Mark Goodhand, Walter Hamscher (editors)


Financial Reporting Instance Standards 1.0 Public Working Draft dated 2004‑11‑14.




Walter Hamscher (editor)


Financial Reporting Taxonomies Architecture 1.0, Recommendation.




Walter Hamscher (editor), Hugh Wallis


Link Role Registry 1.0, Candidate Recommendation 2 dated 2005-05-17.




World Wide Web Consortium. 


XML Schema Part 0: Primer.




World Wide Web Consortium. 


XML Schema Part 1: Structures.




World Wide Web Consortium. 


XML Schema Part 2: Datatypes




Philip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon and Hugh Wallis


Extensible Business Reporting Language (XBRL) 2.1 Specification, with corrected errata dated 2004-04-25.

B        Intellectual property status (non‑normative)

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


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 (

C        Document history and acknowledgments (non-normative)

This conformance suite was reviewed by the participants of the XBRL Specification Working Group. The XBRL International Specification Working Group is chaired by Paul Warren (DecisionSoft) and vice chaired by Cliff Binstock (UBmatrix).






First draft of document prepared and distributed.



Added note to contrast the test coverage of the LRR suite to the test coverage in the FRTA suite.



Updated to reflect Internal Working Draft status.



Updated to reflect Public Working Draft status. Updated dates in the approval process section.

D        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 XBRL International Specification Working Group up to and including 2005-06-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 SWG

Because this is a Public Working Draft, there are no errata at this time.

E        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.



(* - Current)

Party responsible for decision


Revisions needed

Target date for end of stage


Internal WD


Recommend for Stage 2

Stay in Stage 1



Internal WD pending publication


Approve for Stage 3

Return to Stage 1



* Public WD

WD Editors

Minor revisions – to Stage 4

Major revisions, Restart Stage 1



Draft Candidate Recommendation


Recommend for Stage 5

Restart Stage 3



Candidate Recommendation


Approve for Stage 6

Restart Stage 4