Financial Reporting Instance Standards 1.0

Public Working Draft, dated 2004-11-14

Corresponding to XBRL 2.1 Recommendation with Corrected Errata dated 2004-11-14 and FRTA 1.0 CR4 dated 2004-11-14

This version:

FRIS-PWD-2004-11-14

Editors

Name	Contact	Affiliation
Mark Goodhand	mrg@decisionsoft.com	DecisionSoft
Walter Hamscher	walter@hamscher.com	Standard Advantage / Consultant to PricewaterhouseCoopers

Authors

Name	Contact	Affiliation
Charles Hoffman	Charleshoffman@olywa.net	UBmatrix
Josef Macdonald	jmacdonald@iasb.org.uk	IASC Foundation

Abstract

The rules in this document aim to facilitate the analysis and comparison of XBRL financial reporting data by computer applications and human readers.  The rules are intended to complement those in the Financial Reporting Taxonomy Architecture [FRTA].

“Financial Reports” encompasses documents that mix quantitative and textual information and are:

·          meant to satisfy authoritative financial reporting standards and generally accepted accounting practices/principles (or GAAP), or

·          regulatory reports whose subject matter is primarily financial position and performance and related explanatory disclosures, or

·          data sets used in the collection of financial statistics.

“Financial reports” excludes:

·          transaction- or journal-level reporting,

·          primarily narrative reports (for example, internal controls assessments), and

·          non-financial quantitative reports (for example, air pollution measurements).

Status

Circulation of this Public Working Draft is unrestricted. Recipients of this draft are invited to submit comments to the editors and authors, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Table of Contents

1      Introduction. 1

1.1       Scope. 1

1.2       Relationship to other work. 1

1.3       Organisation of this document 2

1.4       Terminology. 2

1.5       Document conventions. 3

2      Instance Structure. 4

2.1       XBRL Instance rules. 4

2.2       schemaRef 7

2.3       linkbaseRef 7

2.4       Contexts. 8

2.5       Entities. 9

2.6       Segments and Scenarios. 9

2.7       Units. 11

2.8       Facts. 13

2.9       Footnotes. 19

A      References (non-normative) 21

B      Rule Automation (non-normative) 22

C      Intellectual Property Status (non-normative) 26

D      Acknowledgements (non-normative) 26

E      Document History (non-normative) 27

F      Rejected rules (non‑normative) 29

F.1       Rejected rules originally appearing in FRTA. 29

F.2       Other rejected rules. 29

G      Approval process (non-normative) 30

 

List of Tables

Table 1. Standard namespace prefixes. 5

Table 2. Recommended ordering of XBRL instance components. 7

Table 3.  Footnote extensions allowed in a FRIS instance. 19

Table 4.  Suggested automation approaches for all rules. 22

 

List of Examples

Example 1. Disallowed s-equal contexts. 8

Example 2. Dimensions in a context. 9

Example 3.  Allowed unit sets. 12

Example 4.  Disallowed unit sets. 12

Example 5.  Identical values and contradictory values, both disallowed. 13

Example 6. Disallowed tuple containing no items. 14

Example 7. nil nested tuple. 15

Example 8. nil top-level tuple (counterexample) 16

Example 9. Explicit xsi:nil=”false” counterexample. 18

1         Introduction

The rules in this document aim to facilitate the analysis and comparison of XBRL financial reporting data by computer applications and human readers.  The fundamental use case that guides the rules is the publication, by a single organisation, of its financial reports, and the consumption of those financial reports by many, initially unknown, users and software applications.  The rules in this document have been established in the course of the creation of XBRL instances, notably instances for the IFRS Taxonomy Framework [IFRS] and the US-GAAP Taxonomy Framework [USFR].  The rules are written with general principles in mind:

·          Human readability of XBRL instances is relevant.  Although, increasingly, XBRL instances will be viewed "as XBRL" through specialised software, at this stage of XBRL adoption the ubiquity of XBRL-enabled software cannot be assumed. 

·          Human readability is less important than automation.  Guidelines in this document that cater to human readers are recommendations (should, should not) rather than imperatives (must, must not).  Imperatives are reserved for those rules upon which authors of automated processing, analysis, and comparison software could rely to simplify consumption of XBRL instances.

·          Redundant content is bad.  Duplicated information needlessly increases processing time, and may confuse human readers.  In particular, any information that is inferable from XBRL defaults should not appear at all.

·          Extraneous content is bad.  Content that would be discarded by an XBRL instance processor and that does not contribute to human readability should not appear at all.

·          Common representations are good.  Instances that use only taxonomies, units, entity identifier schemes, segments, and scenarios that appear in registries with schemas that are universally accessible, version controlled, and royalty free, are easier to consume, analyse, and compare.

This document assumes a working knowledge of the XBRL 2.1 Specification [XBRL], familiarity with Financial Reporting Taxonomy Architecture 1.0 [FRTA], and a basic understanding of XML, Namespaces, and XML Schema.

To many readers with XML experience, some of the guidelines in this document will be common sense.  Certain other rules are motivated by particular features of XBRL, and the reasoning behind the requirement may be less obvious.  Where appropriate the rules are accompanied by a brief rationale.

1.1      Scope

The rules in this document have been created with financial reporting in mind; some of the rules may be inappropriate or inapplicable for other types of business reporting.

In this document, “financial reporting” encompasses authoritative financial reporting standards and generally accepted accounting principles/practices (or GAAP), regulatory reports whose subject matter is primarily financial position and performance and 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).

1.2      Relationship to other work

The guidelines in this document pertain to XBRL instances as defined in the XBRL Specification [XBRL]. 

Parts of this document reiterate for expository clarity certain syntactic and semantic restrictions imposed by XBRL, but this document does not modify XBRL.  In the event of any conflicts between this document and XBRL, XBRL prevails.  This document does place additional restrictions beyond those prescribed by XBRL.

This document also refers to FRTA 1.0 [FRTA]. 

Parts of this document reiterate for expository clarity certain syntactic and semantic implications of FRTA, but this document does not modify FRTA.  In the event of any conflicts between this document and FRTA, FRTA prevails.

It is expected that most XBRL instances produced for financial reporting will conform to taxonomies that are FRTA compliant.  While FRTA is intended to ensure that financial reporting concepts are accurately and consistently modelled in XBRL, this document encourages appropriate use of FRTA compliant taxonomies to capture financial facts.  Together they aim to maximise the usability and comparability of XBRL-encoded financial information.

1.3      Organisation of this document

This main part of this document (Section 2) covers Instance Structure.  It begins with a consideration of general issues, and then discusses each instance component in detail: schemaRef, linkbaseRef, context, unit, facts (item & tuple), and footnote. The second part (Section A) collects rejected rules to provide insight into the scope of this document.

1.4      Terminology

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

