1 Introduction

The rules in this document aim to facilitate the analysis and comparison of XBRL GL data by computer applications and human readers. 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.

· Some XBRL constructs are inappropriate, or questionably appropriate, for XBRL GL instances and yet are still required to be present in an instance. These rules provide guidance for how to deal with those constructs.

This document assumes a working knowledge of the XBRL 2.1 Specification [XBRL] 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 XBRL GL reporting in mind; some of the rules may be inappropriate for or inapplicable to other types of business reporting.

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.

Some rules in this document have general applicability to all XBRL documents. At some time in the future these might be separated into their own document but at this time they are identified by having the notation “(General)” after them.

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 Error! Reference source not found.) 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.
GLIS	XBRL GL Instance Standards (this document).
GLIS compliant (GLIS-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.
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. XBRL GL is highly tuple based.

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 GL instance creators have the option of creating one XBRL instance containing all the information in a particular journal (for example sales, purchases, inventory, payroll, job cost etc.), creating many XBRL instances that together make up the journal, or creating an instance containing data for multiple journals. 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 represent repetitive information in master files that are referenced at transaction level through IDs (for example the client master referenced in the sales invoice) as opposed to including all the information in each transaction. 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. (General)

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 XML files with <xbrl> as the root element should have the file extension .xml. (General)

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. Until an XBRL specific file extension (such as .xbrl) is commonly recognised by off the shelf software packages it has been found to be more conducive to general acceptance of XBRL instances not to use it. Therefore the extension .xml SHOULD be used in this case, although XBRL processors must be able to handle XBRL documents irrespective of the file extension.

2.1.3 The names of files that contain XBRL instances should not contain characters with different meanings across platforms. (General)

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.4 XBRL instances should use the same namespace prefixes as used in the XBRL schemas or conformance suite instances. (General)

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

Namespace prefix	Namespace identifier
xbrli	http://www.xbrl.org/2003/instance
xlink	http://www.w3.org/1999/xlink
link	http://www.xbrl.org/2003/linkbase
xsi	http://www.w3.org/2001/XMLSchema-instance
iso4217	http://www.xbrl.org/2003/iso4217

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.5 XBRL instances should use the recommended default namespace prefix for all namespaces. (General)

The namespace of each XBRL GL compliant taxonomy schema used by the instance should be bound to the “recommended default prefix” for that namespace. For example, http://www.xbrl.org/int/gl/cor/2005-07-12 should be bound to gl-cor.

2.1.6 Unused namespace declarations should not appear in XBRL instances. (General)

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.7 Irrelevant schema location hints should not appear in XBRL instances. (General)

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.8 An xsi:schemaLocation hint should not contain more than one namespace-location pair. (General)

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 goal 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.9 XBRL instances should order elements so that referents precede references. (General)

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

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.10 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. (General)

XBRL GL 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. (General)

The href attribute of the schemaRef element MUST point to the web location of the authoritative copy of a referenced taxonomy schema document.

For example, an instance author must not use relative URI references to point to a copy of the approved version of gl-cor-2005-07-12.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 gl-cor-2005-07-12.xsd elsewhere on the web. The approved taxonomy gl-cor-2005-07-12.xsd MUST only be referred to at its authoritative location.

2.3 linkbaseRef

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

The href attribute of the linkbaseRef element must contain the web location of an authoritative copy of the referenced linkbase document.

For example, an instance author must not use relative URI references to point to a copy of the approved version of gl-cor-2005-07-12-label-ja.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 gl-cor-2005-07-12-label-ja.xml elsewhere on the web.

2.4 Contexts

Most of the contextual information in XBRL GL instances is carried as facts in tuple structures in the instance itself instead of in a <context> element that is referred to by a contextRef attribute on the fact. However, since XBRL requires all facts to have an associated context and certain parts of the <context> element are also obligatory, there needs to be rules as to their content. A consequence of the following rules as applied to XBRL GL instances is that there should be only one context in any XBRL GL instance per <accountingEntries> structure, each of which might refer to a different entity.

2.4.1 An instance must not contain s-equal contexts. (General)

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

</entity>

</period>

</context>

</entity>

</period>

</context>

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. (General)

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 Entities

2.4.3.1 Existing authoritative identifier schemes should be used. (General)

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.

2.4.4 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]). Since this information is carried as facts in XBRL GL instances it is inappropriate to use the segment portion of an entity in such instances.

