1 Introduction

XBRL International specifies this architecture to enhance consistency among the XBRL taxonomies used for financial reporting. An important design goal for financial reporting taxonomies is to maximise the usability of the taxonomy to the non-technical (from a computer science perspective) users and experts of the reporting domain, while not compromising the ability of the taxonomy to describe reporting requirements and possibilities in an accurate and XBRL-compliant manner. Where these goals conflict, the architecture is biased in favour of comprehensibility over implementation ease for software designed to support the architecture. The financial reporting taxonomy architecture addresses several areas of consistency:

· Representation: Taxonomies should use similar XBRL structures to represent similar relationships among concepts. For example, financial reporting concepts that are measured the same, aggregated the same, and disclosed the same are represented using the same shared XBRL element. Distinctions such as period, entity, or units that are meant to be captured using XBRL contexts are not reflected in the taxonomy itself. The different levels of equivalency allowed within the architecture are a critical aspect of its design.

· Modularity: Taxonomies should have a common approach to grouping taxonomy content at a file level. For example, language-specific labels and references are placed in separate linkbase files; jurisdiction-specific references are placed in separate linkbase files; sets of logically related elements that are unlikely to change separately are placed in the same schema files.

· Evolution: Taxonomies built to the architecture set out in this document can be extended or revised using similar approaches.

Consistency among financial reporting taxonomies is important because lack of consistency may lead to additional effort being required to consume, use, compare and extend financial facts reported using these taxonomies.

Taxonomies are meant to be long-lived and broadly used across a business reporting supply-chain. In practice this means they are developed in collaboration among several parties. In recognition of this, the needs of those reviewing and maintaining the financial reporting taxonomies have also influenced this document.

1.1 Scope of the architecture

In this document, “financial reporting” encompasses authoritative financial reporting standards and financial reporting best practices (or GAAP), regulatory reports whose subject matter is primarily financial position and performance including related explanatory disclosures, and data sets used in the collection of financial statistics; it excludes transaction- or journal-level reporting, primarily narrative reports (for example, internal controls assessments) and non-financial quantitative reports (for example, air pollution measurements).

This architecture is NOT itself a set of financial reporting standards. For example, FAS and IFRS are financial reporting standards. FRTA—the Financial Reporting Taxonomy Architecture—provides the means by which disclosures made pursuant to those financial reporting standards, GAAP, and so forth can be captured using XBRL. This architecture improves the consistency with which such standards are expressed in the XBRL financial reports that are based on them. The architecture does NOT require that preparers of XBRL instances disclose any more information than they currently do in a non-XBRL environment.

1.2 Relationship to other work

This financial reporting taxonomy architecture assumes XBRL 2.1 [XBRL]. Parts of this document reiterate for expository clarity certain syntactic and semantic restrictions imposed by the XBRL Specification, but this document does not modify the XBRL Specification. In the event of any conflicts between this document and the XBRL 2.1 Specification, the XBRL 2.1 Specification prevails. This document does place additional restrictions above and beyond those prescribed by the XBRL Specification. The purpose of these additional restrictions is to maximize XBRL instance comparability of external financial reports where a large number of extension taxonomies are expected.

The IFRS and USFR taxonomy frameworks [IFRS] [USFR] will provide examples of this architecture once they have achieved Approved status [TRP]. In the event of any conflict between this document and any current version of IFRS and USFR taxonomy frameworks, this document prevails.

1.3 Goals of this document

A financial reporting taxonomy or extension of the USFR or IFRS taxonomy that receives Approved status from XBRL International must conform to this architecture. This document is normative with respect to such taxonomies. The architecture must be used during XBRL International’s review of taxonomies that are candidates for Approved status [TRP]. All parts of this document not explicitly identified as non-normative are normative.

This document should be used by taxonomy developers, that is, those who already have some familiarity with XBRL usage, syntax and semantics and who are contributing to or responsible for a financial reporting taxonomy, either with:

· financial reporting domain expertise and previous exposure to XBRL technology, or

· XBRL software expertise and previous exposure to financial reporting concepts.

This document may also be useful to:

1. Taxonomy developers creating a financial reporting taxonomy who wishes to follow a broadly used set of practices;

2. Taxonomy developers wishing to create a company-specific extension taxonomy to support their financial statements using XBRL using custom concepts and relationships; and

3. Application developers who support development or use taxonomies that meet the requirements set out in this document.

No part of this architecture requires any aspect of a taxonomy to have an English translation. Any rule which depends on a feature present in English but not in another language, may be ignored for taxonomy content in that other language.

1.4 Organisation of this document

This document describes the architecture in layers from the bottom up. Overall, the architecture comprises:

1. a Concept layer describing rules governing XBRL representation structures such as elements, concepts, and links;

2. a Relationship layer describing rules of link usage and how relationships are captured using link types such as definition, calculation and presentation;

3. a Discoverable Taxonomy Set layer defining the rules of the organisation of individual files to form discoverable taxonomy sets; and

4. an Extensions layer dealing with rules by which taxonomy extensions are to be created and general principles governing modularity.

XBRL is implicitly a part of this architecture although much of what is covered in the XBRL Specification is not repeated in this document. XML Schema and XML Linking Language are also implicitly part of the architecture because they are building blocks for XBRL, however they are not covered explicitly in this document either.

Example 1. Layers of the FR taxonomy architecture.

Many taxonomy development errors result from a lack of understanding the consequences for XBRL instances; hence there are examples and discussion relating to instances even though that is not the focus of this document.

1.5 Terminology and document conventions

Terminology used in XBRL frequently overlaps with terminology from other fields.

Table 1. Terminology used in this document.

Architecture

“The fundamental organization of a system embodied by its components, their relationships to each other and to the environment and the principles guiding its design and evolution. This definition may just as usefully be applied to technical architecture” [IEEE].

This document describes in the form of design rules the organization of financial reporting taxonomies embodied by schemas, linkbases, concepts, links, and other components, their relationships to each other and to financial reporting standards, and principles that justify the design rules both for base taxonomies and for the extensions that will inevitably follow.

Contrast this with the IEEE definition of Software Engineering: “A systematic approach to developing, using, maintaining and liquidating systems;” this document does not cover approaches to development, use, maintenance or liquidation of taxonomies.

abstract element, ancestor, base set, bind, child, concept, concrete element, context, duplicate items, duplicate tuples, element, entity, essence concept, fact, fully conforming, grandparent, instance, item, least common ancestor, linkbase, minimally conforming, parent, period, sibling, taxonomy, taxonomy schema, tuple, uncle, unit

As defined in XBRL 2.1 specification.

must, must not, required, shall, shall not, should, should not, may, optional

See [RFC2119] 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.

DTS

Discoverable Taxonomy Set As defined in XBRL 2.1 specification.

base DTS

extension DTS

An extension DTS is a DTS that is a proper superset of a base DTS. Because an extension must be a proper superset, a DTS is not an extension of itself.

extended-type link

As defined by the XML Linking Language [XLINK]. XBRL linkbases are made up of extended-type links.

FRTA

Financial Reporting Taxonomies Architecture: the set of rules described in this document.

FRTA compliant (FRTA-compliant)

An element, attribute, linkbase, schema or DTS satisfying all applicable mandatory (“must”) rules in this document. Any of such artefacts that violates or ignores a recommended (“should”) rule is inferior to one that obeys it and should not be emulated.

GAAP

Generally Accepted Accounting Practice‌/‌Principles: Term used to describe broadly the body of principles that governs the accounting for financial transactions underlying the preparation of a set of financial statements. Generally accepted principles are derived from a variety of sources, including promulgations of accounting standards boards, together with the general body of accounting literature consisting of textbooks, articles, papers, common practices, etc. [LLLL]

LRR

Link Role Registry. 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 [LRR].

Module

An XBRL International recommendation that depends on XBRL and defines the syntax and semantics of additional elements, attributes, roles or arc roles that cannot be defined entirely within an XBRL valid taxonomy.

Persisting DTS (persisting extension)

A DTS whose purpose is to be stored as files to be referenced by instances of multiple entities and published in some fashion for users to examine. This contrasts with a DTS that is ephemeral—for example, dynamically created while processing instances, only to be discarded.

source

The source of an arc is the element indicated by the “from” attribute.

target

The target of an arc is the element indicated by the “to” attribute.

Taxonomy status:

Acknowledged

Approved

Recommended

This is non‑normative; see the Taxonomy Recognition Process [TRP]:

Acknowledged: XBRL International recognizes that the taxonomy is technically in compliance with all appropriate specifications.

Approved: In addition to being Acknowledged, XBRL International warrants that the taxonomy was developed in an open fashion and it complies with all best practices for compatibility.

Recommended: In addition to being approved, XBRL International singles out a Recommended taxonomy as being the one preferred for a given type of reporting. Financial reporting taxonomies are not expected to achieve this status from XBRL International since it is not the custodian of the financial reporting standards themselves.

version control

A version control system maintains an organized set of all the versions of files that are made over time. Version control systems allow people to go back to previous revisions of individual files, and to compare any two revisions to view the changes between them.

XBRL

XBRL 2.1 Recommendation, with corrected errata to 2005-04-25 [XBRL].

XBRL valid

XML instances and schemas that satisfy the syntax requirements of XBRL.

The following highlighting is used for non-normative examples in this document:

The following highlighting is used for non-normative counterexamples in this document:

Non-normative editorial comments are denoted as follows and removed from final recommendations:

WcH: This highlighting indicates 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.

Figure 1 illustrates drawing conventions followed in figures showing taxonomy fragments and taxonomies.

Figure 1. Legend of drawing conventions for taxonomy fragments.

Figure 2. Legend of taxonomy schema and Linkbase drawing conventions.

The following table summarizes the notation used in the diagrams of this document.

Table 2. Drawing notations in this document.

	A “from-to” arc from a source element (end of line with no arrow), to a target element (end of line with arrow).
	A concept element
	An extended-type link element
	Taxonomy schema
	Linkbase
	Discoverable taxonomy set
summation-item	summation-item arc role
weight = +1	Weight of 1 relative to parent (on summation-item arc)
parent-child	parent-child arc role
essence-alias	essence-alias arc role
documentation	documentation role
terseLabel	Label link, terse role
lang = en	xml:lang attribute value “en”
…	Abbreviation for http://www.xbrl.org/2003
…/role/this	xlink:role attribute value “http://www.xbrl.org/2003/role/this”
…/arcrole/that	xlink:arcrole attribute value “http://www.xbrl.org/2003/arcrole/that”

2 Concept Layer

In a syntactic sense, a concept is an XML Schema element definition, defining the element to be in the item element substitution group or in the tuple element substitution group. At a semantic level, a concept is a definition of kind of fact that can be reported about the activities or nature of a business entity. Taxonomies contain XBRL concepts represented by XML Schema element definitions. Concepts are meant to represent a type of fact, that is, data. The presentation of the concept in any given situation is described by other XBRL constructs, and that distinction between data and presentation is fundamental to XBRL.

2.1 Rules for all concepts

The rules covering concepts apply to items and to tuples.

Abstract concepts are concepts (elements in the item or tuple substitution group) having their XML Schema abstract attribute equal to true. Abstract concepts cannot be used in XBRL instances. Their role is limited to organisation (grouping) of other concepts defined in taxonomies. All rules applying to concepts apply also to abstract concepts unless otherwise indicated.

2.1.1 A taxonomy schema must define only one concept for each separately defined class of facts.

Having one concept per definition of how a class of facts is to be measured simplifies applications that must extract, compare and combine information from XBRL instances. Two facts fall into the same “class” in this sense if for any context the two values would always be the same in an instance. For example, “Cash Balance in Bank” would, theoretically, have only one element to express this concept, and XBRL instances would use different contexts to report the value for this element for different periods, different entities, etc. Similarly, concepts that have multiple uses within financial reporting (for example, in primary financial statements and in explanatory notes to financial statements) must be defined only once.

The uniqueness requirement only applies to sets of concepts defined within a single taxonomy schema and does not extend to discoverable taxonomy sets. Where duplicate concepts are identified, taxonomy authors should recognise such equivalencies using essence-alias relationships in definition extended-type links. For rules governing these relationships see chapter 4, “Discoverable taxonomy set layer” and chapter 5, “Taxonomy Extensions”.

The equivalency of two concepts must be assessed at the semantic level, by comparing the set of possible values that are valid to report using the syntax for those concepts. This requires a comparison of the labels, references and inter-concept relationships associated with the two concepts in the linkbases.

Example 2. Identical concepts.

Concept	Concept	Explanation
Net Profit	Net Loss	These are not distinct concepts because an entity cannot have both a profit and loss in the same period. Concepts such as NetProfit and NetLoss are redundant and should be represented a single element such as NetProfitLoss.

Example 3. Distinct concepts.

Concept	Related but distinct concept	Explanation
Cash Balance	Change in Cash Balance	The first concept is the amount of cash at a specific instant; the other is the change in the cash balance between one instant and another.
Revenue	Change in Revenue Ratio	The first concept is the amount of revenue over a period of time, and the other is the change in revenue between one period of time to another period of time expressed as a ratio.
Inventory (measured using the LIFO or FIFO method)	LIFO Inventory	The 2^nd concept is measured using the LIFO method only.
	FIFO Inventory	The 2^nd concept is measured using the FIFO method only.
	Inventory Measurement Policy	Text describing how the inventory is measured.
Trade Receivables, Net	Trade Receivables, Gross	These concepts are different because they are calculated differently; one nets out “Allowances for Bad Debts” and the other does not.
Deferred Tax Assets	Deferred Tax Liabilities	These concepts are distinct because they are disclosed separately; that is, unlike net income which can only be a profit or loss, an entity may have both deferred tax assets and liabilities that do not offset.

Equivalence of concepts is affected by four factors affecting the set of valid values for a concept: measurement, aggregation, materiality, and disclosure. These are discussed below and should be taken into account when determining whether two concepts are duplicates. Naturally, concepts should be examined on a case-by-case basis to determine appropriate modelling in the specific situation.

2.1.1.1 Measurement

Concepts that are measured differently MAY be represented by a single concept if that concept has a broad enough definition provided by its labels and references and by its calculation and definition extended-type link relationships to other concepts.

For example, LIFO and FIFO inventory both value inventory, but are measured differently. An inventory concept that allowed both measurement approaches could validly be defined to contain inventory facts measured using either approach.

In contrast an inventory concept that only allowed measurement using one approach should not be used to contain inventory facts measured using the other approach.

2.1.1.2 Aggregation

Concepts that are aggregated or calculated the same way MAY be equivalent and represented by a single concept.

Concepts MAY also be considered equivalent even if their values are calculated slightly differently, so long as their underlying definitions permit both kinds of calculations. However, in general, the calculation relationships describing how the values for one concept can be derived from the values of others provide a good guide to concept equivalencies: if they are calculated differently they are probably distinct.

Aggregation can also be a good guide to concept identification for non-numeric concepts. For example, notes can be provided as a single block of text or they can be provided as a series of separate facts whose text values can be combined to constitute the combined value of the non-numeric concept with the broader, more aggregated definition.

For example, a concept could be defined to validly contain a comprehensive description of all accounting policies. Alternatively a set of concepts could be defined so that each can only validly contain text about a particular kind of accounting policy. Depending on the granularity of reporting that specific instances are intended to achieve, either the aggregated single concept or the disaggregated set of concepts could appear in an instance.

To allow different levels of granularity in reporting, taxonomies MAY define both the single concept and the set of concepts and MAY represent the associations between the aggregate concept and the disaggregated concepts using presentation extended-type link parent-child relationships.

2.1.1.3 Materiality

Materiality guidelines generally call for disaggregating reported items down to some relative materiality, which differs from entity to entity depending on factors such as management discretion. For example, “Cash” under some standards includes postage stamps and under others do not, but it is unlikely in the general case that the total “Cash” amount disclosed would be materially different; hence these MAY be modelled as the same concept in an XBRL taxonomy so long as the underlying definition of the concept accommodates both approaches to measurement.

2.1.1.4 Disclosure

Reporting standards frequently mandate qualitative disclosures that nevertheless do not warrant separate XBRL items. For example, an “Inventory” monetary figure must be disclosed, but it may be neither necessary nor desirable to have different inventory items to distinguish every possible distinction (for example, perishable vs. durable). Such disclosures can be made in a text description provided with a separate concept.

XBRL does not provide an extended-type link relation between the numeric item and the non-numeric item that provides textual detail. The distinctions that can be captured in the disclosure description (text) concept must not be part of the concept definitions determining valid values for the concept whose disclosure is being described in additional detail. Returning to the Inventory example above, define either (a) an Inventory item and an Inventory Policy item, or (b) a LIFO Inventory and FIFO Inventory item, but not both (a) and (b).

2.1.2 Contextual and measurement information in XBRL instances must not result in different elements in a taxonomy.

For example, a concept definition must not specify that the concept is only to be used for facts about company XYZ or for facts that are true as at the end of a financial year.

XBRL instances contain facts that are instances of concepts. Facts can contain content values that should meet the semantic requirements associated with the concepts that they are instances of. Besides the value of a fact, such as “the value of cash is 500,000”, the XBRL instance provides contextual information necessary to correctly interpret each fact. This context includes:

· the entity that the value of the fact describes;

· a period for which or over which the fact is true; and

· the scenario under which the value of the fact has been measured.

Because only facts have a period associated with them, there is no such thing as “the period over which a concept applies.” Hence (for example) “cash,” “cash at the beginning of a period,” and “cash at the end of a period” are not distinct concepts. There is only one concept in this case: cash, and it is measured at an instant.

For numeric facts, XBRL instances also provide information relating to measurement accuracy and measurement units.

2.1.3 Concepts’ meanings must not depend on their position within an instance.

A single item or tuple can appear within many different tuples because all items and tuples are defined globally. For example, the item Residuals may appear within different tuples only if it has the same meaning in both places. Therefore, if one tuple relates to payments received for each rerun after an initial showing of a TV show, while another tuple relates to the value of oil not yet extracted from beneath leased property, two different items (for example, TelevisionResiduals and OilResiduals) should be defined.

An additional reason to distinguish between TelevisionResiduals and OilResiduals in this example is that the distinction is useful should the Oil and Television tuples happen to be siblings in an instance. If both concepts had been represented by the same element (Residuals), then it would not be possible to define a calculation for the value of TotalOilResiduals as the sum of all Residuals. The interaction between calculation arcs and tuples is discussed further in section 3.3.4 below.

2.1.4 Concept names should adhere to the LC3 convention.

LC3 means Label CamelCase Concatenation (LC3). LC3 rules require that:

1. Element names must be based on an appropriate presentation label for the element. A label should be a natural language expression that is meaningful to experts in the domain covered by a taxonomy (for example, “Revaluo Propio”, “Restatement of Fixed Assets”), for a given item.

2. If multiple labels exist for a concept, then any one of those labels MAY be used as the basis for construction of the element name. Furthermore, if the element name is originally based on a label and in a subsequent version of the taxonomy the label changes, the element name must not be changed merely to maintain agreement.

3. The first character of the element name must not be underscore (_); this leaves only letters (as defined in XML) as valid first characters.

4. The first character of the element name must be capitalised.

5. Connective words in the label may be omitted from the element name to make names shorter. Examples of English connective words include (but are not limited to) the following:

· the, and, for, which, of, a

6. As a consequence of XML element name restrictions, all special characters must be omitted from the element name. Special characters include the following:

( ) * + [ ] ? \ / ^ { } | @ # % ^ = ~ ` “ ‘ ; : , < > & $ ₤ €

7. Element names must be limited to 256 characters or fewer.

8. Words in a label from which an element name is derived may be abbreviated when used in the element name. A list of standard abbreviations and rules for substitution (for example, “Property Plant and Equipment” in a label is always replaced by “PPE” in the element name) should be maintained by the taxonomy author(s). When standard abbreviations are used, they should be applied consistently throughout the taxonomy.

9. If two or more elements share the same element name and the element name is less that 256 characters long, then uniqueness may be accomplished by one of the following means:

· appending a distinguishing suffix;

· adding a distinguishing prefix;

· appending the first duplicate name with a number suffix, beginning with 1 and incrementing by 1 for each element with a common name.

The distinguishing suffix or prefix may be derived from the label of one or more ancestor elements. If two or more elements share the same name and the element prefix takes the name length beyond 256 characters, sufficient characters from the end of the element name must be dropped and rule number 9 must be applied.

The following is an example of element names based on the naming conventions described above. The table shows a concept label and the corresponding element name, based on the LC3 naming conventions.

Example 4. Sample LC3 element names.

English Label of Concept	Element Name
Assets	Assets
Cash & Marketable Securities	CashMarketableSecurities
Notes to Financial Statements	NotesFinancialStatements
Statement of Compliance	StatementCompliance
1st Time Application of US-GAAP	FirstTimeApplicationUSGAAP
First-Time application of US-GAAP	FirstTimeApplicationUSGAAP
Impact on Net Profit (Loss) for Each Period Presented for Change in Classification in Significant Foreign Operation	ImpactNetProfitLossEachPeriodPresentedChangeClassificationSignificantForeignOperation
Arm's length disposals of Excess of nominated proceeds from PRT1(Part2) Sterling Value £	ArmsLengthDisposalsExcessNominatedProceedsPRT1Part2SterlingValueUKPound