Term	Meaning
arcroleRef, child, concept, context, duplicate item, descendant, DTS, duplicate tuple, element, entity, fact, footnote, instance, item, linkbase, linkbaseRef, period, roleRef, schemaRef, taxonomy, taxonomy schema, tuple, unit	As defined in XBRL.
DTS Component	A DTS contains taxonomy schemas and linkbases. The bounds of a DTS are such that DTS Components include all taxonomy schemas and linkbases that can be discovered by following links or references in the taxonomy schemas and linkbases included in the DTS.
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 Conformant documents and consuming applications are required to behave as described; otherwise they are in error.
DWG	The “Domain” Working Group of XBRL International.
Financial report	A document containing quantitative and textual information that is either: meant to satisfy authoritative financial reporting standards and generally accepted accounting principles/practices (or GAAP), or a regulatory report whose subject matter is primarily financial position and performance and related explanatory disclosures, or a data set used in the collection of financial statistics.  This excludes transaction- or journal-level reporting, primarily narrative and non-financial quantitative reports.
FRIS	Financial Reporting Instance Standards (this document).
FRIS compliant (FRIS-compliant)	Describes an element, attribute, or instance 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.
FRTA	Financial Reporting Taxonomies Architecture [FRTA].
FRTA compliant (FRTA-compliant)	Describes 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 Principles/Practices: Term used to describe broadly the body of principles/practices that governs the accounting for financial transactions underlying the preparation of a set of financial statements. Generally accepted accounting principles/practices 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.
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].
Persisting instance (persisting DTS)	A persisting instance is one whose purpose is to be stored as files to be referenced by many applications and published in some fashion.  Only a persisting instance requires documentation.  A persisting DTS is defined similarly [FRTA].
XBRL	Extensible Business Reporting Language (XBRL) 2.1 Recommendation [XBRL].
XBRL valid (XBRL-valid)	XML instances and schemas that satisfy the syntax requirements of XBRL.

1.5      Document conventions

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

The following formatting is used for non-normative counterexamples (examples of poor, discouraged or disallowed usage) in this document:

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

 

2         Instance Structure

2.1      XBRL Instance rules

XBRL instances contain facts (items & tuples), contexts, units (if there are any numeric facts in the instance), and sometimes footnotes. 

Ultimately, all of the business data is contained in items, but tuples are used to group together items that can only be understood in conjunction.

An XBRL instance carrying financial reporting information will usually cover multiple XBRL contexts.  Certainly, multiple periods are to be expected.  Additionally, the reporter’s facts may be divided according to segments (such as a company department), and scenario (such as actual vs. budgeted).  In some cases, as in group reporting in the mutual fund industry, an XBRL instance may even carry facts for multiple business entities.

Every numeric fact (such as 'Number of shares') must also have an associated unit (e.g. xbrli:shares) and the unit must be declared.  XBRL mandates that monetary values in XBRL instances use a unit whose measure is an ISO 4217 currency unit [ISO].

Footnotes may be included to associate structured text annotations with particular facts.

XBRL instance creators have the option of creating one XBRL instance containing all the information in a particular financial report, creating many XBRL instances that together make up the report, or create an instance containing data for multiple financial reports.  The choice may be influenced by technical considerations such as the need to break a large report into smaller chunks for transmission, or by business considerations such as the decision to “factor out” data that is common between financial reports so that the same information is not reported twice.  The ability to aggregate XBRL instances is likely to be important functionality for XBRL processors.

2.1.1      The DTS components discoverable from an instance must be XBRL-valid.

Taxonomy schemas and linkbases give meaning to the facts that appear in XBRL instances.  If these defining structures are invalid, the XBRL instance cannot be meaningfully processed.

2.1.2      The DTS of an instance must be FRTA compliant.

FRTA establishes standards for the design of an XBRL taxonomy and for a persisting DTS.  A DTS that satisfies all of the mandatory rules of FRTA (those phrased as a “must”) is said to be FRTA compliant.

Wherever possible, FRTA-compliant taxonomies and linkbases must be used.

The DTS of an instance (which could consist of the union of more than one DTS component that individually might not be FRTA compliant) must be FRTA compliant.    Section 1.4 above defines “DTS Component.” 

If DTS components to be used for an instance document are not XBRL valid (as for example when the merging of the DTS violates the XBRL prohibition on directed cycles in presentation parent-child arcs) or FRTA compliant (as for example when the merging violates the FRTA requirement that each set of equivalent arcs have a single highest priority arc), the instance creator MUST resolve those conflicts by creating an extension taxonomy that is the root of its DTS.  That extension taxonomy would then contain prohibiting and other arcs sufficient to satisfy both XBRL syntax and FRTA compliance rules.

The DTS of an instance does not have to be a persisting DTS.

2.1.3      XML files with <xbrl> as the root element should have the file extension .xbrl.

An XBRL instance is an occurrence of the xbrl element.  The instance may occur at any point in an XML document where it is permitted by the document’s content model.  The document may exist only in memory, or it may be persisted to a file or database. 

In most cases, the containing XML document will be an ordinary file, and often the document will contain only the XBRL instance – that is, the XML document will have <xbrl> as its root element.  In such cases it is appropriate to name the file with a special extension to indicate that it holds only an XBRL instance.  For consistency the extension .xbrl SHOULD be used in this case.  Although XBRL processors must be able to handle XBRL documents irrespective of the file extension, a file naming convention has important benefits:

1.      XBRL documents can be easily and efficiently located using file system indexes.  Alternative methods for identifying XBRL instance documents, such as the examination of the namespace and local name of the root element, require the file itself to be read, which is necessarily slower.

2.      Certain operating systems like Windows and Mac OS maintain associations between file extensions and applications.  It may be convenient to associate .xbrl files with an XBRL instance viewer or editor.

2.1.4      The names of files that contain XBRL instances should not contain characters with different meanings across platforms.

Files containing XBRL instances are likely to be passed across platforms.  Therefore, it is wise to avoid special characters to increase the number of file systems on which the filename is valid.  This avoids the necessity for the receiver to rename the file.

Filenames (excluding the extension and the separating [.]) SHOULD contain only the characters [0-9], [a-z], [A-Z], [-], and [_].  Do not use spaces or the other characters shown below because widely used platforms interpret these characters specially:

2.1.5      XBRL instances should use the same namespace prefixes as used in the XBRL schemas or conformance suite instances.

XBRL instances will contain a number of namespace prefixes.  Authors could use any namespace prefix to identify a namespace.  However, to reduce human reader confusion, for each of the namespaces used in the XBRL schemas or XBRL conformance suite instances, either make it the default namespace, or use the prefix defined in Table 1 below.

Table 1. Standard namespace prefixes

 

This rule relates to human comprehensibility; no consuming software application should ever fail to process an instance just because it uses a different namespace prefix.