The scenario portion of a context is used to distinguish between different types of fact, e.g. “actual”, “budgeted”, “restated”, and “pro forma”. Again, this information is carried as facts in XBRL GL instances and so it is inappropriate to use the scenario portion of a context in such instances.

2.4.4.1 The segment and scenario portions of the context SHOULD NOT be used.

Information that might otherwise be carried by segments and scenarios is reported as facts in XBRL GL instances. This rule is not mandatory so as to allow for an appropriate use of segment or scenario should one be devised in the future.

2.4.5 Period

The period portion of a context is designed to indicate the instant or period of time associated with a fact. However, in XBRL GL instances, there is often more than one instant or period associated with any one fact and so this information is carried within an enclosing tuple structure as a fact or facts. The period information in the context is, therefore, somewhat redundant but is required to be present according to [XBRL]. Therefore it is appropriate to follow a convention as to how it should be used.

2.4.5.1 The period portion of the context SHOULD be the date (or date and time) of creation of the instance.

All XBRL GL item concepts have periodType specified as “instant”. The date, or possibly the date and time (if appropriate), of creation of the instance is a piece of information that is relevant to every XBRL GL instance and so, by convention, SHOULD be the value reported here. This is only automatically testable to the extent that every context in the instance SHOULD have the same instant in the period portion as a consequence of this rule.

2.4.6 There SHOULD be only one context in any XBRL GL instance per <accountingEntries> structure.

This is a consequence of all the above rules and the fact that each occurrence of an <accountingEntries> structure might refer to a different entity.

2.5 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. However, this information is usually carried as a fact in an XBRL GL instance so rules are needed to ensure consistency.

2.5.1 An instance must not contain s-equal units. (General)

s-equal units introduce undesirable redundancy.

2.5.2 An instance must not contain unused units. (General)

Unused units introduce extraneous information.

2.5.3 Standard units should be used in measure elements. (General)

Standard units increase comparability of numeric items.

2.5.4 Each unit should appear with only one scale factor in a given instance. (General)

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

Example 2. Allowed unit sets.

<unit id="km"><measure>kilometer</measure></unit>

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 3. Disallowed unit sets.

<unit id="musd"><measure>my:MillionsUSD</measure></unit>

<unit id="km"><measure>my:kilometer</measure></unit>

<unit id="m"><measure>my:meter</measure></unit>

<unit id="mm"><measure>my:millimeter</measure></unit>

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 3 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.5.5 Units SHOULD be consistent with the units for the fact that are carried in the instance as facts themselves.

The XBRL GL taxonomies provide the means to identify the units of various facts as facts themselves. For example, in the gl-bus:measurable tuple structure the units in which the concept gl-bus:measurableQuantity are expressed are carried in the concept gl‑bus:measurableUnitOfMeasure. Since gl-bus:measurableQuantity is a numeric concept it must have a unitRef attribute associating a unit with it according to [XBRL]. Depending on the unit involved it may or may not be possible to use the same syntax to express the units in both places. For this reason conformance with this rule cannot be tested in an entirely automated fashion.

2.6 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.6.1 Concepts appearing in the content model of a tuple must not appear at top level. (General)

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.6.2 Every non-nil tuple must contain at least one item directly or indirectly. (General)

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 4. Disallowed tuple containing no items.

<?xml version="1.0" encoding="UTF-8"?>

</entity>

</period>

</context>

</unit>

<ar:activity>

<ar:taxStatus contextRef="c5">TaxFavored</ar:taxStatus>

<ar:service/>

</ar:activity>

</xbrl>

2.6.3 Top-level tuples must not have true as the value of the xsi:nil attribute. (General)

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 5. nil nested tuple

<xbrl

xmlns="http://www.xbrl.org/2003/instance"

xmlns:link="http://www.xbrl.org/2003/linkbase"

xmlns:xlink="http://www.w3.org/1999/xlink"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://xbrl.csrc.gov.cn/fr/ar/2004

http://xbrl.csrc.gov.cn/fr/ar/2004/csrc-ar-2004-04-01.xsd"

xmlns:ar="http://xbrl.csrc.gov.cn/fr/ar/2004"

xmlns:iso4217="http://www.xbrl.org/2003/iso4217">

xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"

xlink:href="http://xbrl.csrc.gov.cn/fr/ar/2004/csrc-ar-2004-04-01.xsd"/>

</entity>

</period>