2.1.5 Element declarations for concepts must contain an “id” attribute whose value begins with the recommended namespace prefix of the taxonomy, followed by an underscore, followed by the element name.

The id attribute is not required (XBRL section 5.1.1) but it simplifies fragment identifiers in the URIs of linkbases. The recommended namespace prefix is defined according to rule 4.3.2 below.

Example 5. Required id attributes

English Label of Concept	Element Name	Namespace Prefix	id attribute
Cash in Bank	CashInBank	us-gaap-ci	us-gaap-ci_CashInBank
Gain (Loss)	AumentoP érdida	es-gaap	es-gaap_ AumentoPérdida
Cash in Bank	银行金钱	cn-csrc-ar	cn-csrc-ar_银行金钱

The resulting id MAY be longer than the 256 characters prescribed for the element name.

2.1.6 The value of the “nillable” attribute should be true for all concepts.

XBRL instances may include items with nil values to indicate that the value of the item is not known. An example of where this is useful is in instances that are produced as the result of database queries that return incomplete results.

The only use of nillable="false" (which is the XML Schema default) on items should be cases where the reporting standard itself mandates that a particular value cannot be left unspecified.

The only use of nillable="false" on tuples SHOULD be on tuples that are meant to appear at top level in an instance. This is because the only way that tuples can carry information in an instance is through the items they contain either directly or indirectly. Although tuples MAY contain nil items and contain nil tuples, a nil top-level tuple would contain nothing at all and be disallowed, and therefore making it nillable is discouraged.

Were it not for these cases, the present rule would be mandatory.

Although the value nillable="true" has no effect on items defined with abstract="true", definitions of abstract items must nevertheless follow this rule.

2.1.7 An “element” element may include any of the other XML Schema attributes that can be used on a global element syntax definition.

This is a consequence of specification section 5.11 [XBRL], which reads “The element MAY also include any of the other XML Schema attributes that can be used on an element’s syntax definition, including abstract and nillable.”

2.1.8 A concept must not prohibit the id attribute inherited from a base type.

All XBRL item types (section 4.3 [XBRL]) define an optional id attribute, and rule 2.3.9 below requires that “Tuple content models must include an optional local attribute with name ‘id’ and type ID.” Concepts based on one of these XBRL types may use a restriction of that base type but must not prohibit the id attribute in doing so.

2.1.9 All documentation of a concept must be contained in XBRL linkbases.

Taxonomy element declarations should not use the XML Schema documentation element.

2.1.10 A concept must have a label with the standard label role.

The standard label role is http://www.xbrl.org/2003/role/label.

Understanding the precise meaning of concepts within a financial reporting taxonomy is critical. The meaning of a concept is provided by a combination of documentation provided in the form of text in the label linkbase (using the “documentation” role) and/or references to other documentation provided external to the actual taxonomy, such as a paper volume of accounting standards.

This label must be in an extended-type link that is discoverable from the taxonomy schema in which the concept is defined.

2.1.11 All concepts within a taxonomy schema should have a unique label for the standard or verbose role in each language used.

Uniqueness within the scope of an entire DTS cannot be guaranteed by any single taxonomy author. Although the standard label for a concept need not be unique, for each value of xml:lang that appears on label resource elements in the taxonomy, one of the following holds true:

1. No two concepts have the same content for the element containing their standard label (role http://www.xbrl.org/2003/role/label); or

2. Every concept has a verbose label (role http://www.xbrl.org/2003/role/verboseLabel) AND no two concepts have the same content for their verbose labels.

In practice, taxonomy authors will need to choose whether to make either the standard labels unique, or if this is not practical, use a complete set of verbose labels for this purpose.

2.1.12 Each concept must have documentation in either the label or reference linkbase.

The documentation must be provided in at least one of these three ways:

1. label resource with the role http://www.xbrl.org/2003/role/documentation; or

2. label resource with the role http://www.xbrl.org/2003/role/definitionGuidance; or

3. reference resource with any reference role defined in the specification or in LRR (see rule 3.1.3 below).

A concept may have many different labels, each distinguished by the role assigned to that label and by the language that the label is expressed in. A concept may also have many different references to other literature that sheds light on the meaning of that concept. These references are distinguished using reference roles.

This documentation must be in label or reference extended-type links that are discoverable from the taxonomy schemas in which the concepts are defined.

The substance of the documentation of a concept should include:

· The meaning of the concept and any important distinctions from similar concepts;

· The reason for inclusion in the taxonomy, such as modelling a concept in the accounting literature, common practice within a jurisdiction, or structural elements believed to be necessary for technical reasons.

The substance of the documentation must include other considerations as indicated in rules 2.1.13 and 2.2.4 below. Also, while this rule allows alternative locations for documentation, text that is fully contained in the label linkbase will generally be more immediately accessible to all taxonomy users than anything linked to indirectly via a reference resource lacking its own URI part (see 2.1.21 below).

2.1.13 Labels should have a correspondence to the meaning of the element.

Human users are likely to be presented with a label, rather than the element name. This guidance is a consequence of rule 2.1.4.

2.1.14 There must not be internal structure in label text that requires software to draw inferences about the meaning of the label.

This is the dual of rule 2.1.13; label text should have meaning only to human users.

2.1.15 Words must be spelled consistently throughout the labels in a linkbase.

For example, “pro forma” must be used consistently rather than sometimes using “proforma” and sometimes “pro forma.” This rule should be interpreted as referring to labels all in a single language (see 4.2.7 below) and refers to root words only, for inflected languages such as German. This rule is advisory, rather than mandatory, for the role attributes listed in Table 3 below, “Roles indicating documentation”, because documentation may legitimately have reason to use variant spellings.

Table 3. Roles indicating documentation

http://www.xbrl.org/2003/role/documentation

http://www.xbrl.org/2003/role/definitionGuidance

http://www.xbrl.org/2003/role/disclosureGuidance

http://www.xbrl.org/2003/role/presentationGuidance

http://www.xbrl.org/2003/role/measurementGuidance

http://www.xbrl.org/2003/role/commentaryGuidance

http://www.xbrl.org/2003/role/exampleGuidance

2.1.16 Labels should have a consistent style of phrasing.

For example, “Treasury Shares, Ending Balance”, “Treasury Shares, Changes”, and “Treasury Shares, Beginning Balance” are consistent phrasings. Inconsistent phrasings would be “Final Treasury Shares,” “Treasury Shares, Changes” and “Beginning of Period Treasury Shares”. Note that “Treasury Shares, Ending Balance” could not be a standard label but rather is a period end label, so as this example implies, the rule of consistent phrasing applies across different roles.

2.1.17 Non-alphabetic characters, if used, should be used consistently in labels.

For example, if a comma is used to separate parts of a label, as in “treasury shares, ending balance”, then commas should be used in other labels in the taxonomy for the same purpose -- not mixed with dashes and brackets.

The following are example labels for each of the label roles:

Example 6. Labels

Role	Label for item NetResultForeignCurrencyTranslations (period type = duration)
standard label	Currency Translations, Net
terse label	F/X Net
verbose label	Foreign Currency Translations, Net Result
positive label	Currency Translations Gain
positive terse label	F/X Gain
positive verbose label	Foreign Currency Translations, Net Gain
negative label	Currency translations, Loss
negative terse label	F/X Loss
negative verbose label	Foreign Currency Translations, Net Loss
zero label
zero terse label
zero verbose label
total label	Total Currency Translations, Net

	Label for item FinishedGoodsInventory (period type = instant)
period start label	Finished Goods Inventory, Beginning of Period
period end label	Finished Goods Inventory, End of Period

Labelling guidelines for languages other than English are the responsibility of individual XBRL jurisdictions and, when they exist, must be followed in any labelling linkbase in the relevant language.

2.1.18 A concept must not have more than one label in a base set for each combination of language and label role in the DTS whose starting point is the schema defining that concept.

The taxonomy author is free to define additional labels to existing concepts defined in the taxonomy schemas that are imported. However, it makes no sense for that author to create more than one label of any given combination of language and role. Example 7 below shows three labels no two of which may both appear in a single linkbase. The scope of this rule applies only to the DTS discoverable from a taxonomy schema, since the taxonomy author can predict this, but cannot predict what DTS any instance will use.

Example 7. Disallowed inconsistencies in labels

Concept	Role	Language	Label
CashInBank	standard label	en	Cash in Bank
CashInBank	standard label	en	Cash in Bank
CashInBank	standard label	en	Cash on Deposit

2.1.19 All components of references to authoritative literature documenting concepts must be contained in appropriately defined reference parts.

References documenting a concept may consist of a hyperlink to web-based reference material or to pages or paragraphs in authoritative printed literature, or both.

Note that a consequence of the requirement that all components must be contained in reference parts means that although the XBRL schema does allow mixed content in the reference element (because it is a generic XLink resource-type element), FRTA compliant reference elements must not contain anything other than elements in the substitution group of part.

Example 8. Disallowed reference element with mixed content.

<link:reference

xlink:type="resource"

xlink:role="http://www.xbrl.org/2003/role/reference"

xlink:label="ar_Revaluations_ref"

xmlns:ref="http://www.xblr.org/2004/ref”>

See page <ref:Page>27</ref:Page> of the <ref:Name>Revaluations</ref:Name> volume.

</link:reference>

2.1.20 Reference parts should include the name of the standard or other enactment, and sections, clauses or paragraphs as appropriate.

The reference parts point to other materials. Note that specification section 5.2.3.2 says that reference parts “must not contain the content of those reference materials themselves.”

Each part of the literature must be referenced in a consistent manner; for example, the same law should always be “IPA” and not sometimes “Investor Protection”, sometimes “Protection Act”, etc.

2.1.21 References must use elements in the substitution group of the XBRL linkbase “part” element from the namespace http://www.xbrl.org/2004/ref.

Reference parts have been defined by XBRL International with recommended namespace prefix “ref”, where those elements are appropriate for the documentation that they are referencing. For example, page numbers may be irrelevant for some references. Reference linkbases must not use definitions with new names to mean the same thing as these elements.

Table 4. Defined reference parts.

Element	Documentation
Appendix	Refers to the name of an Appendix, which could be a number or text.
Article	Article refers to a statutory article in legal material.
Chapter	For a publication that uses chapters, this part should be used to capture this information. Chapters are not necessarily numbered.
Clause	Sub component of a sub paragraph.
Example	Example captures examples used in reference documentation.
Exhibit	Exhibit refers to exhibits in reference documentation.
Footnote	Footnote is used to reference footnotes in reference information.
IssueDate	The issue date of the specific reference. The format is CCYY-MM-DD.
Name	Name refers to the specific publication. For example, “Statement of Financial Standards”, “Statement of Position” or “IFRS”. It does not include the number.
Note	Notes can contain reference material; use this element when the note is published as a standalone document.
Number	Number is used to record the actual number of the specific publication. For example, the number for FAS 133 would be 133.
Page	Page number of the reference material.
Paragraph	Paragraph is used to refer to specific paragraphs in a document.
Publisher	Publisher of the reference material, such as SEC, FASB, or AICPA.
Section	Section is used to capture information typically captured in sections of legislation or reference documents.
Sentence	In some reference material individual sentences can be referred to, and this element allows them to be referenced.
Subclause	Subcomponent of a clause in a paragraph.
Subparagraph	Subparagraph of a paragraph.
Subsection	Subsection is a subsection of the section part.
URI	Full URI of the reference such as “http://www.fasb.org/fas133”.
URIDate	Date that the URI was valid, in CCYY-MM-DD format.

Appendix B below shows the normative XML Schema defining the parts.

Any subset or combination of these parts may be used in any given reference. A reference part must not appear more than once in any reference element, and they may appear as sub-elements in any order, since their contents will usually be displayed in an application-specific fashion. Reference elements MAY use additional reference part elements they deem appropriate for their documentation.

Example 9. Reference contents.

IAS 1 75 (e)
ref:Name	IAS
ref:Number	1
ref:Paragraph	75
ref:Subparagraph	e

Section 12(2)(a) Securities Act 1983
ref:Name	Securities Act
ref:Year	1983
ref:Section	12
ref:Subsection	2
ref:Paragraph	a

The xlink:role attribute (that reference elements must already contain) should distinguish between reference elements by the nature of the XBRL concept documentation that they make external reference to.

Example 10 below provides an example of some standard xlink:role attribute values and their meanings for reference resources. In the Balance sheet of the IFRS taxonomy, there is an element whose label is “Onerous Contracts Provision, Non Current”. The example has multiple references linked to the element OnerousContractsProvisionNonCurrent.

Example 10. Reference role usage.

Xlink:role attribute value for reference (Definition from XBRL 2.1 Section 5.2.2.2)	Reference example (actual text)
http://www.xbrl.org/2003/role/definitionRef	Name: Number: Paragraph:	IAS 37 10
Reference to documentation that details a precise definition of the concept.	An onerous contract is a contract in which the unavoidable costs of meeting the obligations under the contract exceed the economic benefits expected to be received under it.

http://www.xbrl.org/2003/role/presentationRef	Name: Number: Paragraph:	IAS 1 73 d
Reference to documentation which details an explanation of the presentation, placement or labelling of this concept in the context of other concepts in one or more specific types of business reports	… provisions are analysed showing separately provisions for employee benefit costs and any other items classified in a manner appropriate to the enterprise’s operations

http://www.xbrl.org/2003/role/measurementRef	Name: Number: Paragraph:	IAS 37 66
Reference concerning the method(s) required to be used when measuring values associated with this concept in business reports	If an enterprise has a contract that is onerous, the present obligation under the contract should be recognised and measured as a provision.

http://www.xbrl.org/2003/role/commentaryRef	Name: Number: Paragraph:	IAS 37 67
Any other general commentary on the concept that assists in determining appropriate usage	Many contracts (for example, some routine purchase orders) can be cancelled without paying compensation to the other party, and therefore there is no obligation. Other contracts establish both rights and obligations for each of the contracting parties. Where events make such a contract onerous, the contract falls within the scope of this Standard and a liability exists which is recognised. Executory contracts that are not onerous fall outside the scope of this Standard.
	Name: Number: Paragraph:	IAS 37 68
	This Standard defines an onerous contract as a contract in which the unavoidable costs of meeting the obligations under the contract exceed the economic benefits expected to be received under it. The unavoidable costs under a contract reflect the least net cost of exiting from the contract, which is the lower of the cost of fulfilling it and any compensation or penalties arising from failure to fulfil it.
	Name: Number: Paragraph:	IAS 37 69
	Before a separate provision for an onerous contract is established, an enterprise recognises any impairment loss that has occurred on assets dedicated to that contract (see IAS 36 Impairment of Assets).

http://www.xbrl.org/2003/role/exampleRef	Name: Number: Paragraph:	IAS 37 Appendix C Example 8
Reference to documentation that illustrates by example the application of the concept that assists in determining appropriate usage.	An enterprise operates profitably from a factory that it has leased under an operating lease. During December 2000 the enterprise relocates its operations to a new factory. The lease on the old factory continues for the next four years, it cannot be cancelled and the factory cannot be re-let to another user … Conclusion – A provision is recognised for the best estimate of the unavoidable lease payments.

2.1.22 Reference part element definitions must provide a documentation element containing a human readable explanation.

Reference link bases may use reference parts that have been defined in a schema other than an XBRL International published schema wherever the reference part definition is found, a human readable text definition must appear within the element definition at the path annotation/documentation.

Example 11. A reference part definition.

<element name="Article" type="string "

substitutionGroup="link:part" id="my_linkPart_Article">

<documentation>The title of an Article within a Law or other statutory document.</documentation>

</annotation>

</element>

2.2 Rules for items

This section documents syntax rules for concepts in the item substitution group.

2.2.1 XML Schema types should be used to constrain the content of items.

XML Schema offers a number of ways to provide constraining facets, all of which restrict the values allowed for elements. For example, enumerated lists, the minimum or maximum length of the string representation of a fact value, a certain pattern for a value, may all be used. These restrictions are documented in “XML Schema Part 2: Data Types” [SCHEMA‑2].

Taxonomies should use these XML Schema restrictions as far as possible to enable XML Schema checking of compliance with the constraints on valid values for concepts, insofar as the constraints hold universally. Constraints such as “revenues can have no more than 12 decimal digits” are too application-specific.

For example, item types whose content is restricted to enumerations are encouraged in financial reporting taxonomies when there are a finite number of valid values for an instance of a concept. For example, if “FixedRate” or “VariableRate” are the only options, and exactly one value is required, an enumeration with the values of “FixedRate” and “VariableRate” as a restriction of token should be used as the data type of which the concept’s item type is an extension.

2.2.2 Different values for an item must not result in different elements.

Concepts must not constrain the set of valid values for their instances on the basis of any of these limitations:

n the period over which a fact is measured;

n the entities or entity segments that the fact describes;

n the scenarios under which the fact is applicable; or

n the allowed units of measurement (for example, “in US Dollars”) unless specific units are literally and specifically required by the reporting standards underpinning the taxonomy.

Example 12. Concepts and facts

Concept	Fact	Explanation
Intangible Assets	Intangible Assets as of December 31, 2003	The one concept is used to represent facts in instances each with a different context. This context is for a particular point in time.
	Intangible Assets as of December 31, 2004	This context is for a different point in time as the previous fact.
	Intangible Assets as of December 31, 2003 for the East Asian Division	This context is for a different entity.
	Budgeted Intangible Assets as of December 31, 2003	This is a different measurement context.

2.2.3 Monetary concept declarations corresponding to accounting credit or debit balances (asset, liability, equity, revenue, expenses) must use the balance attribute.

The balance attribute must have the value credit or debit. Section 5.1.1.2 of the XBRL 2.1 Specification is explicit that the balance attribute must not be used on items that do not have type equal to the monetaryItemType or to a type that is derived from monetaryItemType.

2.2.4 A numeric item declaration without a balance attribute should have documentation for the item indicating its expected sign, and where the item represents a change in an underlying concept, increases must be represented as a positive number.

When a numeric item declaration has a balance attribute, the assignment of the value credit or debit to that attribute leaves no ambiguity as to the correct sign of any particular fact to be expressed using that item concept.

For other numeric items, such as those that appear in cash flow statements or movement analyses, the sign or polarity of the item in a taxonomy is to some extent an arbitrary choice, since the associated calculation arcs can subsequently be set with either positive or negative values as needed. For taxonomy designers, the sign of the item determines the sign of the weights; that is, when an instance contains a numeric fact, the correct sign of that fact must be determinable solely by the definition of the item without regard to the weights of adjacent calculation arcs or other parts of the taxonomy.

However, more than mere documentation is required when the goal is to enhance consistency in taxonomy design, remove ambiguity in instance document creation (particularly when there is a manual process), and enhance comparability among facts of the same item in a taxonomy. The following sub-rules apply:

1. The standard label of a numeric item should indicate the expected positive and (negative) sign of the fact values it will represent. See Example 13.

Example 13. Standard labels indicating expected positive and (negative) signs

Item	Standard Label
CashFlowsFromUsedOperatingActivites	Cash flows from (used in) operating activities
IncreaseDecreaseTradeCreditors	Increase (decrease) in Trade Creditors
IncreaseDecreaseInventory	Increase (decrease) in Inventory
IncreaseDecreaseReceivables	Increase (decrease) in Receivables

2. A fact that describes the “increase” or “upward movement” in value of an underlying item must have a positive value. See Example 14.

Example 14. Facts indicating increases and decreases

Item	Value	Meaning
CashFlowsFromUsedOperatingActivities	200	Operations produced 200 cash.
IncreaseDecreaseTradeCreditors	-700	Trade creditors decreased 700.
IncreaseDecreaseInventory	-600	Inventory decreased 600.
IncreaseDecreaseReceivables	500	Receivables increased 500.

Note that the item-summation arc between item declarations in a taxonomy constructed in accordance with both sub-rules must have a weight attribute, but that attribute could be either -1 or 1. As noted earlier, in designing a taxonomy it is the sign of the item concept that determines arc weights, not the reverse. Illustration of its impact on calculation arc weights is shown in section 3.3 below, “Rules for calculation relationships”.

This rule is optional for abstract numeric items.

2.2.5 Numeric items should not be percentages.

The notion of a “percentage” in numeric items of XBRL taxonomies introduces ambiguity, lack of comparability, and potential redundancy. Ratios are universal and unambiguous because there is never a question as to whether a factor of 100 has been applied to a figure such as “.8”, which could be read as a 80% change or .8% change. Whether to present that ratio of .8 to a user as “80%” or as “.8” is up to a rendering application. In Example 15, RevenueChangeRatio is acceptable but RevenueChangePercent is not.

Example 15. Recommended form of numeric ratio.

Element	Standard Label	Documentation
RevenueChangeRatio	Revenue Change	Ratio of current revenue to prior revenue.

Example 16. Discouraged form of numeric ratio.

Element	Standard Label	Documentation
RevenueChangePCT	Percent Revenue Change	The percent change in revenue.

2.2.6 Each item must only be asserted over either a duration or at an instant in time.

The context of a fact includes the instant (periodType="instant") or the period of time (periodType="duration") over which that fact is asserted to be true.

This is a consequence of specification section 5.1.1.1 [XBRL], which makes the periodType attribute mandatory on concept declarations.

2.2.7 Variations on the same concept that can be measured either over a period or at an instant in time must be represented by separate concepts.

Example 17. Related concepts measured at instants or over periods.

Concept	Period Type
Cash and cash equivalents	periodType="instant"
Change in cash and cash equivalents	periodType="duration"
Number of Shares at the End of the Period	periodType="instant"
Number of Shares Average of the Period	periodType="duration"

This is a consequence of specification section 5.1.1.1 [XBRL], which allows only instant and duration as values of the periodType attribute.

2.2.8 Sibling concepts in the content model of a tuple may have different values of the periodType attribute.

Tuples may reasonably associate elements that mix different period types.

Example 18. A tuple definition with children of different period types.

Concept

Period Type

Director Information (tuple)

Director Name (item)
Compensation (item)
Shares Held (item)

periodType="duration"

periodType="instant"

This is a consequence of specification section 4.9 [XBRL], which places no restrictions on the periodType of tuple children.

2.2.9 Numeric concepts representing a balance or to be captured at a specific point in time must have a periodType of “instant”.

Taken as a whole, financial statements are traditionally stated either historically (for example, for the period ended 31 December 2002) or prospectively (for example, for the period ending 31 December 2010). However, balances in the balance sheet, notes and other components of financial statements are stated “as at” or “as of” a specified date (for example, as at 31 December 2002).

Example 19. Numeric concepts requiring an instant period type.

Concept	Period Type
Current assets	periodType="instant"
Bank overdraft	periodType="instant"

The XBRL specification enforces the distinction between periodType="duration" and periodType="instant" at the level of the taxonomy so as to provide additional syntactic constraints on instances that are useful to application software that must consume instances efficiently. Also, applications that must consume and interpret instances using taxonomies that they have never before encountered can still process, present and interpret the taxonomy if more basic properties such as this are known.

2.2.10 The beginning balance, the ending balance, and any adjusted balances of an item for a period must be represented as a single item.

Financial reports often include a reconciliation where a beginning balance is shown (an instantaneous value), changes to that balance are shown (a value for the period which is a duration) reconciled to an ending balance (instant, but in a different period than the beginning balance). This is commonly called a “movement analysis”. Sometimes there is an “originally stated” beginning balance and adjustments to that beginning balance and possibly a restated balance. Distinctions between the beginning and ending balances of a given item must be identified in instances using the period element; distinctions between originally stated and restated values must be identified in instances using the scenario element.

2.2.11 Numeric concepts not measurable at a point in time must have a periodType of “duration”.

All other numeric concepts, including those representing movements in balances over a period, revenue and expense items, etc., will have a periodType of "duration".This holds regardless of whether the numeric concept appears in primary financial statements, notes or elsewhere.

Example 20. Numeric concepts requiring a duration period type.

Concept	Period Type
Net Income	periodType="duration"
Change in provision for doubtful debts	periodType="duration"
Movements in asset revaluation reserve	periodType="duration"
Earnings per share	periodType="duration"

Determining whether a concept is measurable at a point in time may require examining its components. For example, EPS is often stated “as at” or “as of” a particular date, usually balance date. However, a closer look at the components of the EPS equation suggest otherwise. The numerator (Earnings) is clearly a duration; the denominator (Number of shares) may either be an instant (for example, shares at balance date) – or, more commonly, as a duration (for example, weighted average number of shares across the period). Therefore the EPS calculation is more likely than not to have been constructed from the division of two durations and should be represented as a duration by default.

2.2.12 Non-numeric concepts that are stated as at a specified date, but apply to an entire period, must have a periodType of “duration”.

While there is consensus over which of the instant or duration alternatives apply to components of the primary financial statements, the components and concepts that make up the notes and accounting policies often are not addressed directly by accounting literature. Because the XBRL 2.1 Specification requires that all concepts have their periodType specified, general principles and rules assist consistency in taxonomy building and comparability of instance documents.

With regard to financial statement concepts, facts that are true over an entire period are clearly durations and those that are true at a specific date are clearly instants. The problem is that most note disclosures and accounting policies are true over the entire period, despite being stated as at the end of a period. Based on the logic that the duration includes the instant, it has been decided that note disclosures and accounting policies should be captured as periodType="duration".

An example of a numeric item is the depreciation expense of buildings. An example of a non-numeric item is a paragraph of text that explains an accounting policy. Accounting policies are stated as at a specified date, but apply to an entire period.

Example 21. Non-numeric concepts requiring a duration period type.

Concept	Period Type
Accounting policy for inventory	periodType="duration"
Measurement basis	periodType="duration"
Changes in accounting policies	periodType="duration"

2.2.13 Non-numeric concepts that are only true “as of” or “as at” a specific date, must have a periodType of “instant”.

This holds regardless of whether the numeric concept appears in primary financial statements, notes or elsewhere.

Example 22. Non-numeric concepts requiring an instant period type.

Concept	Period Type
Subsequent events	periodType="instant"
Assets held for sale disclosures	periodType="instant"

Although by definition “subsequent events” occur after the balance date and before the financial statements are finalised, they form part of the financial statements of the period. Therefore they should be stated “as of” or “as at” the balance date. This is supported by the fact that subsequent events affect conditions at the stated balance date and reflect on measurements of balance sheet items.

2.2.14 All other non-numeric concepts, such as accounting policies and disclosures, must have periodType of “duration”, whether or not they relate to balances or to a period.

In effect, this means that where it is unclear what the period type is that should be assigned to a concept (numeric or non-numeric), the default assignment must be periodType of “duration”. Because financial statements are generally stated for a period, it follows that an assignment of periodType="duration" will usually be correct.

Example 23. Default assignment of the duration period type.

Item	Period Type
CertificationDisclosureControlsProcedures	periodType="duration"
OmittedFactsIndependentAuditNotCompleted	periodType="duration"

2.3 Rules for tuples

Tuples are used to bind together, or associate, one or more items. Together, these concepts form a compound or complex concept. Examples include lists and tables in financial statements. Sets of tuples are also the only mechanism in XBRL that allows repeated occurrences of a concept to appear in an instance document in the same context (for instance, a list of subsidiary companies as of a point in time).

2.3.1 Tuples must be used to associate concepts that derive their meaning from each other.

Tuples need to be used wherever it is necessary to convey a number of concepts that cannot be understood without being grouped together. For example, it would be common to list directors’ names, salaries and options. To be understood, the entries need to be grouped together. Compare: there was a director named “Jane Smith,” there was a director that earned “$10,000” and there was a director granted “$50,000” in options, versus the fact that “Jane Smith” earned “$10,000” and was granted “$50,000” in options. If an XBRL instance is only composed of element name and value pairs inside atomic items, it is impossible to determine these fact groupings. Tuples associate the name and title pairs by nesting those items within the tuple of director’s remuneration in an instance.

Example 24 shows a table of compensation for directors of a company. For each director, the name of the director, salary, bonus, director’s fees paid, total compensation paid, and fair value of stock options granted are presented. This is a two dimensional table with (in this presentation) the groups of related facts displayed in rows, and the taxonomy concepts contained in columns. This information can be presented for any number of directors. While there is variation at the level of each group (row) of fact values, the concepts are set by the taxonomy. The schema diagram shows how this would be encoded using XBRL. The element DirCompensation is a tuple that contains six items. Each column of the table corresponds to one of the items.

Example 24. A table in a financial statement modelled using a tuple.

Name of director	Salary	Bonus	Director fees	Total compensation	Fair Value of Options Granted
Horace Chang	0	0	60,000	60,000	0
Gerry Ferguson	879,639	1,213,486	0	2,093,125	569,000
Sally James	0	0	24,200	24,200	0
Ivan Chenokitov	0	0	57,000	57,000	0

</appinfo>

</annotation>

</sequence>

</restriction>

</complexContent>

</complexType>

</element>

</schema>

In an XBRL instance, each row in the table will be a separate occurrence of the tuple.

The first row of the compensation table shown above in Example 24 appears in an XBRL instance as shown in Example 25. Each row of facts is grouped together by the nested tuple element, in this case my:DirCompensation, with each item contained, according to the sequence requirements set out in the content model of Example 24, within the opening and closing tags of the tuple.

Example 25. XBRL Instance data containing the first row of a table.

<identifier scheme="dns:nic">www.StandardAdvantage.com</identifier>

</entity>

</period>

</context>

<identifier scheme="dns:nic">www.StandardAdvantage.com</identifier>

</entity>

</period>

</context>

</unit>

<dct:DirCompensation>

<dct:DirName contextRef="sadv05p">Horace Chang</dct:DirName>

<dct:DirSalary decimals="0" contextRef="sadv05p" unitRef="usd">0</dct:DirSalary>

<dct:DirBonus decimals="0" contextRef="sadv05p" unitRef="usd">0</dct:DirBonus>

<dct:DirFees decimals="0" contextRef="sadv05p" unitRef="usd">60000</dct:DirFees>

<dct:DirTotalComp decimals="0" contextRef="sadv05p" unitRef="usd">60000</dct:DirTotalComp>

<dct:DirFairValueOptions decimals="0" contextRef="sadv05e" unitRef="usd">0</dct:DirFairValueOptions>

</dct:DirCompensation>

</xbrl>

In general, if one visualises the instance data as a multidimensional table, each “cell” in the table will appear as a separate item in the XBRL instance.

As discussed earlier in 2.1.13 above, XBRL items and tuples are global, so an item such as DirName appearing outside of the tuple DirCompensation will inevitably be XBRL-valid even if the intent of the taxonomy author may have been to limit its use to being inside of it. Example 26 shows valid documentation along with an instance that violates that documentation.

Example 26. Disallowed use of a concept that must appear in a tuple.

<label xlink:type="resource" xlink:label="label_DirName_1" xlink:role="http://www.xbrl.org/2003/role/documentation" xml:lang="en">This item must not appear at top level.</label>

</labelLink>

</linkbase>

<identifier scheme="dns:nic">www.StandardAdvantage.com</identifier>

</entity>

</period>

</context>

<dct:DirName contextRef="sadv05p">Horace Chang</dct:DirName>

</xbrl>

2.3.2 When instances may contain multiple values of the same item within the same context and having the same units, a tuple must be used.

For example, a single entity, during a single period, may have any number of subsidiaries. Therefore an item such as SubsidiaryName must appear within a tuple.

Although XBRL does not forbid instances to have facts that are both c‑equal and u‑equal, it is undesirable. The purpose of this rule is to prevent situations in which the absence of a tuple would force the instance author to create duplicate facts.

2.3.3 Numbered sequences of items to accommodate multiple values of the same item must not be used.

Items should not be created such as “Address1, City1, State1” and “Address2, City2, State2” simply to allow for two distinct addresses.

Accommodating three lines of street address with items “Street1”, “Street2”, and “Street3” does not violate this rule.

2.3.4 Tuples should not be used to represent segments, units, entities, periods, or scenarios.

A “segment” means a line of business, geographical region, or other partitioning of an entity (see XBRL Specification 2.1 section 4.7.3.2 [XBRL]). Segments should be represented as one or more segment sub-elements of context elements. Using tuples to model segments can make it more difficult to compare data in different instances, because it allows instance creators too much flexibility to invent new and different segments from those used by other instances.

In general, data that has multiple values within an instance depending on units, entities, periods or scenarios do not require tuples to model. This is a more general case than that specific to segments, but the rationale is the same. If the same item has different values when it appears in different contexts, then it is not necessary to use a tuple. Using tuples to embed these different dimensions of variation into a tuple can make it more difficult to compare data in different instances, because it allows instance creators too much flexibility to invent new and different segments from those used by other instances.

This rule is not expressed as an absolute prohibition because there may be situations in which the nature of the reporting standards in fact indicates that tuples are appropriate.

2.3.5 Tuple content models must enforce the constraints on their contents that are expressed in their labels and references.

For example, if a tuple is documented (in its label or reference linkbases) as the remuneration of a director, then its content model (in the schema) cannot contain more than one director name and one remuneration value.

2.3.6 The content model of a tuple should not contain a reference to itself nor any possible ancestor.

Tuples group together facts that cannot be independently understood. When a tuple can contain itself, either directly or at some level of nesting, the scope of the individual facts is unclear.

Example. Disallowed tuple containing a reference to itself.

<element ref="recursiveTuple"/>

</sequence>

</restriction>

</complexContent>

　</complexType>

</element>

</recursiveTuple>

This rule also forbids co-recursion (tuples including each other).

2.3.7 Tuple content models must not use the “all” compositor.

The meaning of the content of an instance of a financial reporting taxonomy does not depend on the order in which the facts are expressed in the instance; the ordering is therefore arbitrary within tuples. Since the order does not matter, the taxonomy author loses no flexibility but processing software can be somewhat simplified if, wherever the all compositor would be used, the sequence compositor is used instead.

2.3.8 Tuple definitions must not have the periodType attribute.

This is a consequence of specification section 4.9 [XBRL].

2.3.9 Tuple content models must include an optional local attribute with name ‘id’ and type ID.

Tuples occurring in instances must be allowed to have an id attribute, to allow footnotes to tuples. See Example 24, which contains the defining element:

In that example the DirCompensation tuple in the instance has also been augmented with a value for the id attribute.

3 Relationships Layer

The relationship layer of the architecture describes how concepts (both items and tuples) and resource-type elements may be related to one another. The relationship layer also describes how these relationships should be modelled.

A relationship exists between a source concept and target concept (or resource) when there is an arc from the source to the target. A single XLink arc can create multiple relationships. This can occur when the values of the “from” and “to” attributes appear as XLink labels on more than one locator-type element in the same linkbase.

Section 5.2 of the XBRL 2.1 Specification [XBRL] describes how relationships are modelled by arcs (arc-type elements) that appear within extended‑type links. Every arc has an arc role. Every extended-type link has a role, and MAY contain one or more arcs. All relationships are captured in extended-type links. The extended-type links together make up linkbases.

When the scope of a rule about a taxonomy schema (or linkbase) is stated as “within a DTS” without further qualification, this should be understood to mean “the DTS whose starting point is the taxonomy schema (or linkbase) to which the rule is being applied.” Rules 2.1.18 above and 3.1.5 below are examples of rules in which this scoping has been made explicit.

Section 3.5.3.9.7.3 [XBRL] defines a link base set, and rules governing relationships usually have a scope that only applies to relationships within the same base set.

3.1 Rules for all relationships

XBRL is an evolving set of standards and the set is always based on a particular version of the XBRL specification, currently 2.1. Additional members of this set of standards may include modules that are XBRL Recommendations and roles and arc roles which are approved and available in a link and role registry (LRR) hosted by XBRL International. Any specification, module, or role will be recommended or approved only when it has well established semantics.

3.1.1 A linkbase must not include any link elements (simple, resource, extended, or arc) not in an XBRL module or in the XBRL 2.1 Specification.

Although XBRL allows linkbases to be extended with additional XLink constructs, the set of schemas and linkbases comprising a FRTA compliant DTS is limited to those defined in the current XBRL Specification or Module Recommendations.

Table 5 summarises other extensions that are disallowed and allowed, and in the case of the extensions allowed, the documentation requirements.

Table 5. Extensions allowed in FRTA linkbases.

	Standard	Module	LRR	Any	Rule	Documentation Requirement
New link elements (xlink:type of locator, simple, arc, resource, or extended)	Yes	Yes	No	No	3.1.1	Modules are defined via specifications that satisfy XBRL International process requirements.
New arc roles	Yes	No	Yes	No	3.1.2	Documented in LRR.
New roles on resources	Yes	No	Yes	No	3.1.3	Documented in LRR.
New roles on extended-type links	Yes	Yes	Yes	Yes	3.1.4	3.1.10 “Any role type definition for an extended-type link in a persisting DTS must have a human-readable explanation in its definition element.”

3.1.2 An arc must have only its standard or LRR approved arc role.

A FRTA-compliant DTS must not use any arc roles except those documented in the XBRL Specification or approved in the LRR. This does not prevent the publication of an additional set of schemas, role definitions and linkbases that constitute a non-FRTA compliant superset of a FRTA-compliant DTS.

3.1.3 The label and reference elements must have only their standard or LRR approved resource roles.

The set of label and reference roles defined in Sections 5.2.2.2 (Table 8) and 5.2.3.2.1 (Table 9) of the XBRL 2.1 Specification, and any label and reference roles defined in the LRR, are all that are allowed in labelLink and referenceLink elements.

3.1.4 An extended-type link role must have no processing semantics other than specified by XBRL.

The only processing semantics that XBRL gives the xlink:role attribute on extended‑type links is that the values partition the sets of arcs in a DTS into distinct sets called link base sets. This is the only semantics allowed for the xlink:role.

3.1.5 A schema must not define a role type that duplicates a definition in the DTS whose starting point is the schema defining that role type.

An equivalent formulation of this rule is that a schema-rooted DTS must not contain s‑equal role types. Although a FRTA compliant taxonomy is constrained to use roles as shown in Table 5, the definitions of those roles may occur in various locations; this rule ensures that only one definition is used within a given DTS, because a taxonomy author can control this but not control the DTS of any instances. This rule also implies that the authoritative location of the role definition should be used.

3.1.6 Roles and arc roles from XBRL, XBRL modules, and the LRR should be used in preference to defining new roles.

This is a logical consequence of the fact that each of these sources has the status of an XBRL International recommendation.

3.1.7 All arcs within an extended-type link must have the same arc role.

The XML Linking Language [XLINK] forbids duplicate arcs within a given extended-type link, even when the arcs in question have different arc roles. Conforming XBRL processors detect violations of this syntax constraint. Accidental violations can be minimised by forcing each extended-type link to have only a single arc role on all the arcs that the extended-type link contains. In practice, this is most relevant to definition extended-type links, which have four standard arc roles defined:

http://www.xbrl.org/2003/arcrole/general‑special

http://www.xbrl.org/2003/arcrole/essence‑alias

http://www.xbrl.org/2003/arcrole/similar‑tuples

http://www.xbrl.org/2003/arcrole/requires‑element

This is true even though there are additional restrictions on which definition arcs may apply to which element pairs. The other extended-type links in XBRL each have only one standard arc role defined in each.

3.1.8 Each extended-type link must have a nonempty role attribute.

XBRL processors treat extended-type links separately when they have different values for the role attribute.

This is a consequence of specification section 3.5.3.3 [XBRL], which indicates that the role attribute must not be empty and that the standard value for the role attribute is http://www.xbrl.org/2003/role/link.

3.1.9 Extended-type links that are not necessarily processed together by consuming applications must have distinct role values.

Typical reasons that extended-type links are not be processed together are that the links may be incompatible (such as two alternative presentation formats that cannot be mixed), or that the links may be redundant.

This is a consequence of specification sections 3.5.3.3 and 5.2 [XBRL], which define, respectively, the syntax and semantics of the extended-type link role attribute.

3.1.10 Any role type definition for an extended-type link in a persisting DTS must have a human-readable explanation in its definition element.

In addition to being good practice to document newly defined roles, the purpose of this rule is to ensure the availability of a human-readable “label” to appear in taxonomy tools. Users see “Balance Sheet, Order of Liquidity Format” rather than “http://www.xbrl.org/2003/role/BalanceSheetLiquidity”.

Example 27. Role type definition with explanation.

roleURI="http://xbrl.iasb.org/int/fr/ifrs/gp/role/BalanceSheetLiquidity">

</link:roleType>

This is a role meant to identify a presentation link that contains arcs in which presentation siblings in a balance sheet are ordered by increasing liquidity.

roleURI="http://www.xbrl.org/int/fr/endNote">

</link:roleType>

This is a role meant to identify a footnote link containing notes intended only to be presented at the end of a document.

This means that in effect the definition element is required in the roleType element and its non-empty content should be an explanatory text string of no more that 50 characters. Additional description of the processing semantics should be provided in documentation [TRP].

3.1.11 The role URI in a roleType element must be an LRR approved role or begin with the same scheme and authority parts as the target namespace of the taxonomy schema where it appears.

This limits the potential for accidental merging of independently created networks of relationships. Only the scheme and authority [RFC2396] must be the same, not the entire path. When the URI is a URN [RFC2141], this rule is interpreted to mean that the NID must be the same.

http://www.ffiec.gov/2003/xbrl/form031

This is a role URI meant to identify extended-type links relating to a particular regulatory form used by the government agency “FFIEC”.

urn:xbrl:taxonomy:gcd:2002-10-15

This is a hypothetical URN identifying a dated version of a taxonomy published by XBRL International, with an NID of xbrl.

3.1.12 The role URI in a roleType element should end with “role” and a human-readable name.

In addition to as the constraints on the first part of a role URI (rule 3.1.11 above), the last part of the role must have a specified form as well. This rule is not mandatory because not all URI schemes might support this convention. When the URI is a URN [RFC2141] this is interpreted to mean that the NIS should contain role.

http://xbrl.iasb.org/int/fr/ifrs/gp/role/ByFunction

This is a role meant to identify an extended-type link that contains arcs having a non‑standard set of arc roles related to summation “by function”.

http://www.xbrl.org/us/fr/lr/role/IncomeStatement

This identifies extended-type links containing arcs for a US GAAP income statement.

urn:xbrl:role:us:fr:lr:incomeStatement

This is a hypothetical URN identifying extended-type links that contain arcs for a US GAAP income statement.

3.1.13 All arcs whose source and target both refer to concepts must specify an order attribute.

This rule universally applies to all arcs in all extended-type links in the calculation, definition and presentation linkbases, and applies to arcs with any arc role, whether standard or custom. This rule ensures that linkbases in taxonomies published conforming to FRTA have a common way of being presented in different tools. It is also meant to apply to any future XBRL modules that introduce new linkbases connecting concepts with each other; it does not apply to the label, reference (or footnote) linkbases. Section 3.5.3.9.6 of XBRL 2.1 Specification indicates that the order attribute is optional, but the order attribute is required in FRTA-compliant taxonomies.

Note that each sub-network of relationships and the way it is displayed to a user may bear no resemblance to any other sub-network. For example, a display in which the definition essence-alias arcs show each essence item as the parent of a list of alias items need bear no relationship to presentation parent-child or calculation summation-item arcs.

3.1.14 Two relationships defined by arcs in the same base set with the “use” attribute having the value “optional”, having concepts as targets and sharing the same “from” concept should have distinct values for the “order” attribute.

It is desirable for a DTS to have a deterministic ordering among siblings when displayed. This is always possible to ensure even for a DTS that imports two otherwise incompatible DTS’s, by prohibiting any arcs that introduce ambiguous ordering. This rule does not apply to relationships with the use attribute value of prohibited; it also does not apply to relationships between concepts and resource-type elements.

Note that this rule applies to relationships, not to arcs. Therefore, an arc with a “to” attribute value that is the XLink label of more that one concept would necessarily violate this rule since its ‘order’ attribute would then apply to siblings.

3.1.15 All arc-type elements may have use and priority attribute values.

This is a consequence of specification section 3.5.3.9.7 [XBRL], which defines how XBRL processors interpret the optional use and priority attributes.

3.1.16 All extended-type, locator-type, arc-type, and resource-type elements may have a title attribute.

XBRL processing ignores the title attribute. The title attribute is intended for use by XLink processors.

This is a consequence of specification section 3.3.5.6 [XBRL], which states that “titles have no XBRL specified semantics.” Section 3.5.3.9.6 applies to extended-type links, 3.3.5.6 to arcs.

3.1.17 Taxonomy creators may provide show and actuate attribute values on linkbase arcs.

XBRL processing ignores the show and actuate attributes. These attributes are intended for use by XLink processors.

3.2 Rules for presentation relationships

Presentation relationships are used to arrange taxonomy concepts into hierarchies with specific orderings for siblings. The usual purpose of a presentation linkbase is to show taxonomy elements in a hierarchical structure that is broadly familiar from printed reports or other standard displays. This helps users to find, identify and distinguish concepts.

For instances, it is the end user of that instance and their preferences as to level of detail, scope of the data, verbosity, language, currency, rounding, etc. that control how an application renders instance data. The presentation and label linkbases cannot, and should not control all of these aspects, but should provide useful data to rendering applications – for example, applications that render the taxonomy for its developers, reviewers and users.

That said it is nevertheless the case different reporting purposes will require different hierarchies. For example, one set of extended-type links and arcs might contain relationships that organise concepts into line items for a financial statement; another might organise the same set of concepts or a subset of these same concepts into a data collection form.

3.2.1 A DTS may contain any number of sets of extended-type links partitioned by role.

Any given DTS has a (possibly empty) set of presentation extended-type links that is partitioned according to the values of their role attributes. It is that partitioning—not the partitioning into files—of extended-type links within a DTS is what determines which extended-type links are processed together. Example 28 shows a simple example in which one extended-type link shows the children of an “Assets” elements with decreasing liquidity, while a different extended-type link shows them ordered by increasing liquidity.

Example 28. Presentation extended-type links, roles, arcs and arc roles

</presentationLink>

</presentationLink>

</linkbase>

Note that in Example 28 it does not matter whether the four arcs had been placed in four separate presentation links instead of two, so long as they remained within a presentation link having the same role value as before.

3.2.2 A concept meant to be ordered among its siblings must have a parent-child presentation relationship from its parent concept.

This rule applies to concepts whether they are items or tuples. The XML Schema content model of a tuple does not constrain the presentation arc ordering except as indicated in rule 3.2.6 below.

3.2.3 Presentation parent-child relationships having the same parent and child in extended links with the same role should provide preferred labels.

Although no pair of arcs in the same extended-type link can have the same “from” and “to” attributes [XLINK], it is still possible for separate extended-type links to have otherwise equivalent arcs. XBRL does allow undirected cycles in parent-child arc sets. But in addition to distinct values for the “order” attribute as suggested by 3.1.14 above, parent-child presentation arcs should indicate using the preferredLabel attribute which label an XBRL processor should use for the child concept depending on which parent concept it is being presented as a child of.

3.2.4 A DTS should provide parent-child presentation relationships intended for users of the taxonomy.

The base sets consisting of parent-child arcs in a DTS, taken in union, should provide enough information to display all the concepts that the DTS authors intend to be used in instances to be validated by that DTS. This does not mean that the base set has to provide all of the information needed to replicate or reconstruct printed financial statements or other standard displays. It also does not mean that presentation link bases must include all concepts in the DTS. If the standard role attribute value http://www.xbrl.org/2003/role/link is not used, then the documentation should specify the base sets (roles) whose union provides the intended coverage.

3.2.5 Abstract elements may be used as a heading to group other concepts for presentation.

Related financial data items and tuples are often presented together grouped under a heading or section. If the headings do not have to be tuples because each data item can stand on its own, and if there is no data item reported specifically for that heading, then an abstract element MAY be used to organize the presentation relationships. In Example 29, Earnings per share is a heading; the components of basic and diluted earnings per share are shown separately because although they are related, they are distinct calculations. There are also line items beneath these. The top level item, Earnings per share, in the example is an abstract element with an element name whose suffix is “Presentation” merely to indicate its purpose, and the entire presentation link happens to have the standard value for role. See additional rules in 2.1 above that apply to abstract elements.

Example 29. Abstract element used as a heading to group items

		Year ended December 31,
		2003	2002
		€	€
Earnings per share
Basic Earnings (Loss) per share
	Basic EPS including discontinued operations	.19	(.02)
	Basic EPS excluding discontinued operations	.21	.76
	Basic EPS	.20	.72
Diluted Earnings (Loss) per share
	Diluted EPS including discontinued operations	.06	(.03)
	Diluted EPS excluding discontinued operations	.28	.70
	Diluted EPS	.18	.68

<linkbase xmlns="http://www.xbrl.org/2003/linkbase" xmlns:xbrli="http://www.xbrl.org/2003/instance" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.xbrl.org/2003/linkbase http://www.xbrl.org/2003/xbrl-linkbase-2003-12-31.xsd" xmlns:ex29="http://www.xbrl.org/int/fr/frta/ex29/2005-04-04"> <presentationLink xlink:type="extended" xlink:role="http://www.xbrl.org/2003/role/link"> <loc xlink:type="locator" xlink:href="ex29-2005-04-04.xsd#ex29_EarningsPerShareAbstract" xlink:label="EarningsPerShareAbstract_0"/> <loc xlink:type="locator" xlink:href="ex29-2005-04-04.xsd#ex29_BasicEarningsLossPerShare" xlink:label="BasicEarningsLossPerShare_1"/> <presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="EarningsPerShareAbstract_0" xlink:to="BasicEarningsLossPerShare_1" use="optional" priority="0" order="1.0"/> <loc xlink:type="locator" xlink:href="ex29-2005-04-04.xsd#ex29_BasicEarningsLossPerShareIncludingDiscontinuedOperations" xlink:label="BasicEarningsLossPerShareIncludingDiscontinuedOperations_0"/> <presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="BasicEarningsLossPerShare_1" xlink:to="BasicEarningsLossPerShareIncludingDiscontinuedOperations_0" use="optional" priority="0" order="1.0"/> <loc xlink:type="locator" xlink:href="ex29-2005-04-04.xsd#ex29_BasicEarningsLossPerShareExcludingDiscontinuedOperations" xlink:label="BasicEarningsLossPerShareExcludingDiscontinuedOperations_0"/> <presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="BasicEarningsLossPerShare_1" xlink:to="BasicEarningsLossPerShareExcludingDiscontinuedOperations_0" use="optional" priority="0" order="2.0"/> <loc xlink:type="locator" xlink:href="ex29-2005-04-04.xsd#ex29_DilutedEarningsLossPerShare" xlink:label="DilutedEarningsLossPerShare_0"/> <presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="EarningsPerShareAbstract_0" xlink:to="DilutedEarningsLossPerShare_0" use="optional" priority="0" order="2.0"/> <loc xlink:type="locator" xlink:href="ex29-2005-04-04.xsd#ex29_DilutedEarningsLossPerShareIncludingDiscontinuedOperations" xlink:label="DilutedEarningsLossPerShareIncludingDiscontinuedOperations_0"/> <presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="DilutedEarningsLossPerShare_0" xlink:to="DilutedEarningsLossPerShareIncludingDiscontinuedOperations_0" use="optional" priority="0" order="1.0"/> <loc xlink:type="locator" xlink:href="ex29-2005-04-04.xsd#ex29_DilutedEarningsLossPerShareExcludingDiscontinuedOperations" xlink:label="DilutedEarningsLossPerShareExcludingDiscontinuedOperations_0"/> <presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="DilutedEarningsLossPerShare_0" xlink:to="DilutedEarningsLossPerShareExcludingDiscontinuedOperations_0" use="optional" priority="0" order="2.0"/> </presentationLink> </linkbase>

Note that there are no other abstract elements in this example, since the concrete elements were deemed sufficient to generate the example presentation. In particular, we assume that the following labels are present in the DTS:

Concept	Lang	Role	Label
BasicEarningsLossPerShare	en	…/label	Basic Earnings (Loss) per Share
BasicEarningsLossPerShare	en	…/totalLabel	Basic EPS
DilutedEarningsLossPerShare	en	…/label	Diluted Earnings (Loss) per Share
DilutedEarningsLossPerShare	en	…/totalLabel	Diluted EPS

We further presume that the application which rendered the instance data recursively descended through the presentation arcs; for any item with a total label it presented it first with the default label, then its children, then with the total label and its value. Finally, we presume that this rendering was done at the direction of, and with the preferences of a user, including factors such as level of detail, and language preference. Because there is no standard procedure or interpreter for rendering of XBRL instances, the goal of providing presentation arcs, preferred labels and labels in a FRTA compliant taxonomy is only to inform such applications. With that in mind, other uses for abstract elements other than that described in this rule are legitimate and not forbidden by FRTA.

3.2.6 For every tuple there should be at least one tree of presentation parent-child relationships in which every concept that can appear as a descendant of the tuple in an instance appears as a descendant of the tuple in that presentation tree, and there should not exist any tree of presentation parent-child relationships in which a non-abstract concept that cannot appear as a descendant of the tuple in an instance appears as a descendant of the tuple in that presentation tree.

The intent of this rule is to ensure that there is at least one presentation defined in the DTS rooted at the taxonomy where a tuple is defined, that matches the entire content of that tuple (to all depths of nesting of descendant tuples) that was anticipated by the taxonomy author.

Tuple concepts may appear in presentation hierarchies and so all elements that could appear as descendants of a particular tuple in an instance should appear as descendants of that tuple in at least one such presentation hierarchy.

Other elements that do not appear as descendants anywhere in its content model should not appear as descendants anywhere in any of its presentation sub-trees.

Note that for this purpose, an element reference in a tuple content model with maxOccurs="0" is considered to be an element that “does not appear”.

The order attribute is not constrained by the content model.

Example 30 shows presentation arcs added to Example 24 above; the arcs connect the elements in the tuple to the tuple element. Presentation arcs, because they appear separately from the tuple definition itself and can exist in extended-type links with different role values, are more flexible than the tuple definition itself, which controls only the arrangement of facts within instances. Presentation arcs impose their presentation order without any regard to the nesting or arrangement of XML Schema constructs such as sequence, and choice.

Example 30. Presentation parent-child arcs in a tuple.

For simplicity, this rule does not apply to concepts that might appear as descendants of tuples either

a. as a result of being in the substitution group of an element in a the content model of a tuple, or

b. as a result of matching a wildcard in the content model of a tuple.

This exception means that strict application of the rule does not, therefore, achieve the complete intent of the rule in every possible circumstance where a taxonomy author has used complex features of XML schema. However, such complex uses are not expected to be commonplace, nor are they considered desirable.

3.2.7 The parent-child relationships of a movement analysis must refer to a single item for the beginning, adjusted and ending balance values, each with a different preferred label.

Examples of movement analysis in financial reporting include the statement of changes in shareholders equity, the movement analysis for property, plant and equipment, and depreciation schedules in income tax reporting. As stated in rule 2.2.10, “The beginning balance, the ending balance, and any adjusted balances of an item for a period must be represented as a single item.” Example 31 shows a movement analysis for fixed assets, showing reconciling items along the top, and a list of assets down the side.

Example 31. Movement analysis for fixed assets.

	Valuation/Cost
	As at 1.1.2003	Additions	Disposals	Translation difference	As at 31.12.2003
	€’000	€’000	€’000	€’000	€’000
Land and Buildings	244,508	109,659	(193)	12,401	366,375
Furniture and Fixtures	34,457	0	0	0	34,457
Other	6,702	7,100	(262)	(7,487)	6,053
Total	285,667	116,759	(455)	4,914	406,885

3.3 Rules for calculation relationships

Calculation relationships, expressed using summation-item arcs in calculation extended-type links, allow taxonomy authors to document the meaning of items in terms of other items representing their mathematical components. Where the calculation relationships are sufficiently restricted that they can be expressed entirely within a single context (same period, same entity, same scenario), fully conforming XBRL processors will also use the calculation links as constraints on the consistency of instances. In general, a formula involving items A, B and C that is expressed as:

A = B - C

Is represented by two summation-item relationships:

· From A to B, weight 1.0;

· From A to C, weight -1.0.

Calculation arcs are designed so that taxonomy extensions can add new concepts to existing formulas without restating the parts of the formula that they are not altering. Therefore, an extension taxonomy could express the new formula

A = B – C + D

With an additional summation-item relationship:

· From A to D, weight 1.0.

The application of other rules may impact or constrain the way in which calculation arcs are used and their weights set. In particular, rule 2.2.4 states that “A numeric item declaration without a balance attribute should have documentation for the item indicating its expected sign, and where the item represents a change in an underlying concept, increases must be represented as a positive number.” Once the “sign” of a numeric item has been selected in a taxonomy, the weights of the calculation arcs which connect that item to other items can be assigned.

Example 32 shows a fragment of a taxonomy where all but three of the calculation summation-item arcs have weight=1. The items in the example correspond to the items in the examples of rule 2.2.4, Example 13 and Example 14.

Example 33 shows a set of facts from a sample instance, along with an indication of the corresponding weight of the arc from that item to its parent in Example 32.

34 then shows three different presentations of the same instance data (and implicitly, presenting the calculation or derivation of the data). In that example, it is assumed that some positive and negative terse and verbose labels (see Example 6) have been provided in the taxonomy.

Example 32. Calculation arcs in a cash flow statement

Example 33. Fact values of a cash flow statement in an instance

Standard Label	Fact	Weight of arc	Calculation
Net cash inflows (outflows) from operating activities	-440		+100+60-600
Reported net surplus (deficit)	100	+1
Non-cash items and non-operating items	60	+1	+50+20-10
Depreciation	50	+1
Bad debts reserve	20	+1
Gain (loss) on sale of fixed assets	10	-1
Increase (decrease) in working capital	600	-1	-(-700)+(-600)+500
Increase (decrease) in trade creditors	-700	-1
Increase (decrease) in inventory	-600	+1
Increase (decrease) in receivables	500	+1

Example 34. Three alternative presentations of a single set of cash flow facts

Calculation relationships indicated by displayed values only:

Reported net surplus	100

Add (less) non-cash items and non-operating items:
Depreciation	50
Bad debts reserve	20
(Gain) on sale of fixed assets	(10)

Movements in working capital:
Change in trade creditors	(700)
Change in inventory	600
Change in receivables	(500)
Net cash flows from operating activities	(440)

Calculation relationships indicated by labels only:

Reported net surplus	100

non-cash items and non-operating items:
Add:
Depreciation	50
Bad debts reserve	20
Less:
Gain on sale of fixed assets	10

Movement in working capital:
Add:
Decrease in inventory	600
Less:
Decrease in trade creditors	700
Increase in receivables	500
Net cash outflows from operating activities	440

Calculation relationships indicated by a combination of label & displayed values:

Reported net surplus (deficit)	100

Add (less) non-cash items and non-operating items:
Depreciation	50
Bad debts reserve	20
Loss (Gain) on sale of fixed assets	(10)

Movements in working capital:
Increase (decrease) in trade creditors	(700)
(Increase) decrease in inventory	600
(Increase) decrease in receivables	(500)
Net cash inflows (decrease) from operating activities	(440)

The examples above reinforce the point that calculation and presentation arcs do not necessarily correspond, and that the presentation of a particular fact value as positive (negative) could even depend on the sign of its parent and other factors.

3.3.1 All concepts in a DTS which have an additive relationship in all equal contexts should have calculation relationships in that DTS.

Taxonomy authors should supply a calculation relationship for any two concepts in the same DTS, whenever it is the case that in any context, one item is a mathematical component of the other.

For example, suppose that a DTS encompasses the concepts “Gross receivables”, “Net receivables” and the adjustment “Allowance for returns and doubtful accounts”, and further suppose that the documented definitions of these concepts indicate that the relationship is a total (“Gross”) with two items “Net” and “Adjustment”. Mathematically this is identical to the “A = B – C” example illustrated above and so the calculation links are structured identically.

Example 35. A Net and Gross relationship

Accounts receivable, net of allowances, consists of the following as of the balance sheet date:	2001	2002
	€’000	€’000
Gross accounts receivable	18,280	13,472
Less allowance for returns and doubtful accounts	(5,687)	(4,682)
Net accounts receivable	12,593	8,790

In this case, calculation relationships should be defined relating the gross, net and adjustment total concepts.

3.3.2 Calculation relationships that represent alternative summations for the same item must be in extended-type links with distinct roles.

Double counting would result if two alternative ways of calculating an amount were to appear both in extended-type links with the same role. For example, total income tax expense might be calculated either by summing foreign and domestic taxes, summing current and deferred, or both. These calculations must appear in extended-type links with distinct roles.

In Example 36, three extended-type links are shown, one with the standard role value, one with role value http://www.xbrl.org/2003/role/currentDeferrred, and one with role value http://www.xbrl.org/2003/role/foreignDomestic (these are example roles; to conform with rules 3.1.10 and 3.1.11 above these would be based on some other namespace).

The summation‑item arcs in Example 36 all have weight equal to 1.0, and all of the concepts have balance="credit" and periodType="duration" since they are all expenses that are measured over a period of time.

Example 36. Two distinct summations in a financial report

The following is a summary of income tax expense:	2001	2002
	$’000	$’000
Current income tax expense
Foreign	5,408	1,994
Domestic	7,972	1,426
Total current	13,380	3,420
Deferred income tax expense
Foreign	6,046	838
Domestic	(90)	0
Total deferred	5,956	838
Total Income Tax Expense	19,336	4,258
The following is a summary of income tax expense:	2001	2002
	$’000	$’000
Foreign income tax expense
Current	5,408	1,994
Deferred	6,046	838
Total foreign	11,454	2,832
Domestic income tax expense
Current	7,972	1,426
Deferred	(90)	0
Total domestic	7,882	1,426
Total Income Tax Expense	19,336	4,258

Specification section 5.2 [XBRL] details how the semantics embodied in extended link arcs is contingent on extended link arc role values, and forces independence on calculations in different base sets.

Compliance with this rule cannot be established in an entirely automated fashion because it is impossible to reliably determine the taxonomy authors’ intent.

3.3.3 Taxonomies should define an extensive set of subtotal concepts to limit the extent to which XBRL instances requiring such sub-totals need to create report-specific extensions.

Just as in Example 36, all of the items and relevant calculation arcs should be defined for cases where such alternatives are permitted.

Multiple calculation hierarchies, summing a single set of concepts in multiple ways, occur in many guises in financial reporting. For example, in a classified balance sheet, assets and liabilities are totalled separately into current and non-current categories; while an unclassified balance sheet does not make the current versus non-current distinction. Classified balance sheets may also be presented as “assets = liabilities + equity,” as “net assets = assets – liabilities = equity,” as “net assets = assets – liabilities – minority interests = equity,” and so on. These relationships must be defined in calculation links having different roles.

3.3.4 Calculation relationships must be defined between items being totalled in a tuple.

Financial reporting tables often show totals for one or more of the columns. Calculation relationships must be defined between the items being totalled within the table and the item that represents the total itself where such calculation relationships hold within a single context. Example 37 is similar to Example 24 except for the item “Total Salary, Bonus, and Director Fees”. This is a total within a tuple. The total across the tuples is the “Total” at the bottom of the table. Each such total is a child of the enclosing tuple, here called DirCompensationTotal. The relationships are shown below.

Example 37. Table containing a summation across tuples.

Name of director	Salary	Bonus	Director fees	Total Salary, Bonus, and Director fees	Fair Value of Options Granted
Horace Chang	0	0	60,000	60,000	0
Gerry Ferguson	879,639	1,213,486	0	2,093,125	569,0000
Sally James	0	0	24,200	24,200	0
Ivan Chenokitov	0	0	57,000	57,000	0
Total	879,639	1,213,486	141,200	2,234,325	569,000

It is up to XBRL instance creators to ensure that their XBRL instances present the various instances of the concepts in a way that enables the calculation relationships to bind. Generally, a total item should be a sibling of the tuples that contain the items whose values aggregate to the value of the total item.

3.3.5 The declarations of the source and target concepts of a summation-item relationship must have identical values of the periodType attribute.

For example, there must not be a calculation relationship between the items in Example 38, because the period types are different and therefore the items are in different contexts.

Example 38. Calculation links cannot cross period types

Item	Label Role	Item Label	periodType	Value
ChangeInCash	standard	Change in Cash	duration	-10
Cash	Period end	Cash, ending balance	instant	90

3.3.6 The source and target concepts of a summation-item relationship must be distinct.

Summation-item arcs must not be used to describe relationships if the starting and ending balances are represented by the same numeric item but distinguished by different periods. Although XBRL section 5.2.5.2 allows all types of cycles in sets of summation-item arcs, this rule forbids the particular case of a cycle of a single item. There must not be any calculation relationships between the items in Example 39, because the two Cash items are the same concept.

Example 39. Calculation relationships cannot cross periods

Item	Label Role	Item Label	periodType	Value
Cash	Period start	Cash, beginning balance	instant	100
ChangeInCash	standard	Change in Cash	duration	-10
Cash	Period end	Cash, ending balance	instant	90

Taken together, rules 3.3.5 and 3.3.6 mean that calculation relationships cannot associate the beginning balance, adjusted balance and ending balance in a movement analysis (see rule 2.2.10, “The beginning balance, the ending balance, and any adjusted balances of an item for a period must be represented as a single item.”). Only the presentation of movement analyses can be represented using XBRL 2.1.

3.4 Rules for definition relationships

XBRL represents relationships among concepts that influence each others’ values or presentation. Definition relationships allow the taxonomy author to represent relationships that are not expressed by presentation or calculation relationships. Consuming applications MAY use these definition relationships to draw inferences about the concepts.

Definition relationships are not sensitive to any portions of any context element in an instance. XBRL 2.1 provides no way to distinguish between definition arcs that should only apply to one entity in an instance and not another. Definition relationships are a “blunt instrument” and because of the variety of situations in which they might be used, none of the rules that govern their use are phrased as mandatory (“must”) rules.

3.4.1 Equivalent items in different taxonomy schemas within a DTS should be indicated by essence-alias relationships.

Section 5.2.6.2 [XBRL] imposes the constraint that items connected by an essence-alias arc must have the same item type and must have identical values within the same context in an instance. Also, rule 2.1.1 (“A taxonomy schema must define only one concept for each separately defined class of facts.”) means that each taxonomy schema must use unique elements to express unique concepts.

Therefore, the intended use of the essence‑alias arc is to map equivalence between taxonomies. In fact, because of rule 2.1.1, this rule is relevant only for arcs where the source and target are in different taxonomy schemas. There are no requirements governing which concept is chosen as the essence (source) and which the alias (target) in the relationship.

Adding an essence-alias arc from one DTS to a concept not already in that DTS does imply that the taxonomy of that other concept will, by the rules of DTS discovery, be included in the DTS. The present rule does not recommend the inclusion of additional taxonomy schemas; it only says that if a DTS contains equivalent concepts, then there should be an essence‑alias or similar‑tuples arc, as appropriate.

3.4.2 Items that fall into the same category or family should be related using the general-special relationship.

General-special relationships provide the user of the taxonomy assistance in identifying what a particular concept means by helping classify the concept, and can help end users to identify appropriate elements to select when mapping their own data models or terminology to a taxonomy. For example, “fixed assets” are a specialisation of “assets”; “profit” is a specialisation of “business measure”; “accumulated depreciation” is a specialisation of “contra-asset”. The general‑special relationship suggests its meaning to a human observer, but conforming XBRL processors do not draw any particular inferences from the presence or absence of general‑special relationships.

3.4.3 A tuple having the same reporting purpose as a tuple in a different taxonomy within the same DTS should have a similar-tuples relationship to that other tuple.

Extension taxonomies are meant to use similar-tuple definition relationships to relate a new tuple to an existing tuple in the taxonomy that is being extended, where the new tuple had the same reporting purpose. Example 40 shows two tuples:

· pdt:PropertyDescription having a content model of only two items pdt:PropertyIdentifier and pdt:PropertyDateAcquired, and below it,

· ex41:PropertyDescription having the same two items followed by a third item, ex41:PropertyAssessmentForTaxes.

Example 40. Similar-tuple relationship between old and new tuples.

In a strict sense, “similar” tuples are tuples with similar meanings but different content models. The similar-tuples arc role is used to indicate that two different tuple concepts are both designed to serve the same purpose, for example, to relate two mailing address tuples with different address structures. This arc role is for the documentation of relationships between tuples and a conforming XBRL processor draws no inferences from it. The most common circumstance contemplated is where a new tuple has been added to a DTS via an extension taxonomy. This provides a mechanism for documenting relationships between a new tuple and its predecessor, without using the XML Schema redefine construct that is prohibited by XBRL section 5.1.5.

3.4.4 The requires-element relationship must not be used when a tuple construct can adequately represent the same constraint.

As stated in 5.2.6.2 [XBRL], “If an instance of the concept at the source of the arc occurs in an XBRL instance then an instance of the arc’s target concept must also occur in the XBRL instance.” A conforming XBRL processor will enforce this constraint on instances. A similar effect can be achieved with the following tuple content model:

</sequence>

</choice>

However, the intent of the reporting standard being expressed by the taxonomy may be more or less restrictive than that. 5.2.6.2 [XBRL] also points out that “this requirement does not impose requirements on relative locations of the concept instances in tuples.” Therefore, if the intent of the taxonomy to require one element if another appears, irrespective of content, irrespective of where the element appears in the instance, and irrespective of usage by other taxonomies, that is the only appropriate use of the requires‑element arc.

4 Discoverable taxonomy set layer

The DTS layer of the financial reporting taxonomy architecture encompasses the scope, syntax, naming and documentation relating to a DTS whose starting point is a given taxonomy schema.

4.1 Scope of discoverable taxonomy sets for financial reporting

For financial reporting, a DTS should include the concept definitions and documentation and relationships that describe:

1. Required financial reporting disclosures; and

2. Common practices in financial reporting.

The goal of a financial reporting DTS should be to provide users of that DTS with what is commonly contained within financial reported information within the jurisdiction and industry in which an entity operates.

It is up to entities reporting using a specified financial reporting DTS to extend that DTS for specific disclosures which are material to that entity, but are not covered by the DTS.

4.2 Rules for discoverable taxonomy set structure

The DTS rules governing the process of discovering all the files of a DTS are documented in Section 3.2 [XBRL]. The rules in this section cover appropriate usage and syntactic constraints on the files in a DTS.

4.2.1 A schema document must contain only declarations of reference parts OR declarations of concepts, roles and arc roles OR declarations that are not concepts and not reference parts.

A DTS must be organised with separate schema files so as to partition the entire set of element definitions into separate schema documents containing different types of definitions:

1. Reference parts;

2. Content for context segment and scenario elements (which are subject to the rules in [XBRL] sections 4.7.3.2 and 4.7.4);

3. Taxonomy concepts, custom roles and arc roles.

Consequences of this (taking [XBRL] section 5.1 into account) include the following:

· Any taxonomy schema that contains a declaration of an element substitutable for xbrli:item or xbrli:tuple must not contain declarations for any elements that are not substitutable for xbrli:item or xbrli:tuple.

· Any taxonomy schema that contains a declaration of an element substitutable for link:part must not contain declarations for any elements that are not substitutable for link:part. Note that link:part is a simple type and therefore a “part” would never have any child elements.

· If a schema contains roleType or arcroleType elements, any element declarations it contains must be for elements substitutable for xbrli:item or xbrli:tuple.

· Type declarations may appear in any schema.

· XML Schema group, attributeGroup and attribute declarations may appear in any schema.

· This rule imposes no constraints whatsoever on the contents of schemas that do not contain one of the following: a) concept declarations; b) reference part declarations; c) roleType elements; d) arcroleType elements.