2.1.6      XBRL instances should use the recommended default namespace prefix for all namespaces.

 

The namespace of each FRTA compliant taxonomy schema used by the instance should be bound to the “recommended default prefix” for that namespace (see [FRTA] section 4.3.2).  For example, http://xbrl.iasb.org/int/fr/ifrs/gp/2004‑06‑15 should be bound to ifrs‑gp.

2.1.7      Unused namespace declarations should not appear in XBRL instances.

While they pose no problem for processing applications, unnecessary namespace declarations can confuse human readers, and so should be removed from XBRL instances.

2.1.8      Irrelevant schema location hints should not appear in XBRL instances.

The xsi:schemaLocation attribute should contain schema location hints only for those namespaces that are actually used within the XBRL instance or its containing document.  Irrelevant location hints are to be avoided for the same reasons as unused namespace declarations are to be avoided.

2.1.9      An xsi:schemaLocation hint should not contain more than one namespace-location pair.

All of the information relevant to an XBRL processor for XML Schema-validation and XBRL-validation of an instance is contained in its schemaRef and linkbaseRef elements; therefore the xsi:schemaLocation attribute provides no new information and is only a potential source of inconsistencies (section 4.2 [XBRL]).  It may be omitted.

At best, the xsi:schemaLocation attribute can make it possible for non-XBRL aware processors to perform XML Schema validation on XBRL instances.  It is not a gaol of the current guidance to facilitate processing of XBRL instances by non-XBRL aware processors.  Even so, instance authors who wish for this property should recognise that the xsi:schemaLocation attribute is a hint [SCHEMA-0] that is processed differently by different XML parsers.  For example, it is common for processors to ignore any hint after the first.  Therefore, portable instances will contain at most one such hint. 

A consequence of this rule is that an instance that draws definitions from disjoint DTS’s should contain at most one xsi:schemaLocation hint and schemaRef to a schema that imports the needed taxonomy schemas.

2.1.10 XBRL instances should order elements so that referents precede references.

XBRL instance components SHOULD appear as children of the xbrl element in the following order.  Note that this ordering is partly enforced by [XBRL].  Any consistent ordering makes an XBRL instance easier for humans to read.  The recommended ordering was chosen so that the targets of references precede the references themselves, a property that can facilitate efficient processing.  Note that this rule is only a recommendation, and XBRL processors MUST NOT rely on this or any other ordering of the instance components beyond what is prescribed by [XBRL].

Table 2. Recommended ordering of XBRL instance components.

Elements	Explanation
schemaRef	schemaRef elements must be the first children of the xbrl element within an XBRL instance ([XBRL] 4.2).
linkbaseRef	linkbaseRefs MUST appear after the schemaRefs ([XBRL] 4.3).
roleRef	roleRefs MUST appear after the linkbaseRefs ([XBRL] 4.4).
arcroleRef	arcroleRefs MUST appear after the roleRefs ([XBRL] 4.5).
context	Contexts should appear after arcroleRefs.
unit	Units should appear after the contexts.
Facts	Facts should appear after the units.
Footnotes	Footnotes should appear after the facts.

2.1.11 An XBRL instance creator may include XML comments within an XBRL instance, but must not assume that the XBRL instance consumer will use the comments.

Financial report data should be reported as XBRL facts.  Comments do not carry data that is intended to be consumed.

2.2      schemaRef

2.2.1      If a taxonomy schema document has an authoritative location, it must be referred to by that location.

The href attribute of the schemaRef element MUST point to the web location of the authoritative copy of a referenced taxonomy schema document. Approved taxonomies, which  are required to be publicly available on the web at an authoritative location, must be at the location by which they must be referred ([FRTA] 4.3.5).

For example, an instance author must not use relative URI references to point to a copy of the approved version of ifrs-gp-2004-06-15.xsd that might be bundled in some manner along with the instance.  Similarly, the instance author must not use absolute URI references to point to an unofficial copy of ifrs-gp-2004-06-15.xsd elsewhere on the web.   The approved taxonomy ifrs-gp-2004-06-15.xsd MUST only be referred to at its authoritative location: http://xbrl.iasb.org/int/fr/ifrs/gp/2004-06-15/ifrs-gp-2004-06-15-calculation.xml.

2.3      linkbaseRef

2.3.1      If a linkbase document has an authoritative location, it must be referred to by that location.

The href attribute of the linkbaseRef element must contain the web location of an authoritative copy of the referenced linkbase document.   Approved linkbases, which are required to be publicly available on the web at an authoritative location, must be at the location by which they must be referred ([FRTA] 4.3.5).

For example, an instance author must not use relative URI references to point to a copy of the approved version of ifrs-gp-2004-06-15-calculation.xml that might be bundled in some manner along with the instance. Similarly, the instance author must not use absolute URI references to point to an unofficial copy of ifrs‑gp‑2004‑06‑15‑calculation.xml elsewhere on the web.

As a further example, ifrs‑gp‑2004‑06‑15‑calculation.xml must only be referred to at its authoritative location: http://xbrl.iasb.org/int/fr/ifrs/gp/2004-06-15/ifrs-gp-2004-06-15-calculation.xml.

2.4      Contexts

Facts in financial reporting pertain to a particular business entity in a particular time period.  XBRL captures this information in contexts, and every XBRL item is associated with exactly one context.

2.4.1      An instance must not contain s-equal contexts.

Two contexts are s-equal if they differ only in the attributes on the context element (for a formal definition, see [XBRL] 4.10). 

In the following example, the only difference between the two contexts is the value of the id attribute (c1 versus c2).

Example 1. Disallowed s-equal contexts

s-equal contexts convey exactly the same XBRL information, so only one of them is needed.  Redundant contexts add clutter, increase processing time, and can confuse human readers

2.4.2      An XBRL instance SHOULD not contain unused contexts.

An unused context is a context that is not referred to by any fact.  Unused contexts should be removed on the same grounds as s-equal contexts.

2.4.3      Context id attribute values should be meaningful to a reader of the primary language of the instance.

A context ID is, and must be, meaningless to processing software except as a unique identifier; all the semantic information is carried in the context itself.  Nevertheless, the context ID can be regarded as a kind of simple mnemonic documentation to a human reader of the instance such as a programmer.  Meaningful or descriptive context IDs are potentially helpful and do no harm to automated processing.  Of course, ‘meaningful’ is subjective and subject to change: a string that is meaningful to the instance author may not be meaningful to all readers of the instance; a string that is misleading because the context has changed and the ID has not is worse than no descriptive ID.  Context IDs should be neither too short (“c001”) nor overly verbose; a context ID such as   “SAMP20031231GroupActual” gives a reader of English an approximate idea of what the context contains.

2.5      Entities

2.5.1      Existing authoritative identifier schemes should be used.

Widely used, stable, authoritative schemes should be used.  For example:

·          business information vendors (DUNS)

·          security identifiers (CUSIP, SEDOL)

·          government issued (CIK)

·          exchange identifier (ticker symbol, QUIK code)

Schemes such as:

which amounts to "My name is what I call myself", severely hinder instance comparability.

DWG is considering an Identity Scheme Registry, similar to the proposed Link Role Registry [LRR] to help instance authors locate authoritative schemes.

2.6      Segments and Scenarios

The segment portion of an entity is “intended to identify the business segment more completely in cases where the entity identifier is insufficient” (4.7.3.2 of the XBRL Specification [XBRL]).

The scenario portion of an entity is used to distinguish between different types of fact, e.g. “actual”, “budgeted”, “restated”, and “pro forma”.

The contents of the segment and scenario elements are practically unconstrained by XBRL: any elements not from the XBRL instance namespace are allowed.  To allow meaningful analysis and comparison of XBRL instances, particularly by automated systems, it is essential that common structures be used.  This document does not define any common segments, but it does recommend a dimensional approach detailed in the rules of this section.  Instance authors should note that the level at which segments and scenarios are standardised will determine the degree of comparability.  XBRL International is currently considering an approach to standardising segment and scenario elements, but in the meantime companies, industries, and jurisdictions should develop their own standards. 

2.6.1      Each child element of segment or scenario should identify distinct partitions of the data.

Examples of distinct partitioning schemes commonly used in financial reporting are geography and line of business; the same idea applies to scenarios as for example different levels or types of authority assigned to the document.  In both, the different segments and scenarios are meant to be mutually disjoint and their union is a complete set (in short, a partition).  Each partition represents a distinct dimension of analysis.  A dimension may be an infinite set (dates, for example, although the time dimension is given special status within a context by [XBRL] and carries certain semantics as defined by the combination of [XBRL] and [SCHEMA‑2]) and does not have to be an enumerated set of elements.

Example 2. Dimensions in a context.

 

 

This example only suggests one such set of elements (geography, lineOfBusiness, attestation, and reportDate) and its supporting schema. 

Enumerating the members of a dimension using elements (e.g. AuditedUnqualified), Schema types and substitution groups is motivated by the observed need of instance and taxonomy authors to be able to extend the set of allowed values, in much the same way that an XBRL taxonomy is extensible with new elements; an enumeration of tokens does not achieve that.

2.7      Units

XBRL requires that the unit of measure be explicitly stated for each numeric item.  The units of measure used in an XBRL instance are defined through unit elements.

2.7.1      An instance must not contain s-equal units.

s-equal units introduce undesirable redundancy.

2.7.2      An instance must not contain unused units.

Unused units introduce extraneous information.

2.7.3      Units should have IDs meaningful to a human reader of the instance.

A unit ID is, and must be, meaningless to processing software except as a unique identifier; all the semantic information is carried in the unit element itself.  Nevertheless, the unit ID can be regarded as a kind of simple mnemonic documentation to a human reader of the instance such as a programmer.  Meaningful or descriptive context IDs are potentially helpful and do no harm to automated processing.  Of course, ‘meaningful’ is subjective and subject to change: a string that is meaningful to the instance author may not be meaningful to all readers of the instance; a string that is misleading because the context has changed and the ID has not is worse than no descriptive ID.  Context IDs should be neither too short (“d”) nor overly verbose; a unit ID such as   “usdPerShare” gives a reader of English an approximate idea of what the unit contains.

2.7.4      Standard units should be used in measure elements.

Standard units increase comparability of numeric items.

DWG is considering a Unit Registry similar to the proposed Link Role Registry [LRR] to help instance authors identify units based on international standards [UCUM].

2.7.5      Each unit should appear with only one scale factor in a given instance.

Measures based on different underlying scales (e.g. feet vs. meters, USD vs. JPY) are allowed.  Example 3 shows two different sets of compatible units.

Example 3.  Allowed unit sets.

 

 

A scale factor is a constant multiplier such as thousands, thousandths, etc.  A single underlying dimension of measurement must not appear in an instance that differ only by multiple scale factors, be it in thousands, thousandths, etc. 

Example 4.  Disallowed unit sets.

 

 

This means that even though numbers in a given instance may differ by orders of magnitude (e.g., par value in thousands of dollars, shareholder equity in millions of dollars) that is simply a matter of including enough zeroes before or after the decimal point so as to represent the fact correctly in the instance.  It is up to the consuming application that renders the data for human viewing to determine any scale factors and corresponding units of measure to use in that rendering.

Note that in Example 4 above, section 4.8.2 [XBRL] requires that monetary items be represented using ISO4217 currency designations, so the definitions “musd” and “cent” must not be used for monetary items in any event.  In other words, conforming XBRL processors already enforce the restriction insofar as monetary items are concerned.

Compound units such as “square feet” and “square miles”, or “cubic centimetres” and “cubic metres”, are not allowed because their numerators and denominators form pairs of disallowed sets.

2.8      Facts

The rules governing the syntax and usage of facts in XBRL instances in most if not all cases add further restrictions to those imposed by XBRL validation.  Mandatory rules are given before advisory rules.

2.8.1      An instance must not contain duplicate items.

By definition, duplicate items are appearances of the same concept in one XBRL instance and have the same (i.e. s-equal) context and the same (i.e. s-equal) unit (for a formal definition see [XBRL] 4.10).  We may divide duplicate items into two classes: those that have the same value, and those that have different values.

Both kinds of duplicate item are inappropriate for financial reporting instances. Each fact for a given concept, context and unit MUST have exactly one value, and that value MUST be stated no more than once.

Example 5.  Identical values and contradictory values, both disallowed.

2.8.2      An instance must not contain duplicate tuples.

Duplicate tuples are inappropriate for financial reporting instances, for the same reason that duplicate items are inappropriate (2.8.1 above).  Unlike items, tuples are duplicates only if the values for all corresponding items in the tuples are equal.  For a formal definition, see [XBRL] 4.10.

2.8.3      Concepts appearing in the content model of a tuple must not appear at top level.

Because of the rules of XML Schema and how XBRL uses XML Schema, in particular the substitutionGroup mechanism, all XBRL concepts defined are global in nature and could legally appear as children of the xbrl root element, per the rules of XML Schema [SCHEMA-1].  However, not all items have meaning outside of a tuple.

There are two types of items: those that stand on their own, and those that must be understood in conjunction with other items.  The former MUST appear as children of the xbrl element; the latter MUST appear in tuples.  For example, a fact about the item “Director Salary” has no meaning by itself; it MUST appear with a fact about the item “Director Name”.   Instances must not have the items outside the tuple that contains both.

This applies also to tuples.  A tuple that appears in the content model of another tuple MUST NOT appear at top level.

2.8.4      Every non-nil tuple must contain at least one item directly or indirectly.