</context>

</unit>

<ar:activity>

<ar:taxStatus contextRef="c5">TaxExempt</ar:taxStatus>

<ar:service>

<ar:serviceName contextRef="c5">Education</ar:serviceName>

<ar:serviceRevenue decimals="INF" contextRef="c5" unitRef="cny">5000</ar:serviceRevenue>

<ar:serviceCosts decimals="INF" contextRef="c5" unitRef="cny">4400</ar:serviceCosts>

<ar:serviceGross decimals="INF" contextRef="c5" unitRef="cny">600</ar:serviceGross>

</ar:service>

<ar:product>

<ar:productName contextRef="c5">Vehicles</ar:productName>

<ar:productRevenue decimals="INF" contextRef="c5" unitRef="cny">9900</ar:productRevenue>

<ar:productCosts decimals="INF" contextRef="c5" unitRef="cny">7200</ar:productCosts>

<ar:productGross decimals="INF" contextRef="c5" unitRef="cny">2700</ar:productGross>

</ar:product>

</ar:activity>

<ar:activity>

<ar:taxStatus contextRef="c5">TaxFavored</ar:taxStatus>

<ar:service>

<ar:serviceName contextRef="c5">Telecommunications</ar:serviceName>

<ar:serviceRevenue decimals="INF" contextRef="c5" unitRef="cny">10000</ar:serviceRevenue>

<ar:serviceCosts decimals="INF" contextRef="c5" unitRef="cny">5000</ar:serviceCosts>

<ar:serviceGross decimals="INF" contextRef="c5" unitRef="cny">5000</ar:serviceGross>

</ar:service>

</ar:activity>

<ar:activity>

<ar:taxStatus contextRef="c5">FullyTaxable</ar:taxStatus>

<ar:service xsi:nil="true"/>

</ar:activity>

</xbrl>

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 6. nil top-level tuple (counterexample)

</entity>

</period>

</context>

</unit>

<ar:product>

<ar:productName contextRef="c5">Vehicles</ar:productName>

<ar:productRevenue decimals="INF" contextRef="c5" unitRef="cny">9900</ar:productRevenue>

<ar:productCosts decimals="INF" contextRef="c5" unitRef="cny">7200</ar:productCosts>

<ar:productGross decimals="INF" contextRef="c5" unitRef="cny">2700</ar:productGross>

</ar:product>

<ar:service xsi:nil="true"/>

</xbrl>

2.6.4 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 to determine whether fact values should be positive or negative. In XBRL GL this is generally the case.

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

2.6.5 Items and Tuples should not have false as the value of the xsi:nil attribute (General).

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 7. Explicit xsi:nil="false" counterexample.

<identifier scheme="http://www.sampleCompany.com">Sample Company</identifier>

</entity>

</period>

</context>

</unit>

<ifrs-gp:CashCashEquivalents contextRef="Current_AsOf" unitRef="U-Euros" decimals="INF" xsi:nil="false">42</ifrs-gp:CashCashEquivalents>

</xbrl>

2.6.6 Numeric facts should use the decimals attribute (General).

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.6.7 Textual facts represented in more than one language SHOULD use the xml:lang= attribute to indicate the language of the text content.