4.2.2 Taxonomy schemas must be defined in XML documents in which the XML Schema “schema” element appears once only as the root element.

Taxonomy Schemas are XML Schemas, which are represented in XML as one or more schema elements. XML Schema [SCHEMA-1], [SCHEMA‑2] allows these elements to appear anywhere in an XML document, but many Schema-validating XML parsers will only process schema elements that are the root element in the document in which they appear. To facilitate processing, this rule requires that every schema element is the root element in its containing XML document.

4.2.3 Taxonomy schemas must not contain embedded linkbases.

This is a consequence of 4.2.2 above to clarify that a linkbase is not considered a part of a taxonomy schema.

4.2.4 Taxonomy schemas must declare elementFormDefault to be “qualified,” attributeFormDefault must have the value “unqualified”, and the “form” attribute must not appear on element and attribute declarations.

This rule ensures consistent treatment of references to attributes and elements in element definitions. The XML Schema form attribute is disallowed because it could be used on individual attribute and element declarations to override the defaults specified on the schema element; “unqualified” is the default for attributeFormDefault [SCHEMA-0].

4.2.5 A linkbaseRef element must have an xlink:role attribute value.

The XBRL specification 4.3.4 [XBRL] allows the xlink:role attribute to have either a URI value or be unspecified (missing); this rule forces it to have a value.