The only way tuples can carry information is through the facts (ultimately, the items) they contain.  Either directly (as a child) or indirectly (as a non-child descendant), every non-nil tuple MUST contain at least one item.  This rules out empty tuples as well as tuples that contain only nil tuples.  The reason for this rule is to ensure that every tuple in an instance has at least one context associated with one of its items; otherwise it is redundant and should not appear.

Example 6. Disallowed tuple containing no items.

2.8.5      Top-level tuples must not have true as the value of the xsi:nil attribute.

Tuples may have xsi:nil="true", while the content model of a tuple may require another tuple to be present within it.  If the value of the inner tuple is unknown or undefined, it may be appropriate for that tuple to have xsi:nil="true".

Example 7. nil nested tuple

 

In this example, loosely translated from the “Board of Directors Report” portion of a draft Chinese Securities Regulatory Commission (CSRC) taxonomy, different activities are reported under different tax treatments, and within those, each product or service has to be disclosed separately.

A nil value for ar:activity is meaningful because we know that there are no results being reported for the ‘taxable’ activity category. 

In contrast, a nil top-level tuple is meaningless because it has no supporting information (“top-level” tuples are those that appear as children of the xbrl element).

Example 8. nil top-level tuple (counterexample)

2.8.6      The sign of numeric fact values must adhere to the guidance provided by concept documentation when a balance attribute has not been provided.

When the sign of a numeric concept is not determined by a balance attribute, the instance author must consult the documentation (as defined by FRTA rule 2.1.13) to determine whether fact values should be positive or negative.

Conformance with this rule cannot be tested in an entirely automated fashion.

2.8.7      Facts relating to events or concepts must not be assigned to any date outside the period being reported upon unless necessary to reflect accurately the occurrence of the concept.

Any instant or duration specified in the contexts for any fact in a financial report MUST fall within the period documented by the report.

Some elements of financial statements are themselves dates.   The content of the date element (for example, the date of the Accountant’s report) is different from the context date to which it refers (in this case, the context is the period covered by the accountant’s report).

This rule applies even for facts that, strictly speaking, occured outside the period documented by the report, but impact the content of the report:

 

1.      Subsequent Events should be reported as at the balance date to which they are subsequent, with periodType="instant".

2.      (Exception) Directors’ names and signatures to the accounts should be reported as at the date of signing financial statements, subsequent to the balance date, when known.

There may be other exceptions.

Note that accounting policies relate to the period of the stated financial statements and to any prior periods caught by requisite comparatives.

Restated figures should be periodType="instant".  By default, they should be assigned the date at the start of the period captured in the financial statements.

Conformance with this rule cannot be tested in an entirely automated fashion.

2.8.8      Facts relating to a financial statement for a period must not have any context that is any longer than the period being reported.

A financial statement covering, say, a year may have facts in it whose duration is longer than that particular year.  Nevertheless, the facts should be placed into separate contexts each one covering no more than the year covered by the financial statement, so as to simplify the task of applications that extract information.

2.8.9      Both the ending balance of a period and the beginning balance of the subsequent period in the same scenario must be represented by a single numeric fact.

For example, suppose a fiscal year begins on April 1^st and an instance needs to represent the beginning and ending values of Cash and the Change in Cash during Fiscal 2002 and Fiscal 2003.  The table below shows five facts and the relevant parts of their contexts.

March 31^st and April 1^st appear to be different dates, but in this case are actually the same instant in time.  Section 4.7.2 [XBRL] defines a distinction in the way that dates are treated in the startDate and endDate elements:  “A date, with no time part, in the content of a startDate element is defined to be equivalent to specifying a dateTime of the same date, and T00:00:00 (midnight at the start of the day).  A date, with no time part, in the endDate or instant element is defined to be equivalent to specifying a dateTime of the same date plus P1D and with a time part of T00:00:00.”

In this example, therefore, Cash at the start of the period “2001-04-01 to 2002-03-31” is represented by a fact whose context is the instant 2001-03-31 (meaning midnight on April 1^st).  Section 4.7.2 [XBRL] therefore eliminates a potential source of duplicate facts.

The facts above could be rendered (presented) by an application as shown below.  Obviously, the value 5000 appears in two different places, as the ending value of fiscal 2002 and beginning value of fiscal 2003.  However, those same two presentations are expressed using a single fact value within an XBRL instance:

2.8.10 Items and Tuples should not have false as the value of the xsi:nil attribute.

The default value of the xsi:nil attribute is false, therefore the xsi:nil attribute SHOULD only appear if it has the value true.

Example 9. Explicit xsi:nil="false" counterexample.

2.8.11 Numeric facts should use the decimals attribute.

XBRL provides two methods of communicating the precision of a numeric fact: precision and decimals attributes.  Humans seem to have an easier time reading a document that uses the decimals attribute because the decimals value is likely to be only one of 2, 0, -3, -6, -9 or INF.  Moreover, given a decimals value the precision can always be computed, but this is not symmetric.

2.9      Footnotes

Footnotes are a feature of XBRL that provides associations between facts in an XBRL instance.

Highly regular, repeating associations should be expressed using tuples in many cases or by calculation, definition, and presentation links within a taxonomy in other cases.  Footnotes are intended to convey ad hoc information about a fact or set of facts.

Because footnotes are implemented as linkbases inside of XBRL instances, the rules covering all linkbase relationships (FRTA section 3.1) apply to them even though FRTA rules apply to the DTS and the DTS is discovered from the instance but does not include it.  The explanation of these rules as they apply to footnotes is abbreviated here; the complete rules covering all XBRL linkbases can be found in FRTA itself.

2.9.1      An instance must not include any footnote link elements (simple, resource, extended, or arc) not in an XBRL module or in XBRL.

The footnote links comprising a FRIS-compliant instance are limited to those defined in XBRL or XBRL Module Recommendations.  Table 3 summarises other extensions that are disallowed and allowed, and in the case of the extensions allowed, the documentation requirements.

Table 3.  Footnote extensions allowed in a FRIS instance

	XBRL 2.1	XBRL Module	LRR	FRIS Rule	Documentation Requirement
Link elements (xlink:type of locator, simple, arc, resource, or extended)	Yes	Yes	No	2.9.1	Modules are defined via specifications that satisfy XBRL International process requirements.
Arc roles	Yes	No	Yes	2.9.2	Documented in [LRR]
Roles on resources	Yes	No	Yes	2.9.3	Documented in [LRR].
Roles on extended-type links	Yes	Yes	Yes		FRTA consequence [FRTA].

2.9.2      Footnote arcs must have only their standard or LRR approved arc roles.