XBRL permits the addition of attributes from non-XBRL namespaces to facts but provides no explicit semantics for them. The XML specification [XML], however, provides a special attribute, xml:lang, to specify the language used in the contents and attribute values of any element in an XML document (see http://www.w3.org/TR/xml11#sec-lang-tag). This attribute SHOULD be used to indicate the language of the text content of a fact where necessary.

Example 8. Use of xml:lang to indicate language content

<accountMainDescription xml:lang="en" contextRef="nnc01">Text in English goes here</accountMainDescription>
<accountMainDescription xml:lang="ru" contextRef="nnc01">Text in Russian goes here</accountMainDescription>

A References (non-normative)

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

[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 2005-04-25
	http://www.xbrl.org/SpecRecommendations/

[XML]	World Wide Web Consortium.
	Extensible Markup Language (XML) 1.1
	http://www.w3.org/TR/xml11

[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 3 below lists each of the rules along with

· Its text;

· whether it is mandatory or not;

· whether it is objectively testable by software;

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 3. Suggested automation approaches for all rules.

Rule	Text	Mandatory.	Testable.	Remarks
2.1.1	The DTS components discoverable from an instance must be XBRL-valid.	Yes	Yes
2.1.2	XML files with <xbrl> as the root element should have the file extension .xml.	No	Yes
2.1.3	The names of files that contain XBRL instances should not contain characters with different meanings across platforms.	No	Yes
2.1.4	XBRL instances should use the same namespace prefixes as used in the XBRL schemas or conformance suite instances.	No	Yes
2.1.5	XBRL instances should use the recommended default namespace prefix for all namespaces. (General)	No	Yes
2.1.6	Unused namespace declarations should not appear in XBRL instances.	No	Yes
2.1.7	Irrelevant schema location hints should not appear in XBRL instances.	No	Yes
2.1.8	An xsi:schemaLocation hint should not contain more than one namespace-location pair.	No	Yes
2.1.9	XBRL instances should order elements so that referents precede references.	No	Yes
2.1.10	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
2.2.1	If a taxonomy schema document has an authoritative location, it must be referred to by that location.	Yes	Yes
2.3.1	If a linkbase document has an authoritative location, it must be referred to by that location.	Yes	Yes
2.4.1	An instance must not contain s-equal contexts	Yes	Yes
2.4.2	An XBRL instance SHOULD not contain unused contexts.	No	Yes
2.4.3.1	Existing authoritative identifier schemes should be used.	No	No	There is no universally agreed set of ‘authoritative’ identifier schemes.
2.4.4.1	The segment and scenario portions of the context SHOULD NOT be used.	Yes	Yes
2.4.5.1	The period portion of the context SHOULD be the date (or date and time) of creation of the instance.	No	No
2.4.6	There SHOULD be only one context in any XBRL GL instance per <accountingEntries> structure.	No	Yes
2.5.1	An instance must not contain s-equal units.	Yes	Yes
2.5.2	An instance must not contain unused units.	Yes	Yes
2.5.3	Standard units should be used in measure elements	No	No	There is no universally agreed set of ‘standard’ units.
2.5.4	Each unit should appear with only one scale factor in a given instance.	No	No
2.5.5	Units SHOULD be consistent with the units for the fact that are carried in the instance as facts themselves.	Yes	No
2.6.1	Concepts appearing in the content model of a tuple must not appear at top level.	Yes	Yes
2.6.2	Every non-nil tuple must contain at least one item directly or indirectly.	Yes	Yes
2.6.3	Top-level tuples must not have true as the value of the xsi:nil attribute.	Yes	Yes
2.6.4	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
2.6.5	Items and Tuples should not have false as the value of the xsi:nil attribute (General).	No	Yes
2.6.6	Numeric facts should use the decimals attribute (General).	No	Yes
2.6.7	Textual facts represented in more than one language SHOULD use the xml:lang= attribute to indicate the language of the text content.	No	No

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 to numerous to mention individually. We are grateful to all of them for their contributions.

E Document History (non-normative)

Date	Editor	Summary
2005-09-08	Wallis	Took FRIS Public Working Draft document to use as basis for GLIS initial IWD and edited to make appropriate for XBRL GL use
2005-10-18	Wallis	Incorporated input from Cohen, Garbellotto, Goto and Hamscher for new IWD
2005-10-26	Wallis	Added xml:lang section 2.6.7
2005-11-11	Wallis	Updated to indicate Candidate Recommendation Status
2006-10-11	Fedor	Updated to indicate Proposed Recommendation Status, FRTA errata update
2006-10-25	Fedor	Updated contact Information and affiliation for Garbellotto and Mueller, and Approval Process Dates
2007-04-17	Wallis	Editorial to reflect RECOMMENDATION status

Name	Contact	Affiliation
Jeff Fedor	jeff.fedor@gmail.com	InDimensions Systems Inc
Hugh Wallis	hughwallis@xbrl.org	XBRL International Inc.

Name	Contact	Affiliation
Eric E. Cohen	eric.e.cohen@us.pwc.com	PricewaterhouseCoopers
George Farkas	gfarkas@xbisoftware.com	XBI Software
Gianluca Garbellotto	gg@iphix.net	Iphix
Masatomo Goto	mg@us.fujitsu.com	Fujitsu Laboratories Of America, Inc.
Walter Hamscher	walter@hamscher.com	Standard Advantage
Diane Mueller	diane@justsystems.com	Justsystems Canada
Nobuyuki Sambuichi	n-sanbuichi@hitachi-system.co.jp	Hitachi Systems and Services, Ltd.