4.2.6 All extended-type links in a single linkbase must have the same namespace and local name.

Each linkbase can only contain one kind of extended link, such as labelLink, referenceLink, definitionLink, calculationLink or presentationLink.

4.2.7 A label linkbase should only contain labels defined in a single language.

A “single language” means a single ISO 639 language code [ISO]. For example, “en” and “en-nz” are distinct for this purpose.

4.2.8 Any number of taxonomy schemas may contain links to select schemas and linkbases to enable discovery of unique DTS’s.

A DTS may be defined in such a way that it includes other DTS’s. To ensure discovery of specific taxonomy components from a given starting document, that starting document simply provides physical links to those other documents.

A taxonomy schema used as a starting document may therefore contain only import, include, schemaRef and linkbaseRef elements without any element, complexType or any other XML Schema elements. This allows for controlled discovery of certain taxonomies for specific reporting purposes and may be distributed as part of a DTS for financial reporting.

In Example 41, there are three DTS’s:

1. A taxonomy schema of 200 elements and an associated presentation linkbase;

2. A taxonomy schema of zero elements and a reference to a linkbase of Spanish labels;

3. A third formed from a different empty Schema consisting only of a link to a different (English labels) linkbase.

Note that only the 2^nd and 3^rd discoverable taxonomy sets are FRTA-compliant; the first, lacking labels, violates rule 2.1.10.

Example 41. Three distinct discoverable taxonomy sets.

xlink:href="cnv-presentation.xml" xlink:title="Presentation Links, all" xlink:role="http://www.xbrl.org/2003/role/presentationLinkbaseRef"/>

</appinfo>

</annotation>

</schema>

xlink:href="cnv-label-es.xml" xlink:title="Label Links, Español" xlink:role="http://www.xbrl.org/2003/role/labelLinkbaseRef"/>

</appinfo>

</annotation>

<!-- import is not needed here because cnv.xsd is in the DTS by virtue of the label linkbase.

-->

</schema>

xlink:href="cnv-label-en.xml" xlink:title="Label Links, English" xlink:role="http://www.xbrl.org/2003/role/labelLinkbaseRef"/>

</appinfo>

</annotation>

<!-- import is not needed here because cnv.xsd is in the DTS by virtue of the label linkbase.

-->

</schema>

Such additional taxonomy schemas, with or without XBRL item, tuple or other definitions, are not mandatory; the decision is up to DTS designers and should be driven by considerations of modularity and control over the strength of the association between semantics and the syntax for XBRL concepts.

4.2.9 A taxonomy schema should not contain import or include elements not strictly needed for XML Schema validity.

Many XBRL taxonomy schemas, even though they represent extensions of other taxonomies, will not need to import any schema other than the base XBRL schemas themselves. Instead, a linkbaseRef element is often sufficient, as illustrated in Example 41. Identifying the taxonomy being extended is rarely needed, since the rules of DTS discovery will traverse the linkbase in question to gather all relevant taxonomy schemas. Furthermore, where such references are needed in order for XBRL validation to perform correctly, schemaRef in instances is preferable to import and include in schemas.

4.2.10 A DTS should include scenario element definitions that are relevant to the reporting standard upon which it is based, unless such elements already exist in a recommended taxonomy.

Any context element that omits further detail in its scenario sub-element is left open to interpretation: is it a reported, verifiable fact, an estimate, a restatement of a prior period reported value? If these distinctions are important in the reporting standard, then they should be encoded as elements to appear in the scenario element. Applying the general principle that a FRTA compliant taxonomy must not redefine elements that already have recommended definitions, scenario elements appearing in XBRL International taxonomies that have achieved recommended status must be used if applicable.

4.2.11 Every schema in a DTS must define a non-empty targetNamespace attribute value.

The targetNamespace of a schema not only allows the definitions in the schema to be uniquely identified, but it also allows the entire schema to be referred to. Although a schema may be devoid of concept definitions (as for example if its only function is to group a set of linkbases and other schemas), it must still have a non-empty namespace.

4.3 Taxonomy naming rules

As noted in section 1.3, “Goals of this document,” a financial reporting taxonomy or extension of the USFR or IFRS taxonomy that receives Approved status [TRP] from XBRL International must conform to this architecture. The conventions in this section relate to taxonomy (as opposed to element) naming and related rules.

4.3.1 Persisting taxonomies must use a targetNamespace that is an XBRL International style URI for all final versions of their taxonomies.

The target namespace must be an absolute URI representing a hierarchy having at least these levels:

Jurisdiction;
Reporting type;
Accounting type;
Version date.

This may either be a URN [RFC2141] or a generic URI; generic URI syntax (Section 3 [RFC2396]) describes a URI as:

Because all components except scheme may be absent from a particular URI, in BNF this becomes:

scheme '://' {authority}? {path}? {'?' query}?

The restrictions imposed by this rule when the target namespace is a generic URI are as follows:

The scheme may be any widely recognised generic URI scheme such as http, https or ftp.

There must be an authority component. The authority MUST be server-based. Section 3.2.2 [RFC2396] describes a server-based authority as:

Or in BNF,

{userinfo '@'}? host {':' port}?

The host MUST be a domain name controlled by the authority issuing the taxonomy; the userinfo and port parts are optional.

Example 42. Authorities and controlled names.

Name	Authority
www.xbrl.org	XBRL International
www.xbrl.de	XBRL Deutschland e.V.
xbrl.iasb.org	IASC Foundation
www.xbrl-au.org	XBRL Australia Ltd.
xbrl.reardensteel.com	Rearden Steel

The path must be present and must follow this pattern:

/jurisdiction/reportingType/accountingType/{qualifier/}*versionDate

In BNF:

'/' jurisdiction '/' reportingType '/'accountingType '/' {qualifier '

/'}* versionDate

The components are defined as follows.

Component	Definition	Non-normative Examples
jurisdiction	Indicates the jurisdiction abbreviation. Typically, jurisdictions should be the country code [IANA] of the jurisdiction where possible.	· int – International · us – United States · de – Germany
reportingType	The report type.	· br – Business Reporting · fr – Financial Reporting
accountingType	The type of accounting.	· ifrs – International Financial Reporting Standards · gaap – Generally Accepted Accounting Principles · tax – Tax based reporting
qualifier	Any other qualifier more granular than jurisdiction, reporting type and accounting type.	· Language codes (en, fr-ca) · Regulatory form identifier (ffiec031, ct600) · Industry, such as: o ci – Commercial and Industrial entities o basi – Banking and Savings Institutions o gp – General Purpose o nfp – Not-for-Profits
versionDate	The release date of the taxonomy in ISO8601 format (CCYY-MM-DD).	· 2004-10-19

The query must be empty.

When the target namespace is a URN the same components that would have been in an equivalent hierarchical URI must be present in the same order.

4.3.2 Each unique taxonomy schema target namespace must have one and only one namespace prefix of one to twelve characters, which will be its recommended namespace prefix.

The recommended namespace prefix should suggest the distinct scope and purpose of the concepts defined within that namespace.

Example 43. Recommended namespace prefixes.

Prefix	Meaning
int-gcd	International Global Common Document concepts
ifrs-gp	IFRS General Purpose concepts
us-gaap-ci	US GAAP Commercial and Industrial concepts
au-ifrs-ci	Australian IFRS extensions
au-cd	Australian Common Document concepts

4.3.3 A taxonomy that supersedes an existing version of itself must use the date portion of its namespace URI to identify the new version.

The date may be the date of anticipated publication, date of the end of the comment period, or any other significant date which disambiguates the version in question from prior and subsequent versions. At this time there is no taxonomy element to express the linkage between two versions of a taxonomy other than this naming convention.

4.3.4 Taxonomy file names should use the recommended namespace prefix and identifying date in their names.

Taxonomy file names should follow the pattern:

Schema files	{recommendedNamespacePrefix}-{date}.xsd
Linkbase files	{recommendedNamespacePrefix}-{date}-{linkbasetype}{‑qualifier}*.xml
Label Linkbase files	{recommendedNamespacePrefix}-{date}-label{‑language}{-qualifier}*.xml

The {-qualifier} must not be used for any linkbase which is the “default” linkbase, as for example a presentation linkbase intended for use in presenting the taxonomy.

Example 44. Taxonomy file names with qualifiers.

File name	Meaning
ifrs-gp-2004-08-15.xsd	IFRS-GP schema
us-gaap-ci-2004-08-15.xsd	US-GAAP-CI schema
us-gaap-ci-2004-08-15-labels.xml	US-GAAP-CI (default US English) labels linkbase
us-gaap-ci-2004-12-25-labels-sp.xml	US-GAAP-CI Spanish labels linkbase

A consequence of rule 4.2.8 is that a linkbase may have an existence distinct from the other taxonomy schemas and linkbases in its DTS. For example, the Spanish labels linkbase of a US-GAAP-CI taxonomy, for example, may have an independent publication date from the schemas it refers to, and new versions of the Spanish labels may be published at any time. The DTS whose starting point is that Spanish labels linkbase should nevertheless have a file name following the convention described in this rule.

5 Taxonomy Extensions

Taxonomy extensions add concepts and modify the relationships among the concepts in the base taxonomies that they extend. Extension taxonomies will commonly be created to support specialised reporting requirements in specific accounting jurisdictions, in specific industries, or for specific companies. Taxonomy extensions consist of a set of taxonomy schemas and/or linkbases that augment a DTS that includes the base taxonomies.

A linkbase document L1 is an extension of another linkbase document L2 if and only if L2 is discoverable from L1 but L1 is not discoverable from L2. Here we call L1 the “extension linkbase” and L2 the “base linkbase”.

Rules relating to extensions include rules of syntax and, for persisting extensions, rules of documentation. A persisting extension is one whose purpose is to be stored as files to be referenced by many instances and published in some fashion for users to examine.

5.1 Rules for extension taxonomies

5.1.1 An extension must not modify the meaning of concepts in the base.

More precisely, extensions must not modify the meaning of concepts as documented in the base in ways that are inconsistent with the meaning of those concepts defined by any DTS that includes the base but excludes the extension.

“Meaning” is captured by relationships in linkbases; as stated in 5.1.6 below, “The concept-label, essence-alias, similar-tuples, concept-reference, and general-special relationships should not be prohibited.” An extension can violate 5.1.6, yet it is up to reviewers to judge whether relationships added by the extension (allowed by rule 5.1.8) are so inconsistent with the prohibited relations that the concept becomes inconsistent with the original concept.

5.1.2 Word choice in the labels of an extension should be consistent with the terminology used in its base.

This rule, while seemingly self evident, does allow for the possibility that a legitimate purpose for an extension might be to apply a different, but consistent terminology, as for industry specific terminology applied to a concept known by a more generic term in the base.

5.1.3 An extension that defines new concepts must have its own target namespace distinct from the namespaces of its base taxonomies.

Concepts added to an extension taxonomy must reside within their own namespace(s), distinct from the namespace(s) of the base taxonomy and may have relationships with concepts in the base taxonomies and other concepts in the extension taxonomies.

Note that the rule only applies when the extension defines new concepts; in Example 41 the use of include allows both the “Spanish labels” and “English labels” extension taxonomies to share the same namespace, because neither extension defined any new concepts.

5.1.4 An extension needing a tuple that is consistent with the meaning of an existing tuple in the base must be defined in the extension taxonomy schema.

If a new content model is required to report content that is consistent with the meaning of another tuple that has already been defined then a new tuple must be created in the extension taxonomy to represent the new content model. Rule 3.4.3 also indicates that the similar-tuples arc should be used to document the relationship thus established.

This is a consequence of specification section 5.1.5 [XBRL], which prohibits the use of the XML Schema redefine construct. Without redefine, there is no way to change the definition of an existing tuple.

5.1.5 An extension should not add new concepts that would be equivalent to concepts in the base.

Every concept defined in a taxonomy may be used in another taxonomy simply by importing the schema that defines it.

A fundamental goal of XBRL is “to enhance the creation, exchange, and comparison of business reporting information” [XBRL]. Comparability of instances is enhanced when the same concept is represented by the same element.

Rule 2.1.1 states that “A taxonomy schema must define only one concept for each separately defined class of facts.” While impractical to enforce at the level of a DTS, it is nevertheless the underpinning of the current rule.

Prior to adding a new element in the extension, consideration should be given to the use of an existing concept in the base. Where such a concept exists in the base it should be imported and referenced by the extension. In these cases a new concept should not be created.

5.1.6 The concept-label, essence-alias, similar-tuples, concept-reference, and general-special relationships should not be prohibited.

Labels, references, and some definitional arcs are provided on elements in base linkbases to assist in defining concepts.

This rule is advisory, not mandatory, because sometimes an extension linkbase encompasses necessary amendments to the base. An example of a necessary amendment would be to incorporate a terminology change to an existing concept, as mandated by a newly issued accounting standard. To effect this change, the extension would prohibit the arcs that connect the concept to the base linkbase labels and references, and include in the extension linkbase new arcs with use="optional" connecting the concept to new labels and references. Even though it is allowed, this rule discourages prohibition of these particular arcs because prohibitions can alter the intended meaning of concepts from the base.

5.1.7 An extension may prohibit requires-element, parent-child, and summation-item arcs involving an existing concept drawn from the base taxonomy.

Arcs that supply general information to software applications is often of an intrinsically “default” nature, that is, it is to be used when there is no more specific information. Therefore these arcs may be prohibited by extension linkbases.

5.1.8 An extension may augment an existing concept in the base with new extended-type links having any role, and arcs having any arc role.

A FRTA compliant extension must comply with FRTA rules regarding permissible extended-type links, but it is not constrained in that respect by the absence of a given type of arc, resource, role, etc., in the base taxonomy. An extension, for example, is free to add similar-tuples arcs even if the base taxonomy had none.

Adding new arcs (as opposed to prohibiting existing ones) in an extension does not necessarily alter the original intent or meaning of the concept in the base taxonomy.

New labels or references must not modify the set of valid values for those concepts.

5.1.9 When an arc in an extension is equivalent to an arc in the base, the extension arc should have a higher priority than the base arc.

XBRL section 3.5.3.9.7.4 defines the meaning of “equivalent arcs” so that arcs which have different priority and use attribute values can still be equivalent. XBRL section 3.5.3.9.7.5 defines the rules to determine which one among a set of equivalent arcs in a DTS takes precedence. When equivalent arcs have the same value for the priority attribute appear, the behaviour is left application dependent, but since the rules ensure that such alternative arcs would be semantically indistinguishable, it actually doesn’t matter which arc the application chooses.

Taking these factors into consideration, this rule discourages the introduction of ineffectual arcs. Arcs are ineffectual when there is an arc with the same or higher priority (an arc with use="prohibited" always taking precedence over arcs with use="optional" when their priorities are the same):

Example 45. Ineffectual arcs.

Arc	From	To	Use	Priority	Why it is ineffectual
Given the following arcs:
1	A	B	optional	n
2	C	D	prohibited	m
The following arcs are ineffectual:
3	A	B	optional	Any value including n	Semantically identical to 1
4	A	B	prohibited	Less than n	Doesn’t prohibit 1
5	C	D	optional	Less than or equal to m	Prohibited by 2
6	C	D	prohibited	Any value including m	Semantically identical to 2

As a practical implementation, the author of an extension may choose to simply assign the priority for all arcs in the extension to be one greater than the highest priority of any arc in the base set.

5.1.10 For any concept in the base that cannot be used in any instance of the extension, a persisting extension should prohibit requires‑element, parent‑child, and summation‑item arcs involving it.

Sometimes an extension has specific reporting purpose for which instances could only use a subset of concepts in a DTS. For example, if an extension (such as for a tax form) requires reporting on a cash accounting, then concepts in the base taxonomy dependent on accrual accounting (and therefore excluded under cash accounting) should not appear in any instances of that extension. Note that this rule will usually not apply when the purpose of the extension is for instances of a single entity, since that would imply that the entity could not have reported that item or tuple. Just because an entity does not report a fact does not mean that the entity cannot report it.

XBRL does not provide any way to eliminate a concept from a taxonomy and therefore there is no way to prevent an obsolete item from appearing at top level in an instance. Such an extension taxonomy should prohibit the presentation, calculation and definition links from the base taxonomy that are not relevant to the reporting purpose of the extension. An XBRL processor consuming an instance containing such a fact is likely to ignore its presence so long as it passes XML Schema validation.

5.1.11 Any value of href in an extension where the intent is for that href to be equivalent to a prior use of href in the base should use identical fragment identifiers.

The matching of href attribute values to form matching pairs (as for example in arcs with use="prohibited" or in roleRef elements in different linkbases) is defined in XBRL section 3.5.3.9.7.4 as being based on identical XML fragments. Those fragments could be reached via entirely different URI’s relative to different bases (Section 3.5.1.5). While section 3.5.4 of the XBRL 2.1 Specification allows both #id and #element syntax for fragment identifiers, the present rule is suggesting that fragment identifiers should be used in a fashion that eases testing for equivalence.

Appendix A. References (non‑normative)

[IANA]	IANA country codes.
	http://www.iana.org/cctld/cctld-whois.htm

[IEEE]	IEEE Standard 610.12-1990
	IEEE Standard Glossary of Software Engineering Terminology, IEEE, 1990.
	http://www.ieee.org

[IFRS]	International Financial Reporting Standards (IFRS), General Purpose Financial Reporting for Profit-Oriented Entities, Incorporating Additional Requirements for Banks and Similar Financial Institutions (IFRS‑GP), 2005‑01‑15, Exposure Draft
	http://xbrl.iasb.org/int/fr/ifrs/gp/2005-01-15/

[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/

[LLLL]	The 'Lectric Law Library.
	http://www.lectlaw.com/

[LRR]	Walter Hamscher (editor), Hugh Wallis
	XBRL Link Role Registry, Candidate Recommendation of 2005-01-22
	http://www.xbrl.org/lrr/

[USFR]	US Financial Reporting Taxonomy Framework
	http://www.xbrl.org/taxonomy/us/TaxonomyFrameworkOverview.htm

[RFC2119]	Scott Bradner
	Key words for use in RFCs to Indicate Requirement Levels, March 1997
	http://www.ietf.org/rfc/rfc2119.txt

[RFC2141]	Ryan Moats
	RFC 2141: URN Syntax
	http://www.ietf.org/rfc/rfc2141.txt

[RFC2396]	T. Berners-Lee, R. Fielding, L. Masinter
	Uniform Resource Identifiers (URI): Generic Syntax
	http://www.ietf.org/rfc/rfc2396.txt

[SCHEMA-0]	World Wide Web Consortium.
	XML Schema Part 0: Primer.
	http://www.w3.org/TR/xmlschema-0/

[SCHEMA-1]	World Wide Web Consortium.
	XML Schema Part 1: Structures.
	http://www.w3.org/TR/xmlschema-1/

[SCHEMA‑2]	World Wide Web Consortium.
	XML Schema Part 2: Datatypes.
	http://www.w3.org/TR/xmlschema-2/

[TRP]	Calvert, P. and J. MacDonald
	XBRL Taxonomy Recognition Process, 19 November 2004
	http://www.xbrl.org/TaxonomyRecognition/

[XBRL]	Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis.
	Extensible Business Reporting Language (XBRL) 2.1 Specification with corrected errata dated 2005-04-25.
	http://www.xbrl.org/SpecRecommendations/

[XLINK]	Steve DeRose, Eve Maler, David Orchard
	XML Linking Language (XLink) Version 1.0.
	http://www.w3.org/TR/xlink/

[XML]	T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau.
	Extensible Markup Language (XML) 1.0 (Third Edition)
	http://www.w3.org/TR/REC-xml/

Appendix B. Schemas

The following are the schemas provided for the reference parts in this document. These are all normative. Non-normative versions (which should be identical to these) are also provided as separate files for convenience of users of the specification.

ref-2004-08-10.xsd

<documentation xml:lang="en">Publisher of the reference material, such as SEC, FASB, or AICPA.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Name refers to the specific publication. For example, "Statement of Financial Standards", "Statement of Position" or "IFRS". It does not include the number.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Number is used to record the actual number of the specific publication. For example, the number for FAS 133 would be 133.</documentation>

</annotation>

</element>

<documentation xml:lang="en">The issue date of the specific reference. The format is CCYY-MM-DD.</documentation>

</annotation>

</element>

<documentation xml:lang="en">For a publication that uses chapters, this part should be used to capture this information. Because chapters are not necessarily numbers, this is a string.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Article refers to a statutory article in legal material.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Notes can contain reference material; use this element when the note is published as a standalone document. There is a separate element for footnotes within other references.

</documentation>

</annotation>

</element>

<documentation xml:lang="en">Section is used to capture information typically captured in sections of legislation or reference documents.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Subsection is a subsection of the section part.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Paragraph is used to refer to specific paragraphs in a document.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Subparagraph of a paragraph.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Sub component of a sub paragraph.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Subcomponent of a clause in a paragraph.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Refers to the name of an Appendix, which could be a number or text.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Example captures examples used in reference documentation; there is a separate element for Exhibits.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Page number of the reference material.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Exhibit refers to exhibits in reference documentation; examples have a separate element.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Footnote is used to reference footnotes that appear in reference information.</documentation>

</annotation>

</element>

<documentation xml:lang="en">In some reference material individual sentences can be referred to, and this element allows them to be referenced.</documentation>

</annotation>

</element>

<documentation xml:lang="en">Full URI of the reference such as "http://www.fasb.org/fas133".</documentation>

</annotation>

</element>

<documentation xml:lang="en">Date that the URI was valid, in CCYY-MM-DD format.</documentation>

</annotation>

</element>

</schema>

Appendix C. Index of all rules (non-normative)

A financial reporting taxonomy that receives “Approved” status from XBRL International must conform to the rules of this architecture, and conversely, the architecture must be used during XBRL International’s review of taxonomies that are candidates for Approved status [TRP]. Table 6 below shows an index of the entire list of rules documented here.

Table 6. Index of all rules.

2.1.1 A taxonomy schema must define only one concept for each separately defined class of facts. 12

2.1.2 Contextual and measurement information in XBRL instances must not result in different elements in a taxonomy. 14

2.1.3 Concepts’ meanings must not depend on their position within an instance. 15

2.1.4 Concept names should adhere to the LC3 convention. 15

2.1.5 Element declarations for concepts must contain an “id” attribute whose value begins with the recommended namespace prefix of the taxonomy, followed by an underscore, followed by the element name. 17

2.1.6 The value of the “nillable” attribute should be true for all concepts. 17

2.1.7 An “element” element may include any of the other XML Schema attributes that can be used on a global element syntax definition. 17

2.1.8 A concept must not prohibit the id attribute inherited from a base type. 17

2.1.9 All documentation of a concept must be contained in XBRL linkbases. 18

2.1.10 A concept must have a label with the standard label role. 18

2.1.11 All concepts within a taxonomy schema should have a unique label for the standard or verbose role in each language used. 18

2.1.12 Each concept must have documentation in either the label or reference linkbase. 18

2.1.13 Labels should have a correspondence to the meaning of the element. 19

2.1.14 There must not be internal structure in label text that requires software to draw inferences about the meaning of the label. 19

2.1.15 Words must be spelled consistently throughout the labels in a linkbase. 19

2.1.16 Labels should have a consistent style of phrasing. 19

2.1.17 Non-alphabetic characters, if used, should be used consistently in labels. 20

2.1.18 A concept must not have more than one label in a base set for each combination of language and label role in the DTS whose starting point is the schema defining that concept. 20

2.1.19 All components of references to authoritative literature documenting concepts must be contained in appropriately defined reference parts. 21

2.1.20 Reference parts should include the name of the standard or other enactment, and sections, clauses or paragraphs as appropriate. 21

2.1.21 References must use elements in the substitution group of the XBRL linkbase “part” element from the namespace http://www.xbrl.org/2004/ref. 21

2.1.22 Reference part element definitions must provide a documentation element containing a human readable explanation. 24

2.2.1 XML Schema types should be used to constrain the content of items. 24

2.2.2 Different values for an item must not result in different elements. 25

2.2.3 Monetary concept declarations corresponding to accounting credit or debit balances (asset, liability, equity, revenue, expenses) must use the balance attribute. 25

2.2.4 A numeric item declaration without a balance attribute should have documentation for the item indicating its expected sign, and where the item represents a change in an underlying concept, increases must be represented as a positive number. 25

2.2.5 Numeric items should not be percentages. 26

2.2.6 Each item must only be asserted over either a duration or at an instant in time. 27

2.2.7 Variations on the same concept that can be measured either over a period or at an instant in time must be represented by separate concepts. 27

2.2.8 Sibling concepts in the content model of a tuple may have different values of the periodType attribute. 27

2.2.9 Numeric concepts representing a balance or to be captured at a specific point in time must have a periodType of “instant”. 27

2.2.10 The beginning balance, the ending balance, and any adjusted balances of an item for a period must be represented as a single item. 28

2.2.11 Numeric concepts not measurable at a point in time must have a periodType of “duration”. 28

2.2.12 Non-numeric concepts that are stated as at a specified date, but apply to an entire period, must have a periodType of “duration”. 28

2.2.13 Non-numeric concepts that are only true “as of” or “as at” a specific date, must have a periodType of “instant”. 29

2.2.14 All other non-numeric concepts, such as accounting policies and disclosures, must have periodType of “duration”, whether or not they relate to balances or to a period. 29

2.3.1 Tuples must be used to associate concepts that derive their meaning from each other. 30

2.3.2 When instances may contain multiple values of the same item within the same context and having the same units, a tuple must be used. 33

2.3.3 Numbered sequences of items to accommodate multiple values of the same item must not be used. 33

2.3.4 Tuples should not be used to represent segments, units, entities, periods, or scenarios. 33

2.3.5 Tuple content models must enforce the constraints on their contents that are expressed in their labels and references. 34

2.3.6 The content model of a tuple should not contain a reference to itself nor any possible ancestor. 34

2.3.7 Tuple content models must not use the “all” compositor. 35

2.3.8 Tuple definitions must not have the periodType attribute. 35

2.3.9 Tuple content models must include an optional local attribute with name ‘id’ and type ID. 35

3.1.1 A linkbase must not include any link elements (simple, resource, extended, or arc) not in an XBRL module or in the XBRL 2.1 Specification. 36

3.1.2 An arc must have only its standard or LRR approved arc role. 36

3.1.3 The label and reference elements must have only their standard or LRR approved resource roles. 36

3.1.4 An extended-type link role must have no processing semantics other than specified by XBRL. 36

3.1.5 A schema must not define a role type that duplicates a definition in the DTS whose starting point is the schema defining that role type. 37

3.1.6 Roles and arc roles from XBRL, XBRL modules, and the LRR should be used in preference to defining new roles. 37

3.1.7 All arcs within an extended-type link must have the same arc role. 37

3.1.8 Each extended-type link must have a nonempty role attribute. 37

3.1.9 Extended-type links that are not necessarily processed together by consuming applications must have distinct role values. 37

3.1.10 Any role type definition for an extended-type link in a persisting DTS must have a human-readable explanation in its definition element. 38

3.1.11 The role URI in a roleType element must be an LRR approved role or begin with the same scheme and authority parts as the target namespace of the taxonomy schema where it appears. 38

3.1.12 The role URI in a roleType element should end with “role” and a human-readable name. 38

3.1.13 All arcs whose source and target both refer to concepts must specify an order attribute. 39

3.1.14 Two relationships defined by arcs in the same base set with the “use” attribute having the value “optional”, having concepts as targets and sharing the same “from” concept should have distinct values for the “order” attribute. 39

3.1.15 All arc-type elements may have use and priority attribute values. 39

3.1.16 All extended-type, locator-type, arc-type, and resource-type elements may have a title attribute. 39

3.1.17 Taxonomy creators may provide show and actuate attribute values on linkbase arcs. 40

3.2.1 A DTS may contain any number of sets of extended-type links partitioned by role. 40

3.2.2 A concept meant to be ordered among its siblings must have a parent-child presentation relationship from its parent concept. 42

3.2.3 Presentation parent-child relationships having the same parent and child in extended links with the same role should provide preferred labels. 42

3.2.4 A DTS should provide parent-child presentation relationships intended for users of the taxonomy. 42

3.2.5 Abstract elements may be used as a heading to group other concepts for presentation. 42

3.2.6 For every tuple there should be at least one tree of presentation parent-child relationships in which every concept that can appear as a descendant of the tuple in an instance appears as a descendant of the tuple in that presentation tree, and there should not exist any tree of presentation parent-child relationships in which a non-abstract concept that cannot appear as a descendant of the tuple in an instance appears as a descendant of the tuple in that presentation tree. 45

3.2.7 The parent-child relationships of a movement analysis must refer to a single item for the beginning, adjusted and ending balance values, each with a different preferred label. 46

3.3.1 All concepts in a DTS which have an additive relationship in all equal contexts should have calculation relationships in that DTS. 50

3.3.2 Calculation relationships that represent alternative summations for the same item must be in extended-type links with distinct roles. 51

3.3.3 Taxonomies should define an extensive set of subtotal concepts to limit the extent to which XBRL instances requiring such sub-totals need to create report-specific extensions. 53

3.3.4 Calculation relationships must be defined between items being totalled in a tuple. 54

3.3.5 The declarations of the source and target concepts of a summation-item relationship must have identical values of the periodType attribute. 56

3.3.6 The source and target concepts of a summation-item relationship must be distinct. 56

3.4.1 Equivalent items in different taxonomy schemas within a DTS should be indicated by essence-alias relationships. 56

3.4.2 Items that fall into the same category or family should be related using the general-special relationship. 57

3.4.3 A tuple having the same reporting purpose as a tuple in a different taxonomy within the same DTS should have a similar-tuples relationship to that other tuple. 57

3.4.4 The requires-element relationship must not be used when a tuple construct can adequately represent the same constraint. 58

4.2.1 A schema document must contain only declarations of reference parts OR declarations of concepts, roles and arc roles OR declarations that are not concepts and not reference parts. 60

4.2.2 Taxonomy schemas must be defined in XML documents in which the XML Schema “schema” element appears once only as the root element. 61

4.2.3 Taxonomy schemas must not contain embedded linkbases. 61

4.2.4 Taxonomy schemas must declare elementFormDefault to be “qualified,” attributeFormDefault must have the value “unqualified”, and the “form” attribute must not appear on element and attribute declarations. 61

4.2.5 A linkbaseRef element must have an xlink:role attribute value. 61

4.2.6 All extended-type links in a single linkbase must have the same namespace and local name. 61

4.2.7 A label linkbase should only contain labels defined in a single language. 61

4.2.8 Any number of taxonomy schemas may contain links to select schemas and linkbases to enable discovery of unique DTS’s. 62

4.2.9 A taxonomy schema should not contain import or include elements not strictly needed for XML Schema validity. 63

4.2.10 A DTS should include scenario element definitions that are relevant to the reporting standard upon which it is based, unless such elements already exist in a recommended taxonomy. 64

4.2.11 Every schema in a DTS must define a non-empty targetNamespace attribute value. 64

4.3.1 Persisting taxonomies must use a targetNamespace that is an XBRL International style URI for all final versions of their taxonomies. 64

4.3.2 Each unique taxonomy schema target namespace must have one and only one namespace prefix of one to twelve characters, which will be its recommended namespace prefix. 66

4.3.3 A taxonomy that supersedes an existing version of itself must use the date portion of its namespace URI to identify the new version. 66

4.3.4 Taxonomy file names should use the recommended namespace prefix and identifying date in their names. 66

5.1.1 An extension must not modify the meaning of concepts in the base. 67

5.1.2 Word choice in the labels of an extension should be consistent with the terminology used in its base. 67

5.1.3 An extension that defines new concepts must have its own target namespace distinct from the namespaces of its base taxonomies. 67

5.1.4 An extension needing a tuple that is consistent with the meaning of an existing tuple in the base must be defined in the extension taxonomy schema. 68

5.1.5 An extension should not add new concepts that would be equivalent to concepts in the base. 68

5.1.6 The concept-label, essence-alias, similar-tuples, concept-reference, and general-special relationships should not be prohibited. 68

5.1.7 An extension may prohibit requires-element, parent-child, and summation-item arcs involving an existing concept drawn from the base taxonomy. 69

5.1.8 An extension may augment an existing concept in the base with new extended-type links having any role, and arcs having any arc role. 69

5.1.9 When an arc in an extension is equivalent to an arc in the base, the extension arc should have a higher priority than the base arc. 69

5.1.10 For any concept in the base that cannot be used in any instance of the extension, a persisting extension should prohibit requires‑element, parent‑child, and summation‑item arcs involving it. 70

5.1.11 Any value of href in an extension where the intent is for that href to be equivalent to a prior use of href in the base should use identical fragment identifiers. 70

Table 7 below shows an assessment of each rule as to:

1. whether it can be fully tested by automated means (auto)

2. whether the rule is mandatory (MUST),

3. whether the rule applies only to persisting components (Persist),

4. whether the recommended testing would be best done (Approach) by:

a. in the case of an automated test,

i. a FRTA specific test (auto) or

ii. a test already part of XBRL validation (XBRL);

b. in the case of a non-automatable test,

i. a test that a human reviewer could be assisted with (Manual), or

ii. a test that does not need to be performed at all since it does not forbid any usage (moot).

5. whether there is a suggested procedure (Remarks).

Software applications that test taxonomies for FRTA compliance in an automated fashion should only signal FRTA violations if they are marked as automatically testable in Table 7. Other vendor-specific checks, such as for partially testable FRTA rules, should be clearly marked as such with a distinct error code or warning level. Thus, the overall status of FRTA compliance would be signalled as “failed”, “invalid”, and so forth, only if there is a violation of a FRTA violation marked as automatically testable.

Table 7. Rule testability

Rule	Text	MUST	Persist	Approach	Remarks
2.1.1	A taxonomy schema must define only one concept for each separately defined class of facts.	Yes	No	Manual	Selectors look for essence-alias arcs (indicators of redundancy) and elements with similar or identical labels.
2.1.2	Contextual and measurement information in XBRL instances must not result in different elements in a taxonomy.	Yes	No	Manual	Selectors could look for ISO4217 codes in elements, generate a list of all terms used in names and check against dictionary.
2.1.3	Concepts’ meanings must not depend on their position within an instance.	Yes	No	Manual	Select for items that appear in more than one tuple content model.
2.1.4	Concept names should adhere to the LC3 convention.	No	No	Manual	Select any element names that may violate an LC3 rule.
2.1.5	Element declarations for concepts must contain an “id” attribute whose value begins with the recommended namespace prefix of the taxonomy, followed by an underscore, followed by the element name.	Yes	No	Auto
2.1.6	The value of the “nillable” attribute should be true for all concepts.	No	No	Manual
2.1.7	An “element” element may include any of the other XML Schema attributes that can be used on a global element syntax definition.	No	No	XBRL	Redundant with XBRL validation
2.1.8	A concept must not prohibit the id attribute inherited from a base type.	Yes	No	Auto
2.1.9	All documentation of a concept must be contained in XBRL linkbases.	Yes	No	Manual	Check that the element declaration does not use the documentation element.
2.1.10	A concept must have a label with the standard label role.	Yes	No	Auto
2.1.11	All concepts within a taxonomy schema should have a unique label for the standard or verbose role in each language used.	No	No	Auto	Sort all labels (by descending priority) and verify uniqueness.
2.1.12	Each concept must have documentation in either the label or reference linkbase.	Yes	No	Manual	List documentation for each concept and flag empty or short entries.
2.1.13	Labels should have a correspondence to the meaning of the element.	No	No	Manual	Look for elements whose name differs from the standard label.
2.1.14	There must not be internal structure in label text that requires software to draw inferences about the meaning of the label.	Yes	No	Manual	Show element names that indicate possible attempts to assign semantics to parts of the name.
2.1.15	Words must be spelled consistently throughout the labels in a linkbase.	Yes	No	Manual	Split labels into constituents for analysis.
2.1.16	Labels should have a consistent style of phrasing.	No	No	Manual	Sort labels with similar roles and look for inconsistencies.
2.1.17	Non-alphabetic characters, if used, should be used consistently in labels.	No	No	Manual	Inspect labels with non alphabetic, non whitespace characters.
2.1.18	A concept must not have more than one label in a base set for each combination of language and role in the DTS whose starting point is the schema defining that concept.	Yes	No	Auto	Analyze for duplicates
2.1.19	All components of references to authoritative literature documenting concepts must be contained in appropriately defined reference parts.	Yes	No	Manual	Select for empty <reference> elements, which are clearly not "appropriate", or mixed content.
2.1.20	Reference parts should include the name of the standard or other enactment, and sections, clauses or paragraphs as appropriate.	No	No	Manual	Select for lengthy textual content in <reference> child elements, an indicator that the material itself, rather than a reference, is included.
2.1.21	References must use elements in the substitution group of the XBRL linkbase “part” element from the namespace http://www.xbrl.org/2004/ref.	Yes	No	Manual	Select elements in the substitution group of 'part' and compare to list of ref schema elements.
2.1.22	Reference part element definitions must provide a documentation element containing a human readable explanation.	Yes	No	Manual	Read the documentation elements.
2.2.1	XML Schema types should be used to constrain the content of items.	No	No	Manual	Look for elements using only basic XBRL item types without restrictions.
2.2.2	Different values for an item must not result in different elements.	Yes	No	Manual	Look for common misuses such as matching "profit" and "loss" elements.
2.2.3	Monetary concept declarations corresponding to accounting credit or debit balances (asset, liability, equity, revenue, expenses) must use the balance attribute.	Yes	No	Manual	Show items in presentation order, higlighting those possibly missing attributes.
2.2.4	A numeric item declaration without a balance attribute should have documentation for the item indicating the expected sign of the item, and where the item represents a change in an underlying concept, increases must be represented as a positive number.	Yes	No	Manual	For numeric items without a balance, show the documentation.
2.2.5	Numeric items should not be percentages.	No	No	Manual	Show numeric item element names and standard labels.
2.2.6	Each item must only be asserted over either a duration or at an instant in time.	Yes	No	XBRL	Redundant with XBRL validation
2.2.7	Variations on the same concept that can be measured either over a period or at an instant in time must be represented by separate concepts.	Yes	No	Manual
2.2.8	Sibling concepts in the content model of a tuple may have different values of the periodType attribute.	No	No	Moot
2.2.9	Numeric concepts representing a balance or to be captured at a specific point in time must have a periodType of “instant”.	Yes	No	Manual	Show numeric items with period Type instant
2.2.10	The beginning balance, the ending balance, and any adjusted balances of an item for a period must be represented as a single item.	Yes	No	Manual	Remove danger words "beginning, begin, starting, start, ending, end, final" then compare for redundant element names.
2.2.11	Numeric concepts not measurable at a point in time must have a periodType of “duration”.	Yes	No	Manual	Show numeric items with period Type duration.
2.2.12	Non-numeric concepts that are stated as at a specified date, but apply to an entire period, must have a periodType of “duration”.	Yes	No	Manual	Show non-numeric items with period Type instant; these are probably errors.
2.2.13	Non-numeric concepts that are only true “as of” or “as at” a specific date, must have a periodType of “instant”.	Yes	No	Manual	Show non-numeric items with period Type instant and "as of" or "at" constituents in their label or element name; these are probably errors.
2.2.14	All other non-numeric concepts, such as accounting policies and disclosures, must have periodType of “duration”, whether or not they relate to balances or to a period.	Yes	No	Manual	Show non-numeric items with period Type instant; these are probably errors.
2.3.1	Tuples must be used to associate concepts that derive their meaning from each other.	Yes	No	Manual	Select tuples and their children for inspection
2.3.2	When instances may contain multiple values of the same element within the same context, a tuple must be used.	Yes	No	Manual	Sort items and tuples by name and look for "runs".
2.3.3	Numbered sequences of items to accommodate multiple values of the same item must not be used.	Yes	No	Manual	Sort items and tuples by name and look for "runs".
2.3.4	Tuples should not be used to represent segments, units, entities, periods, or scenarios.	No	No	Manual	Select tuples and their children for inspection
2.3.5	Tuple content models must enforce the constraints on their contents that are expressed in their labels and references.	Yes	No	Manual	Compare tuple documentation to content models.
2.3.6	The content model of a tuple should not contain a reference to itself nor any possible ancestor.	No	No	Auto
2.3.7	Tuple content models must not use the “all” compositor.	Yes	No	Auto
2.3.8	Tuple definitions must not have the periodType attribute.	Yes	No	XBRL	Redundant with XBRL validation
2.3.9	Tuple content models must include an optional local attribute with name ‘id’ and type ID.	Yes	No	Auto
3.1.1	A linkbase must not include any link elements (simple, resource, extended, or arc) not in an XBRL module or in the XBRL 2.1 Specification.	Yes	No	Auto
3.1.2	An arc must have only its standard or LRR approved arc role.	Yes	No	Auto
3.1.3	The label and reference elements must have only their standard or LRR approved resource roles.	Yes	No	Auto
3.1.4	An extended-type link role must have no processing semantics other than specified by XBRL.	Yes	No	Manual	Select nonstandard roles for inspection
3.1.5	A schema must not define a role type that duplicates a definition in the DTS whose starting point is the schema defining that role type.	Yes	No	Auto
3.1.6	Roles and arc roles from XBRL, XBRL modules, and the LRR should be used in preference to defining new roles.	No	No	Manual
3.1.7	All arcs within an extended-type link must have the same arc role.	Yes	No	Auto
3.1.8	Each extended-type link must have a nonempty role attribute.	Yes	No	XBRL	Redundant with XBRL validation
3.1.9	Extended-type links that are not necessarily processed together by consuming applications must have distinct role values.	Yes	No	Manual
3.1.10	Any role type definition for an extended-type link in a persisting DTS must have a human-readable explanation in its definition element.	Yes	Yes	Manual	Select all role definitions for manual inspection
3.1.11	The role URI in a roleType element must be an LRR approved role or begin with the same scheme and authority parts as the target namespace of the taxonomy schema where it appears.	Yes	No	Auto	Compare target namespace attribute content with all role type definitions.
3.1.12	The role URI in a roleType element should end with “role” and a human-readable name.	No	No	Manual
3.1.13	All arcs whose source and target both refer to concepts must specify an order attribute.	Yes	No	Auto
3.1.14	Two relationships defined by arcs in the same base set with the “use” attribute having the value “optional”, having concepts as targets and sharing the same “from” concept should have distinct values for the “order” attribute.	No	No	Auto
3.1.15	All arc-type elements may have use and priority attribute values.	No	No	Moot
3.1.16	All extended-type, locator-type, arc-type, and resource-type elements may have a title attribute.	No	No	Moot
3.1.17	Taxonomy creators may provide show and actuate attribute values on linkbase arcs.	No	No	Moot
3.2.1	A DTS may contain any number of sets of extended-type links partitioned by role.	No	No	Moot
3.2.2	A concept meant to be ordered among its siblings must have a parent-child presentation relationship from its parent concept.	Yes	No	Manual
3.2.3	Presentation parent-child relationships having the same parent and child in extended links with the same role should provide preferred labels.	No	No	Auto
3.2.4	A DTS should provide parent-child presentation relationships intended for users of the taxonomy.	No	No	Manual
3.2.5	Abstract elements may be used as a heading to group other concepts for presentation.	No	No	Moot	Does not say that they may ONLY be used this way.
3.2.6	For every tuple there SHOULD be at least one tree of presentation parent-child relationships in which every concept that can appear as a descendant of the tuple in an instance appears as a descendant of the tuple in that presentation tree, and there SHOULD NOT exist any tree of presentation parent-child relationships in which a non-abstract concept that cannot appear as a descendant of the tuple in an instance appears as a descendant of the tuple in that presentation tree.	No	No	Auto
3.2.7	The parent-child relationships of a movement analysis must refer to a single item for the beginning, adjusted and ending balance values, each with a different preferred label.	Yes	No	Manual
3.3.1	All concepts in a DTS which have an additive relationship in all equal contexts should have calculation relationships in that DTS.	No	No	Manual
3.3.2	Calculation relationships that represent alternative summations for the same item must be in extended-type links with distinct roles.	Yes	No	Manual	Show the likely violations, to be reviewed using domain knowledge.
3.3.3	Taxonomies should define an extensive set of subtotal concepts to limit the extent to which XBRL instances requiring such sub-totals need to create report-specific extensions.	No	No	Manual	Manual - needs domain knowledge
3.3.4	Calculation relationships must be defined between items being totalled in a tuple.	Yes	No	Manual
3.3.5	The declarations of the source and target concepts of a summation-item relationship must have identical values of the periodType attribute.	Yes	No	Auto
3.3.6	The source and target concepts of a summation-item relationship must be distinct.	Yes	No	Auto
3.4.1	Equivalent items in different taxonomy schemas within a DTS should be indicated by essence-alias relationships.	No	No	Manual	Select all essence-alias arcs where sources and destinations are in different schemas. A very large number suggests a problem.
3.4.2	Items that fall into the same category or family should be related using the general-special relationship.	No	No	Manual	Show only general-special arcs in definition view, highlight items having no generalisation.
3.4.3	A tuple having the same reporting purpose as a tuple in a different taxonomy within the same DTS should have a similar-tuples relationship to that other tuple.	No	No	Manual	Show only similar-tuple arcs where source and destination are in different schemas
3.4.4	The requires-element relationship must not be used when a tuple construct can adequately represent the same constraint.	Yes	No	Manual	Select all requires-element arcs for manual inspection
4.2.1	A schema document must contain only declarations of reference parts OR declarations of concepts, roles and arc roles, OR declarations that are not concepts and not reference parts.	Yes	No	Auto	Applies to each schema
4.2.2	Taxonomy schemas must be defined in XML documents in which the XML Schema “schema” element appears once only as the root element.	Yes	No	Auto
4.2.3	Taxonomy schemas must not contain embedded linkbases.	Yes	No	Auto
4.2.4	Taxonomy schemas must declare elementFormDefault to be “qualified,” attributeFormDefault must have the value “unqualified”, and the “form” attribute must not appear on element and attribute declarations.	Yes	No	Auto
4.2.5	A linkbaseRef element must have an xlink:role attribute value.	Yes	No	Auto
4.2.6	All extended-type links in a single linkbase must have the same namespace and local name.	Yes	No	Auto
4.2.7	A label linkbase should only contain labels defined in a single language.	No	No	Auto
4.2.8	Any number of taxonomy schemas may contain links to select schemas and linkbases to enable discovery of unique DTS’s.	No	No	Moot
4.2.9	A taxonomy schema should not contain import or include elements not strictly needed for XML Schema validation.	No	No	Manual
4.2.10	A DTS should include scenario element definitions that are relevant to the reporting standard upon which it is based, unless such elements already exist in a recommended taxonomy.	No	No	Manual
4.2.11	Every schema in a DTS must define a non-empty targetNamespace attribute value.	Yes	No	Auto
4.3.1	Persisting taxonomies must use a targetNamespace that is an XBRL International style URI for all final versions of their taxonomies.	Yes	No	Manual
4.3.2	Each unique taxonomy schema target namespace must have one and only one namespace prefix of one to twelve characters, which will be its recommended namespace prefix	Yes	No	Auto	Human review of namepace prefix chosen.
4.3.3	A taxonomy that supersedes an existing version of itself must use the date portion of its namespace URI to identify the new version.	Yes	No	Manual
4.3.4	Taxonomy file names should use the recommended namespace prefix and identifying date in their names.	No	No	Manual	Show all namespaces used
5.1.1	An extension must not modify the meaning of concepts in the base.	Yes	No	Manual	Manual inspection - instances MUST be XBRL Valid in two commercial tools
5.1.2	Word choice in the labels of an extension should be consistent with the terminology used in its base.	No	No	Manual	Select all labels and other linkbase parts that match prohibiting arcs
5.1.3	An extension that defines new concepts must have its own target namespace distinct from the namespaces of its base taxonomies.	Yes	No	Manual	Manual inspection - domain knowledge needed
5.1.4	An extension needing a tuple that is consistent with the meaning of an existing tuple in the base must be defined in the extension taxonomy schema.	Yes	No	Manual	Manual inspection - technical knowledge needed
5.1.5	An extension should not add new concepts that would be equivalent to concepts in the base.	No	No	Manual	Select all tuples that have children in their content models taken from other schemas than where they themselves are defined.
5.1.6	The concept-label, essence-alias, similar-tuples, concept-reference, and general-special relationships should not be prohibited.	No	No	Auto
5.1.7	An extension may prohibit requires-element, parent-child, and summation-item arcs involving an existing concept drawn from the base taxonomy.	No	No	Moot
5.1.8	An extension may augment an existing concept in the base with new extended-type links having any role, and arcs having any arc role.	No	No	Moot
5.1.9	When an arc in an extension is equivalent to an arc in the base, the extension arc should have a higher priority than the base arc.	Yes	No	Auto	Match arcs with the same source and destination and ensure none have identical priorities
5.1.10	For any concept in the base that cannot be used in any instance of the extension, a persisting extension should prohibit requires-element, parent-child, and summation-item arcs involving it.	No	Yes	Manual	Show elements that have no arcs to or from them. Even if a tool generated the removal this must be checked.
5.1.11	Any value of href in an extension where the intent is for that href to be equivalent to a prior use of href in the base should use identical fragment identifiers.	No	No	Manual	Select all prohibiting arcs that do not match any existing arc.

Appendix D. 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 (http://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 (http://www.xbrl.org/legal).

Appendix E. Document history and acknowledgments (non‑normative)

This document could not have been written without the contribution of many people. The participants in the XBRL International Domain Working Group (DWG), public commentators, and personal advisors have all played a significant role. The DWG is chaired by Josef Macdonald, IASC Foundation, and vice chaired by Marc van Hilvoorde, PricewaterhouseCoopers. Contributing members of the working group include Don Bruey, Creative Solutions; Peter Calvert, Calvert Consulting Ltd.; Eric E. Cohen, PricewaterhouseCoopers; Tom Egan, Standard Chartered; George Farkas, XBI Software; Yuji Furusho, Fujitsu; Jason Golieb, PricewaterhouseCoopers; Morikuni Hasegawa, Hitachi; Jeremy Lebrett, Reuters; Jeff Naumann, US Securities and Exchange Commission; Yossef Newman, Deloitte; David Prather, IASC Foundation; Campbell Pryde, KPMG; Mark Schnitzer, Morgan Stanley; Miho Saito, PricewaterhouseCoopers; Geoff Shuetrim, KPMG; Chris Simmons, DecisionSoft; Matt Slavin, Ernst & Young; Tom Taylor, CICA; Alan Teixeira, ICANZ; John Turner, Core Filings; Paul Warren, DecisionSoft; Phil Walenga, UBmatrix; Hugh Wallis, Standard Dimensions; Gary Wicklund, Capricorn Research.

2003-03-26	Hoffman	First draft of document prepared, preliminary summary of discussions.
2003-03-27	Naumann	Edits
2003-03-29	Hamscher	Edited all sections to indicate the proposed normative status of this architecture and follow XBRL International documentation conventions.
2003-04-03	Schnitzer and Turner	Edits incorporated.
2003-04-11	Hoffman	Built out details for sections.
2003-05-04	Hamscher	Used existing material from Jeff Naumann and Charles Hoffman, and reorganised entire document into the four architecture layers, one per section. Added examples, new figures, tables, tables of contents and cross referencing. Added cross-references to Peter Calvert’s Domain Topics list and interspersed notes on pending issues. The extensions layer material borrows selectively but crucially from unpublished papers by Charles Hoffman, Josef MacDonald, Jeffrey Naumann, Alan Teixiera, and the KPMG Global Services Team.
2003-05-12	Hamscher	Clarified audience intent, role of outer tuple in the first table example. Moved observations about Specification constraints back into XBRL 2.1 Draft comments. Changed all figures to use consistent arc direction. Rewrote section on contexts to generalise the point that concepts must not depend on specific entity names, periods, etc., but without writing the rule as if it depended on the element name. Changed example showing use of general‑special arc to link concepts that differ in measurement, to one which shows alternative calculation methods. Added the sample use of a discriminator in a tuple and footnote regarding primary keys. Added footnote about undirected cycles. Added figures showing minimal and maximal schemas and the relationships of taxonomies, encompassing both IAS-style and NAFR-style inheritance. Incorporated suggested edits from George Farkas, Charlie Hoffman, Jeff Naumann and Trevor Pyman.
2003-06-09	Hamscher	After a round of internal feedback, made many small editorial fixes. Added a definition of the scope of financial reporting. Added the classified and unclassified balance sheet example. Added improved movement analysis examples from Charlie Hoffman and added movement analysis with adjustment. Incorporated a large number of comments from Peter Calvert. Copied in the LC3 element name convention as normative, and changed all figures and examples to conform to the naming convention. Edited the tuples description to include explanation of the mechanisms; also changed textual examples showing instances into figures generated from a schema development tool. Added an example of extending a tuple. Raised the profile of the general principle that XBRL taxonomies should not provide more granularity than the accounting standards they represent. Reordered the set of modularity guidelines and rewrote to indicate the need to recognise the need for compromise in any given situation. Added suggestion about arc priorities from David vun Kannon. Added suggestion about modularity and other issues from Charlie Hoffman. Added material detailing the URI components. Added disclaimers about scenario and entity identifiers to the material about contexts.
2003-07-07	Hoffman	Fixed typos. Added various comments to document as issues which need to be discussed. Incorporated Peter Calvert edits to the previous version of the document. Incorporated George Farkas comments on the previous version into this document. Removed references to Excel spreadsheet.
2003-08-27	Shuetrim	Thorough editorial review. Deleted all material relating to constructs now removed from the XBRL 2.1 Draft. Removed all criteria for assessing appropriate modularizations. Reduced all criteria for appropriate usage. Added new prohibition against having tuples as presentation parents. Removed all criteria for assessing different approaches to adding and removing calculation and other arcs.
2003-09-01	Hamscher	Edits for clarity in sections relating to concepts; repairs to diagrams, removal of new constraints pending wider discussion.
2003-10-13	Hamscher	Reorganised the introductory chapter to separate goals, scope and approach. Rewrote chapter 2 and part of chapter 3 to be a series of rules. Included section on modularity guidelines. Redrew examples to take the extended-type link roles into account. Included section on period types.
2003-10-16	Hamscher	Rewrote the Relationship layer rules incorporating work team feedback and factored rules. Promoted rules and text applicable to all linkbases into the first set of Relationship Layer rules. Rewrote the DTS and Extensions Layer chapters reorganising material into rules and promoting the more general rules to the early parts of the chapter and in some cases to earlier chapters. Collapsed several Extensions Layer rules into three rules and a table. Incorporated material from Josef MacDonald and Geoff Shuetrim relating to modularity goals for the Extensions Layer. Created new figures for DTS examples. Added rule pointing to the GCD. Added rule indicating the need to use the priority attribute to disambiguate alternative labels, references, etc. Added rule to indicate how the Date portion of the URI is to be used. Added rule that the assumed scenario value is “actual.” Changed default namespace prefix rule to allow four-character names. Incorporated fixes and suggestions from reviews by Eric E. Cohen and Charles Hoffman, with introduction of several cross-references, new section on implications for instances of the concept rules, removal of spurious rule relating to label capitalisation, movement of period type discussion section into individual rules, repair of figures to accommodate change in standard role and arc role names.
2003-10-20	Hamscher	Incorporated feedback from Josef MacDonald and Charles Hoffman. Changed document name. Added IEEE reference and explanation of the term “architecture” versus “engineering” in the context of software systems as an end note. Removed rule relating to dateTime items, removed one exception from the non-numeric text period type rule, and folded rules regarding dateTime elements into a related rule. Added new instance guidance regarding the maximum duration of contexts, in lieu of a more lengthy discussion of context proliferation and contiguous periods. Clarified wording of rule requiring use of tuples instead of elements with numeric suffixes. Edited wording in instance guidance relating to the “actual” interpretation in the absence of a scenario. Removed term “extended link” in favour of “extended-type link” where generic, or replaced with the name of the specific link type in context. Reformatted reference example provided by Josef MacDonald. Reduced depth of table of contents to be more readable. Added additional definitions and used icons for definitions. Converted pasted bitmaps showing financial statements into regular tables and made other formatting changes to keep relevant materials together. Fixed example that had incorrect figure pasted in. Promoted footnotes into inline text where still relevant. Removed editorial notes. Fixed bug in Legend. Removed obsolete references and changed references to unpublished documents into acknowledgments of authors’ contributions. Fixed bug in “…/role/standard” occurrences. Removed word “semantics” in favour of “meaning”, with explanation in context. Fixed bug in example of label usage. Rewrote the rule regarding reference parts to eliminate redundancy with XBRL 2.1 specification. Added examples of non-numeric concepts from the SEC-CERT taxonomy. Clarified wording of the tuple presentation parent-child arcs rule. Resolved inconsistencies relating to prohibitions on duplicate concepts and use of the essence-alias arc. Fixed rule that indicated qualified or unqualified values for taxonomy schema elements and attributes. Relaxed the wording of rule regarding the GCD and other recommended taxonomies, to allow essence-alias relations.
2003-10-30	Hamscher	Incorporation of George Farkas’ comments and final polishing for release as public working draft.
2003-11-19	Hamscher	Incorporation of clarifications suggested by Tom Egan and Trevor Pyman.
2003-12-14	Hoffman	Updated to reflect XBRL 2.1 Candidate Recommendation 3 and to correct typos and other errors.
2003-12-29	Hamscher	Updated to become Draft Candidate Recommendation by reflecting XBRL 2.1 Recommendation details, and reflect public working draft feedback and Domain working group resolutions as follows. Modified language relating to status of the document. Added clarification of the label consistent phrasing rule. Changed the example of movement analysis so as to clarify that the same item is used for beginning and ending balances. Added rule in the section about implications for instances of the concept rules, once again to illustrate an issue that arises in movement analysis and point specifically to the section of the XBRL 2.1 Specification that ensures that it works. Added examples of jurisdictional (Australian) extensions to IFRS taxonomies, and indicated that the scope of the rule applies to targetNamespace attribute values. Clarified language about DTS documentation. Clarified the meaning of “augments” in rules relating to allowed and disallowed prohibitions in extensions. Fixed the reference to xpointer schemes to refer only to the element scheme. Added clarification of the scope of the prohibition on undirected cycles in parent‑child arc sets. Changed the “director compensation table example” to be more international in flavour. No changes were made to text referring to “acknowledged,” “approved,” and “recommended” status for taxonomies even though this terminology may soon change per DWG resolution.
2003-12-31	Hamscher	Pending further discussion in DWG, removed all pathname components “/xbrl/” and “/taxonomy/” in the rules and the examples, replacing them with a document property “taxonomy” currently bound to “/”. Added explanation and example of the content of a ZIP archive. Updated to become the FRTA Candidate Recommendation as approved by ISC at 2003-12-30 meeting.
2004-02-09	Hamscher	Fixed typo in contributor’s e-mail address. Spurious NOT removed from the Abstract concepts rule. Added requirements about defined roles in the form of a rule and addition to the documentation requirement, and rearranged the order of these rules into a better sequence. Added figure showing the normative schema of the “ref” namespace. Corrected wording in the rule that defaults the meaning of a scenario-free context to “actual.” Added further explanatory note about the need to avoid overloading a single name with multiple concepts. Draft Candidate Recommendation 2.
2004-02-27	Hamscher	Generalised the rule requiring a human readable description for presentation link roles, to apply to all role types. Moved definition of architecture into the glossary. Clarified which arc and role type extensions are allowed, and reordered rules in the section on rules applying to all relationships. Added requirement to specify which version of XBRL used in taxonomy documentation. Removed rule defaulting context scenarios to actual, while adding a rule suggesting the need for scenario element definitions. Added documentation to the normative schema for references and a rule requiring documentation in any additional references. Added rule indicating the need for Sign related documentation on any item that has no balance attribute. Removed redundant rule about presentation arcs now superseded by general rule. Added rule forbidding the “all” compositor. Editorial changes in some rules such as reordering the parts of a DTS, clarification of what should be exercised in instances, and the implications of the roleType attribute documentation. Added note that many FRTA rules can be applied to 2.0 taxonomies. Added the rule automation section and note to the Approval process regarding the need for compliant taxonomy frameworks. Created an issues matrix and annotated this draft with the 11 outstanding issues. Draft Candidate Recommendation 3.
2004-03-02	Hamscher	Changed “constructor” to “compositor”. Simplified wording of the rule requiring documentation of extended-type link roles. Removed rule concerning maxOccurs and removed other remarks pertaining to outstanding issues, per 2004-03-01 DWG teleconference.
2004-04-23	Hamscher	Per DWG decision, strengthened rules governing assignment of signs to numeric items without balance attributes, and added extended example of signs and calculation arcs to the beginning of the section on calculation arc rules. Changed rule to allow non-standard arc roles and roles so long as they are registered in the LRR. Changed rule to allow taxonomies to be hosted elsewhere than at XBRL International, with corresponding change to the automation table.
2004-04-26	Hamscher	Changed the example of an abstract element used in a presentation hierarchy so that it does not suggest inappropriate usage. Removed spurious third subpart of rule regarding signs. Added additional clarification on the calculation arcs example illustrating the consequences of sign assignments in a cash flow statement.
2004-05-17	Hamscher	Finalised text for issuance as Candidate Recommendation 2.
2004-07-25	Hamscher	Split the rule governing element definition ids into a mandatory and recommended part to deal with escaped characters. Added a rule forbidding duplicate labels. Removed sections about instances; folded the tuple example into the basic rule about tuple definitions. Updated the acknowledgments. Fixed incorrect references to element‑label and element‑reference arcs. Converted all modal references (may, should) to modal character style. Made the rule disallowing mixed content in reference resources more explicit and gave a counterexample. Weakened the rule requiring an order attribute on all arcs. Added clarification to the ordered siblings rule. Changed the term “default presentation link set” to “default presentation link base sets” referring explicitly to the specification’s definition and clarified that the default base sets could be the union of several presentation links. Updated the documentation requirement for taxonomies to require an indication of which roles are included in the default presentation link base sets. Clarified that the requirement that all and only tuple children must be presentation children applies only to the default presentation link base sets. Repaired the incorrect “standard” extended-type link role attribute value in text and figures. Fixed the tuple‑similar typos. Added explanatory text to the beginning of the section on presentation relationships, and amplified the example in the rule relating to abstract items to reflect the idea that while abstract elements may not be strictly necessary for representing summations, they are nevertheless harmless so long as the other FRTA rules relating to presentation are followed. Added rule that concepts that may only appear in a tuple must be documented as such and added implementation note to appendix. Enumerated the circumstances in which the default namespace prefix must be used. Added rule against percents. Moved the rule about tuples not having the periodType attribute from the “rules for items” section to the “rules for tuples” section. Added rule requiring that tuple definitions provide for an id attribute, with the caveat that it will depend on a future XBRL errata level. Amplified the documentation requirements about ‘scope’ and indicated that when reference parts are provided their content must be consistent. Added rule advising the avoidance of element names with ‘total’, etc., and the use of different label roles to indicate this. Added rule requiring the use of a total label in some circumstances. Added bullet points suggesting appropriate substance for concept documentation. Relaxed the requirement that the URI authority component be an XBRL International name, while retaining other restrictions. Updated the automation table.
2004-08-06	Hamscher	Added indications of where issues remain for resolution. Merged typo fixes from Hoffman. Updated all references to taxonomies. Added proposed rule forbidding nested tuples.
2004-08-09	Hamscher	Removed rule relating to total labels on presentation parents and its corresponding rule regarding extensions. Weakened the requirement that the xlink:role indicate the type of reference. Removed proposed rule requiring references. Removed rule forbidding ‘total’ etc. in concept names. Combined redundant ‘duration’ rules and redundant ‘segment’ rules. Weakened rule requiring calculation arcs. Allowed defined extended-type link role values so long as they do not change the processing semantics of extended links. Changed the documentation requirement to require HTML and allow other formats. Promoted proposed rule regarding tuple recursion to a normal mandatory rule. Demoted the rule requiring concepts to document whether they are included in a tuple to a proposed rule. Updated the rule automation table.
2004-08-10	Hamscher	Updated the reference parts list and added normative appendix. Rearranged appendices to match XBRL specification order, and renumbered document. Placed an empty errata section. Introduced corrected and new rules from 9 August call. Made formatting changes to improve HTML formatting.
2004-08-16	Hamscher	Removed phrases and rules relating to consortium approval processes. Prepared for ISC approval of CR3.
2004-08-17	Hamscher	Created CR3 version.
2004-09-11	Hamscher	Created draft candidate recommendation. Moved appendix containing ‘rule automation’ to the FRTA Conformance suite and relabelled the section as an index. Removed modularity section per DWG decision of 27 August. Added rule forbidding nillable top level tuples. Reformatted several examples. Indicated that the approval levels in the terminology list are not normative definitions. Reworded the rule forbidding changes in content models so as to directly forbid the use of redefine. Weakened the rule against prohibiting concept-reference and general-special. Provided explanation for rule allowing other prohibitions. Added rule against prohibiting the id attribute.
2004-09-28	Hoffman	Added proposed rule changes resulting from creating conformance suite tests and reconciling FRTA to the current XBRL 2.1 Spec Erratum document. Proposed changes to be discussed on Domain call of 2004-10-04
2004-10-03	Wallis	Additional tidying up and editing.
2004-10-08	Hamscher	Incorporation of edits agreed on 2004-10-04 call. Added definition of “XBRL”, “XBRL Valid” and “FRTA compliant”. Removed the rule that applies all concept rules to abstract concepts and inserted the point into the introductory text of the rules for all concepts. Rewrote the rule about the nillable attribute to clarify that all concepts should be nillable, however that may be syntactically achieved. In the rules about relationships, eliminated unnecessary qualifications regarding “FRTA compliant DTS” since that is implicitly the scope of the entire set of rules. Fixed the wording of the rule forbidding duplicate role type definitions to not use the misleading word “concept”. Expanded the example of role type definition to include a footnote arc definition, to support a corresponding change in FRIS. Reworded the rules concerning duplicate arcs that need different order attributes or preferred labels; the preferred label rule now specifies that it is needed only on arcs that would otherwise be duplicates. Effectively removed the rule requiring a default presentation link base set and replaced it with a weak rule suggesting that taxonomy users may need a presentation link base. Removed the rule forbidding undirected cycles in presentation arcs. Moved the rule about duplicate calculations to a proposed rule. Removed rule forbidding redefine. Added rule requiring greater priorities for certain arcs. Updated the table showing which relationships an extension may prohibit, and added column indicating the impact on priority values. Defined a persisting DTS and persisting extension and narrowed the documentation rules to apply only to persisting DTS.
2004-10-11	Hamscher	After DWG discussion, edited the rules relating to URI naming to better distinguish normative from non-normative material; also, generalised to allow for future use of URN syntax instead of Generic URI syntax. Added indications to some mandatory rules where it is known they are not testable by fully automated means. Split the rule concerning calculation arcs not crossing contexts, so that its individual components (crossing period types and connecting concepts to themselves) are forbidden separately.
2004-10-25	Hamscher	Adjusted authors and contributors. Corrected wording of rule requiring the separation of different types of definitions into separate schemas. Simplified the rules forbidding embedded schemas into a single rule. Allowed additional URI schemes, and tightened up language as suggested by Mark Goodhand. Sections that are tested by the XBRL Specification or XBRL are now marked. Reintroduced the rule testability table into the appendix.
2004-10-26	Hamscher	Rewrote the rule concerning default namespace prefixes so that it is testable. Clarified the definition of persisting taxonomies to exclude single-entity extensions. Expanded the explanation of the rule requiring unused items and tuples to have their associated arcs prohibited. Rewrote the rule concerning sample instances.
2004-10-29	Goodhand	Changed rule regarding xlink:role on linkbaseRef to require the presence of this attribute. Previous wording required the attribute value to be non-empty, but this is already enforced by the spec. Also replaced occurrences of 'default namespace prefix' with 'recommended namespace prefix'.
2004-10-31	Hamscher	Corrected section numbering, formatting, replaced references to XBRL process document with reference to taxonomy recognition process, made other minor edits in preparation for Candidate Recommendation status.
2004-11-02	Hamscher	Created version for Candidate Recommendation status.
2004-12-12	Hamscher	In the testability table, fixed errors noted by Peter Calvert, repaired inconsistencies between the text and other columns, added a ‘persist’ column, reinstated explanations of the table columns, and made several other fixes generally indicating that rules previously indicated as testable by automated procedures in fact require manual review. Deleted the rule regarding escaped identifiers. Clarified the term “persisting” taxonomy. In several places, added the qualifier “the declaration of”, etc. Restricted the unique labels rule to require uniqueness among each language for the standard or verbose label roles; enumerated cases to test for. Edited all figures to correct usage of “…” convention and “standard” roles and arc roles. Corrected multiple formatting problems. Added a note indicating that rules about extensions presume that the identification of the extension and the base are inputs to the process of establishing FRTA compliance. Rewrote the rule regarding the schema root element.
2004-12-17	Hamscher	Further edits to the testability table, in particular all those which require ‘human readability’ are of necessity marked as Manual; added a paragraph indicating how automated FRTA compliance testing software should classify rule violations. Fixed the rule about the role URI so that it now allows for LRR approved roles. Made the unique labels rule stricter. Made edits clarifying that taxonomy authors need to include unnecessary taxonomies just to satisfy the need for essence‑alias arcs. Spelled out implications of the rule forbidding the mixing of concepts, parts, and other element declarations. Changed requirement for a spreadsheet to a requirement for a CSV. Collapsed rules regarding extension arcs that are allowed, and the priority values that they should be assigned, into fewer cases, and added example.
2005-01-05	Hamscher	Correction to body of the rule concerning parent-child arcs in tuples.
2005-01-12	Hamscher	Corrected typographical errors in the rules table. Generalised the rule governing the id attribute of element declarations. Consolidated two separate rules about the nillable attribute into a single rule with exceptions. Narrowed the scope of the rule prohibiting ambiguous orderings. Removed a paragraph permitting applications to use an arc’s priority attribute to select among alternative resources. Broadened the scope of the rule discouraging the use of prohibition on certain relationships. Removed the appendix containing proposed rules.
2005-01-14	Hamscher	Changed the element id rule to use the recommended namespace prefix. Reworded the rule requiring separation of different types of definitions into separate schemas. Changed rules regarding “arcs” to refer to “relationships” in recognition of the possibility that a single arc can define several relationships. Rewrote the introduction to the relationship layer rules to provide background and references to relevant specification sections. Made various typographical corrections in the testability table.
2005-01-21	Hamscher	Typographical corrections and clarification edits. Clarified one rule about relationships because “order” is defined as an attribute of arcs.
2005-01-22	Hamscher	Removed redundant rule requiring extended links to be defined in linkbases; created Candidate Recommendation 5.
2005-01-29	Hamscher	Incorporated edits from Hugh Wallis relating to the rule describing the correspondence between a tuple content model and presentation relationships.
2005-03-20	Hamscher	Weakened rule regarding percentages, removed ‘industry’ qualifier from path, made the recommended namespace prefix be the only namespace prefix, and corrected typographical errors in the rule table.
2005-04-04	Hamscher	Removed all rules requiring external documentation and references to those rules. Removed a lingering mention of the ‘all’ compositor. Defined “extension” and “base” linkbase so that they do not require manual identification. Fixed typo in DTS figure and example. Carved out exception on the spelling rule as applied to documentation and labels in multiple languages. Added guidance that documentation in the label linkbase tends to be more accessible. Provided explanation of the subjective rule against modification of the meaning of concepts. Clarified the text in the rule discouraging prohibition of label and reference texts, so as to illustrate a case where this advisory rule need not be applied. Updated dates and other details in the examples that include sample schema and linkbase text. Updated several individuals’ affiliations in the Acknowledgements and version dates in the References. Created Candidate Recommendation 6.
2005-04-25	Wallis	Editorial to reflect Draft Recommendation status.

Appendix F. 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 Domain Working Group (DWG) up to and including 2005-04-25. 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 DWG

Because this is a Recommendation, there are no errata at this time.

Name	Contact	Affiliation
Mark Goodhand	mrg@decisionsoft.com	DecisionSoft
Charles Hoffman	charleshoffman@olywa.net	UBmatrix
Brad Homer	bhomer@aicpa.org	AICPA
Josef MacDonald	jmacdonald@iasb.org.uk	IASCF
Geoff Shuetrim	gshuetrim@kpmg.com.au	KPMG
Hugh Wallis	hugh@standarddimensions.com	Standard Dimensions