Finance:XBRLS

From HandWiki

XBRLS (XBRL Simple Application Profile) is an application profile of XBRL.

XBRLS is designed to be 100% XBRL compliant. The stated goals of XBRLS are "to maximize XBRL's benefits, reduce costs of implementation, and maximize the functionality and effectiveness of XBRL".[1] XBRL is a general purpose specification, based on the idea that no one is likely to use 100% of the components of XBRL in building any one solution. XBRLS specifies a subset of XBRL that is designed to meet the needs of most business users in most situations, and offers it as a starting point for others. This approach creates an application profile of XBRL (equivalent to a database view but concerned with metadata, not data).

XBRLS is intended to enable the non-XBRL expert to create both XBRL metadata and XBRL reports in a simple and convenient manner. At the same time, it seeks to improve the usability of XBRL, the interoperability among XBRL-based solutions, the effectiveness of XBRL extensions and to reduce software development costs.

The profile was created by Rene van Egmond and Charlie Hoffman, who was the initial creator of XBRL. It borrows heavily from the US GAAP Taxonomy Architecture.

XBRLS Architecture

The XBRLS architecture is based on many ideas used by the US GAAP Taxonomy Architecture. The intent of the XBRLS architecture is to make it easier for business users to make use of XBRL, to make it easier for software vendors to support XBRL, and to safely use the features of XBRL. XBRLS is a subset of what is allowed by the complete XBRL Specification. Examples of these limitations placed on XBRL are the following:

  • Uses no tuples.
  • Only uses the segment element of the instance context and disallows the use of the scenario element.
  • Allows only XBRL dimensional information as content for the segment element in the instance context. Furthermore, it requires that every concept (member, primary item) participates in a hypercube and that all hypercubes are closed.
  • Allows no uses of simple or complex typed members within XBRL Dimensions.
  • XBRLS never uses the precision attribute, always uses the decimals attribute.
  • Requires that every measure exists in at least one XBRL Dimension.

XBRL Components not used in XBRLS

XBRL Specification Topic Explanation
Instance Context: entity identifier, entity scheme Although not required when using XBRLS, it is highly encouraged that the entity scheme and identifier be “held static” or synchronized with an explicit member and rather have XBRL Dimensions be used to articulate entity information, perhaps with an XBRLS “Entity [Axis]” dimension.

The “entity identifier” and “entity scheme” portion of a context should not be used. Rather, the “entity identifier” and “entity schema” are static (i.e., dummy values in order to pass XBRL validation), using constant values. The information articulates relating to the entity identifier and entity scheme are moved to an XBRLS specific taxonomy that makes use of XBRL Dimensions to communicate this information.

Instance Context: period Although not required when using XBRLS, it is highly encouraged that the period context be “held static” or synchronized with an explicit member and that rather XBRL Dimensions be used to articulate this information, perhaps with an XBRLS “Period [Axis]” dimension.

Uses XBRL Dimensions to articulate this XBRL quasi dimension.

Instance (sections 4.7.4 and 4.7.3.2) Context: segments, scenarios Only uses XBRL Dimensions to articulate the content of segments and scenarios, excluding the use of XML Schema-based contextual information allowed by sections. Furthermore, mixing XML Schema based-contextual information and XBRL Dimensions is technically dangerous.
Instance Fact Value: precision Uses only the decimals attribute, precision must not be used.
Taxonomy Elements: tuples Tuples are not allowed.
Taxonomies Weight The weight attribute value of calculations must be either “1” or “-1”, no decimal value between the two is allowed.
Taxonomies Annotation, Documentation Each schema and each linkbase must provide documentation that describes the contents of the file that is readable by a computer application.
Dimensions Open Hypercubes Open hypercubes are not allowed, only closed hypercubes are allowed.
Dimensions notAll Only “all” has-hypercube arcroles are allowed, “notAll” is not allowed
Dimensions Typed Members Typed members (simple or complex) are not allowed.

Footnotes

External links