This rule corresponds to Rule 3.1.2 [FRTA], but applies to footnote arcs.  Because instances cannot define roles nor arc roles but only reference their definitions appearing in a schema, this rule is a consequence of rule 2.1.2 above (the DTS of an instance must be FRTA compliant).  This rule does not prevent the publication of an additional instance that constitutes a non-FRIS compliant superset of a FRIS-compliant instance.

2.9.3      The footnote element must have only its standard or LRR approved resource roles.

This corresponds to Rule 3.1.3 [FRTA], but applies to footnote resource elements.  Because instances cannot define roles nor arc roles but only reference their definitions appearing in a schema, this rule is a consequence of rule 2.1.2 above (the DTS of an instance must be FRTA compliant). The role http://www.xbrl.org/2003/role/footnote ([XBRL] 4.11.1.2) is all that is allowed on footnote elements.  This rule does not prevent the publication of an additional instance that constitutes a non-FRIS compliant superset of the contents of a FRIS-compliant instance.

2.9.4      All arcs within a footnote link must have the same arc role.

This corresponds to [FRTA] 3.1.7, but applies to footnote links.  Although footnote arcs have only one standard arc role (2.9.2 above) each footnote link is constrained to have only a single arc role on all the arcs that the link contains, so as to minimise the possibility of accidental violations of the XML Linking Language [XLINK] constraint on duplicate arcs within a given extended-type link, even when the arcs in question have different arc roles.

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

This corresponds to [FRTA] 3.1.8, but applies to footnote links.  XBRL processors treat footnote links separately when they have different values for the role attribute.  The role attribute must not be empty (Section 3.5.3.3 [XBRL]) and the standard value for the role attribute is http://www.xbrl.org/2003/role/link.

2.9.6      Footnote links that are not necessarily processed together by consuming applications must have distinct role values.

This corresponds to [FRTA] 3.1.6, but applies to footnote links.  Typical reasons that extended-type links are not to be processed together are that the links may be incompatible or that the links may be redundant.   Note that prohibition and overriding of footnote arcs is influenced by the base set to which a footnote arc belongs ([XBRL] 3.5.3.9.7.3).

2.9.7      All footnote arcs must specify an order attribute.

XBRL is silent on the semantics of the order attribute when it appears on a footnoteArc, and Section 3.5.3.9.6 [XBRL] indicates that the order attribute is optional.  It is up to consuming applications that render the data for human viewing to determine what numbers or symbols to use when displaying footnotes, but the required order attribute may be used to present footnotes in a specified order when it would otherwise be ambiguous, as for example when there are multiple footnote arcs for a single fact.  This rule ensures that instances have a common way of communicating order preference to different tools. 

2.9.8      All footnote arcs to the same fact having the same arc role, within footnote links having the same role, must have distinct values for the order attribute.

It is desirable for footnotes to have a deterministic ordering when displayed. 

2.9.9      XBRL instance authors must not use footnotes to express associations that hold across all occurrences of items or tuples in any instance of a taxonomy.

Footnotes in an instance do not substitute for the content of an extension taxonomy.  Footnotes may appear within an XBRL instance to express associations between facts.  However, it is not appropriate for XBRL instance authors to use footnotes in lieu of tuples or definition, presentation, or calculation links.

A       References (non-normative)

[FRTA]	Walter Hamscher (editor).
	Financial Reporting Taxonomies Architecture 1.0 Candidate Recommendation 4 dated 2004-11-14.
	http://www.xbrl.org/TechnicalGuidance/
[IFRS]	IFRS Taxonomy Framework
	http://xbrl.iasb.org/int/fr/ifrs/gp/2004-11-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/
[USFR]	US Financial Reporting Taxonomy Framework
	http://www.xbrl.org/taxonomy/us/TaxonomyFrameworkOverview.htm
[LRR]	Walter Hamscher (editor), Hugh Wallis
	XBRL Link Role Registry, Public Working Draft of 2004-11-14
[UCUM]	Schadow, G. and C. J.  McDonald.
	The Unified Code for Units of Measure
	http://aurora.rg.iupui.edu/~schadow/units/UCUM/ucum.html
[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
[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/
[XBRL]	Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis .
	Extensible Business Reporting Language (XBRL) 2.1 Recommendation with corrected errata to 2004-11-14
	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/

B       Rule Automation (non-normative)

Table 4 below lists each of the 45 rules along with

·          Its text;

·          whether it is mandatory (Man.) or not;

·          whether it is objectively testable by software (Obj.);

·          whether it may be applicable to all instances, not just financial reports (Gen.);

along with remarks as to automation approaches (Remarks).

The most important candidates for automation would obviously be the mandatory, objective rules; for human reviewers of instances (instances, for example, submitted along with a taxonomy in order to achieve XBRL International approval) the mandatory, subjective rules are the best candidates for providing supporting (though not comprehensive) automation.

Table 4.  Suggested automation approaches for all rules.

Rule	Text	Man.	Obj.	Gen.	Remarks
2.1.1	The DTS components discoverable from an instance must be XBRL-valid.	Yes	Yes	Yes
2.1.2	The DTS of an instance must be FRTA compliant.	Yes	Yes	Yes	This is general just insofar as those FRTA rules that are not specific to FR taxonomies.
2.1.3	XML files with <xbrl> as the root element should have the file extension .xbrl.	No	Yes	Yes
2.1.4	The names of files that contain XBRL instances should not contain characters with different meanings across platforms.	No	Yes	Yes
2.1.5	XBRL instances should use the same namespace prefixes as used in the XBRL schemas or conformance suite instances.	No	Yes	Yes
2.1.6	This rule relates to human comprehensibility; no consuming software application should ever fail to process an instance just because it uses a different namespace prefix. XBRL instances should use the recommended default namespace prefix for all namespaces.	No	Yes	Yes
2.1.7	Unused namespace declarations should not appear in XBRL instances.	No	Yes	Yes
2.1.8	Irrelevant schema location hints should not appear in XBRL instances.	No	Yes	Yes
2.1.9	An xsi:schemaLocation hint should not contain more than one namespace-location pair.	No	Yes	Yes
2.1.10	XBRL instances should order elements so that referents precede references.	No	Yes	Yes
2.1.11	An XBRL instance creator may include XML comments within an XBRL instance, but must not assume that the XBRL instance consumer will use the comments.	Yes	No	Yes
2.2.1	If a taxonomy schema document has an authoritative location, it must be referred to by that location.	Yes	Yes	Yes
2.3.1	If a linkbase document has an authoritative location, it must be referred to by that location.	Yes	Yes	Yes
2.4.1	An instance must not contain s-equal contexts	Yes	Yes	Yes
2.4.2	An XBRL instance SHOULD not contain unused contexts.	No	Yes	Yes
2.4.3	Context id attribute values should be meaningful to a reader of the primary language of the instance.	No	No	Yes
2.5.1	Existing authoritative identifier schemes should be used.	No	No	Yes	There is no universally agreed set of ‘authoritative’ identifier schemes.
2.6.1	Each child element of segment or scenario should identify distinct partitions of the data.	No	No	Yes
2.7.1	An instance must not contain s-equal units.	Yes	Yes	Yes
2.7.2	An instance must not contain unused units.	Yes	Yes	Yes
2.7.3	Units should have IDs meaningful to a human reader of the instance.	No	No	Yes
2.7.4	Standard units should be used in measure elements	No	No	Yes	There is no universally agreed set of ‘standard’ units.
2.7.5	Each unit should appear with only one scale factor in a given instance.	No	No	Yes
2.8.1	An instance must not contain duplicate items.	Yes	Yes	Yes
2.8.2	An instance must not contain duplicate tuples	Yes	Yes	Yes
2.8.3	Concepts appearing in the content model of a tuple must not appear at top level.	Yes	Yes	Yes
2.8.4	Every non-nil tuple must contain at least one item directly or indirectly.	Yes	Yes	Yes
2.8.5	Top-level tuples must not have true as the value of the xsi:nil attribute.	Yes	Yes	Yes
2.8.6	The sign of numeric fact values must adhere to the guidance provided by concept documentation when a balance attribute has not been provided.	Yes	No	Yes	Since non-FR taxonomies will have few or no balance attributes, this rule is even more relevant for them.
2.8.7	Facts relating to events or concepts must not be assigned to any date outside the period being reported upon unless necessary to reflect accurately the occurrence of the concept.	Yes	No	No
2.8.8	Facts relating to a financial statement for a period must not have any context that is any longer than the period being reported.	Yes	No	No
2.8.9	Both the ending balance of a period and the beginning balance of the subsequent period in the same scenario must be represented by a single numeric fact.	Yes	No	Yes
2.8.10	Items and Tuples should not have false as the value of the xsi:nil attribute.	No	Yes	Yes
2.8.11	Numeric facts should use the decimals attribute.	No	Yes	Yes
2.9.1	An instance must not include any footnote link elements (simple, resource, extended, or arc) not in an XBRL module or in XBRL.	Yes	Yes	Yes
2.9.2	Footnote arcs must have only their standard or LRR approved arc roles.	Yes	Yes	Yes
2.9.3	The footnote element must have only its standard or LRR approved resource roles.	Yes	Yes	Yes
2.9.4	All arcs within a footnote link must have the same arc role.	Yes	Yes	Yes
2.9.5	Each extended-type link must have a nonempty role attribute.	Yes	Yes	Yes
2.9.6	Footnote links that are not necessarily processed together by consuming applications must have distinct role values.	Yes	No	Yes
2.9.7	All footnote arcs must specify an order attribute.	Yes	Yes	Yes
2.9.8	All footnote arcs to the same fact having the same arc role, within footnote links having the same role, must have distinct values for the order attribute.	Yes	Yes	Yes
2.9.9	XBRL instance authors must not use footnotes to express associations that hold across all occurrences of items or tuples in any instance of a taxonomy.	Yes	No	Yes

C       Intellectual Property Status (non-normative)

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

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.  XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.  Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

D       Acknowledgements (non-normative)

This document could not have been written without the contributions of many people. The participants in the XBRL Domain Working Group, public commentators, and personal advisors have all played a significant role.  The XBRL International domain working group is chaired by John Turner (KPMG) and vice chaired by Josef MacDonald (IASCF).  We also thank the following people for their comments and suggestions: George Farkas (XBI Software), Yuji Furusho (Fujitsu), Akira Gokita, Masatomo Goto (Fujitsu), Marc van Hilvoorde (PricewaterhouseCoopers), Brad Homer (AICPA), David vun Kannon (KPMG), Manabu Mizutani (PCA Corporation), Jim Richards (Murdoch University), Miho Saito (PricewaterhouseCoopers), Paul Snjijders (Semansys), Per Thorling (PricewaterhouseCoopers), Hugh Wallis (Standard Dimensions), and Paul Warren (DecisionSoft).

E        Document History (non-normative)

Date	Editor	Summary
2004-03-26	Hoffman	First draft of document prepared, preliminary summary of discussions.
2004-05-05	Goodhand	Significant editorial revisions and comments on issues.  Document renamed to FRIS (Financial Reporting Instance Standards) from FRIA (Financial Reporting Instance Architecture) because this document does not describe an architecture as such.
2004-06-02	Goodhand	Comments from various people incorporated.  Three rules moved to ‘Rejected rules’ appendix (rejected rules 1, 2, and 3). We await detailed review from more members of DWG, and resolution of issues identified by editors’ comments.
2004-06-06	Hamscher	Proposed edits to text intended to improve clarity, in particular relating to the implicit “publish once, use many” assumption.  Made a variety of formatting changes not impacting semantics.
2004-06-15	Goodhand	Incorporated changes agreed on last Friday’s FRIS call.  Two rules moved to ‘Rejected rules’ appendix (rejected rules 4 and 5).  Two other rules merged into introductory paragraph (2.1).
2004-07-15	Goodhand	Various editorial changes ahead of publication as PWD.
2004-07-23	Hamscher	Editorial changes as a result of discussions, including changes to use naturally-occurring examples and counterexamples of tuple usage, reordering of rules, wording changes.  Added rule relating to unit scale factors.
2004-07-25	Hamscher	Removed section on “data mapping” to be rolled into a separate “patterns” document or “style guide”.  Added additional paragraph of explanation of the impact of instant, start date and end date treatments.  Rearranged rules to place mandatory rules earlier in each section.  Moved rules relating to instances from FRTA into this document.  Moved rejected rules back into main body.  Added to the references section.  Rewrote the rule relating to items and tuples appearing at top level.  Incorporated FRTA rules relating to relationships and edited them to apply to footnotes.  Added the table of rules in the appendix on automation.  Made editorial change to consistently refer to XBRL 2.1 Recommendation as simply XBRL, and FRTA 1.0 as FRTA.
2004-07-29	Hoffman	Fixed typos.  Added references to the USFR Taxonomy Framework.  Changed references from IFRS-CI taxonomy to IFRS-GP taxonomy and updated dates.  Minor clarifications and other miscellaneous edits.  Inserted target dates into completion matrix.
2004-08-16	Goodhand	Incorporated edits and fixed typos.
2004-08-16	Hamscher	Reworded the tuple rules so as to forbid any concept from appearing at top level if it appears in a tuple content model, and to recommend that concepts appearing in tuple definitions appear only in those tuples.  Changed sectioning and pagination in preparation for release as public working draft.
2004-08-17	Hamscher	Final changes to release as public working draft.
2004-08-30	Hamscher	Add definition of DTS Component.  Correct the default prefix rule because instance-related namespaces don't appear in XBRL schemas.  Add rule indicating that multiple schemalocation hints should not be used.  Added a date dimension to the scenarios and segments example, and corrected context syntax.  Make the rules about redundancy consistent as advisory.  Correct the ending balance / beginning balance rule to only apply to numeric facts.  Provide additional rationale for the use of the decimals attribute.  Provide a more accurate explanation of the footnoteArc order attribute rule.  Add acknowledgments.  Make editorial corrections throughout.  Repair the rule automation table to conform to new rule numbering and texts, and change some of the evaluations as to whether they are mandatory, objective, and generalisable.
2004-10-08	Hamscher	Incorporation of edits agreed on 2004-10-04 call.  Added definition of “XBRL”, “XBRL Valid”, “FRTA compliant”, “FRIS compliant”, and “Persistent instance”.  Rewrote the rule that a FRIS instance must have a FRTA compliant DTS (even if its constituent DTS’s are not), with explanation of what might be required to achieve this; the rule mentions the FRTA rule concerning the need for extensions to have higher priorities on the arcs than the arcs it prohibits or overrides.  Added the ampersand to discouraged characters in file names.  Expanded the explanation for human readable context IDs and unit IDs.  Updated the example of segments and scenarios to use substitution groups, since enumerated data types lead to well known extensibility problems.  Removed the rule that concepts cannot appear outside of tuples where they are used, since this is at best redundant with the rule preventing them appearing at top level.  Deleted two rules about footnotes that incorrectly implied it is possible to define roles and arc roles in an instance; added explanatory text to rules that are actually enforced in FRTA and therefore are consequences of the more fundamental rule that an instance cannot be FRIS compliant unless its DTS is FRTA compliant.
2004-10-12	Hamscher	Incorporation of edits agreed on 2004-10-11 call.  Relaxed the rule on namespace prefixes to allow these namespaces to be the default.  Expanded explanation of the rationale behind the recommendation against using more than one schemaLocation pair in an instance.  Strengthened the anti-redundancy rules to be mandatory.  Made entries in the automation table consistent with their status as mandatory or not.
2004-11-05	Hoffman	Corrected typos.  Updated FRTA references to the newest DCR.  Updated IFRS references to most current IFRS taxonomy.
2004-11-05	Hamscher	Formatting and reference updates only.
2004-11-14	Hamscher	Preparation as public working draft.

 

F        Rejected rules (non‑normative)

This appendix will be removed from the recommendation.

There are rules that have been considered but decided against.  Given the close relationship of FRTA and FRIS and their need for consistency, some rules from FRTA that are listed as rejected but actually applying to instances are shown here.

F.1     Rejected rules originally appearing in FRTA

F.1.1     When different occurrences of a concept in an instance are distinguished by measurement or aggregation, labels MUST NOT be used to encode these distinctions. 

For example, labels must not be used to distinguish valuation at cost from valuation at market value while using the same concept to report these two valuations in the same instance.  Furthermore, if the definition of the concept is broad enough to accommodate both measurement approaches, then the labels associated with that concept MUST NOT indicate that a particular measurement approach has been chosen.

F.1.2     Concepts appearing in the content model of tuples should not appear outside of those tuples.

This extends rule 2.8.3 above because usually items and tuples used in a tuple require additional items (not just context) to be meaningful, so they do not make sense inside of tuples where they are not expected.

F.2     Other rejected rules

F.2.1     Items of a particular concept should be reported using the same unit throughout an instance.

This rule would cause trouble for reports that span periods in which a currency change occurs (e.g. GBP to EUR) because XBRL requires that the currency used be valid for the time period.  Besides it is common for companies to disclose sales in multiple currencies (e.g. USD and JPY).  Note that items of a concept may be reported using the same kind of unit: multiple currencies, for example, or several “currency per share” measures.

F.2.2     The iso4217 namespace prefix must appear in all XBRL instances and must have the namespace identifier value of http://www.xbrl.org/2003/iso4217.

This rule was suggested on the grounds that all financial reporting instances are likely to contain monetary values, but it conflicts with rule 2.1.7 by requiring that this namespace always appear (regardless of whether it is actually used).  The association of the prefix 'iso4217' with the namespace 'http://www.xbrl.org/2003/iso4217' has been added to 2.1.5.

F.2.3     A period (date) with no time part used as an endDate and startDate are deemed equal.

This rule was rejected because it runs counter to the rules in [XBRL] 4.7.2.

F.2.4     XBRL instances must contain a validation certificate using the FRTA validation certificate taxonomy

Some rules in this document cannot be tested automatically.  In the absence of comprehensive automated checking it does not seem practical to issue validation certificates.  Thus, it does not make sense to require a validation certificate. 

F.2.5     Period format (startDate, endDate, instant) must be CCYY‑MM‑DD.

The format of these values is already constrained by XML Schema.  startDate, endDate, and instant are of type xbrli:dateUnion which is a union of xsd:date and xsd:dateTime.  Each of these built-in schema types has a strict format: CCYY-MM-DD for date, CCYY-MM‑DDThh:mm:ss for dateTime ([SCHEMA‑2] 3.2.9 & 3.2.7).

F.2.6     Any role type definition for a footnote link must have a human-readable explanation in its definition element.

This corresponds to [FRTA] 3.1.7, but applies to footnote link, arc and resource roles.  In addition to being good practice to document custom roles, the purpose of this rule is to ensure the availability of a human-readable string to be displayed by consuming applications.  Users see “End Note” rather than “http://www.samplecompany.com/role/endnote”. 

The definition element is required in the roleType element and its non-empty content should be an explanatory text string of no more than 50 characters.   Additional description of the processing semantics should be provided in the taxonomy documentation ([FRTA] 4.4.1).

F.2.7     Any role on a footnote link other than the standard role must use a namespace owned by the author of a taxonomy in the DTS of the instance.

This limits the potential for accidental merging of independently created networks, as for example when instances are concatenated.

 

G       Approval process (non-normative)

This section will be removed from the final recommendation.  DWG = Domain Working Group; ISC = International Steering Committee.

For this document, a necessary condition for advancing from stage 5 (Candidate Recommendation) to stage 6 (Recommendation) shall be the concurrent approval of compliant sample instances.

	Stage	Party responsible for decision	Next step	Revisions needed	Target date for stage completion
1	Internal WD	DWG	Recommend for Stage 2	Stay in Stage 1	2004-08-01
2	Internal WD pending publication	ISC	Approve for Stage 3	Return to Stage 1	2004-11-14
3*	Public WD under 45 day review	WD Editors	Minor revisions – to Stage 4	Major revisions – Restart Stage 1	2004-12-31
4	Draft Candidate Recommendation	DWG	Recommend for Stage 5	Restart Stage 3
5	Candidate Recommendation	ISC	Approve for Stage 6	Restart Stage 4
6	Recommendation	DWG	Recommend for Stage 7	Restart Stage 4
7	Recommendation