XBRL Abstract Model 2.0

Public Working Draft 06 June 2012

Copyright © 2011, 2012 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/abstractmodel-primary/PWD-2012-06-06/abstractmodel-primary-PWD-2012-06-06.html>
Editors:
Dave Frankel, Formerly SAP <dsfrankel@yahoo.com>
Herm Fischer, Mark V Systems <fischer@markv.com>
Warwick Foster, <warwick@foster.net>
Raymond Lam, XBRL International Inc. <rayl@xbrl.org>
Contributors:
Roland Hommes, Rhocon <roland@rhocon.nl>
Hugh Wallis, Standard Dimensions <hugh@standarddimensions.com>
Jasdeep Singh Kaler, Infosys <jasdeepsk@infosys.com>
Marc Delbaere, Society for Worldwide Interbank Financial Telecommunication <Marc.DELBAERE@swift.com>
Masatomo Goto, Fujitsu <mg@jp.fujitsu.com>
Patrick Slattery, Canopach <xbrl@canopach.com>
Rob Nehmer, Oakland University <robnehmer@gmail.com>
Shweta Gupta, IRIS <shweta.gupta@irisbusiness.com>
Srinivas Murty, Ez-XBRL Solutions <srinivas.murty@ez-xbrl.com>
Walter Hamscher, U.S. Securities and Exchange Commission <walter@hamscher.com>
Yuta Tanaka, Fujitsu <tanaka.yuuta@jp.fujitsu.com>

Status

Circulation of this Public Working Draft is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to modelling-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This document presents an abstract meta-model for the semantics that have been defined in the XBRL 2.1 [XBRL 2.1] and Dimensions 1.0 [DIMENSIONS] specifications, considering how these semantics are used by XBRL 2.1 with its extension modules and framework taxonomies, including Formula 1.0 [FORMULA], Table Linkbase 1.0 [TABLELINKBASE], Versioning 1.0 [VERSIONING], and Global Ledger Taxonomy Framework [GLOBALLEDGER]. The meta-model is based on concepts and modeling technology, to the degree possible, of the Common Warehouse Metamodel [OMGCWM].

Comments

1 Herm Fischer:In this layer it has been difficult to get specific API of implementing OLAP products with both sparse and vast cubes (ROLAP vs MOLAP) and combinatorial (cross product) aspect selection groups. The OLAP product implementations seem to have neither API nor features for cross-dimensions-product area specification. They appear to implement single-dimension CubeRegion specifications only, as in the example of the CWM Developers Guide. A call with Christian Bremeau and his co-workers appears to confirm this issue. A way to think of it is that MOLAP is more like XBRL hypercube implementations, in that we're never going to completely enumerate the dimensional cartesian-product space (as ROLAP might), and as a MOLAP is implemented by dynamic queries, an XBRL engine is likely to implement XBRL dimensions by "assisted" dynamic DRS traversal at runtime (at least that's what Arelle does) instead of attempt to completely populate in advance the cube combinations (which might need Avigadro's number of RAM chips).
2 Warwick Foster:At this stage the relationship between the Cube and the Table will restrict the domain of the table to the associated cubes. If it is omitted the cube validity of the reported data is still achieved through the Aspects in the table.
3 Dave Frankel:We are not clear that labels and references will be first class objects in the metamodel. RAS-like stuff can go here. Not clear yet on relationship between the Document and DTS packages.
4 Herm Fischer:Labels that comprise formal internal semantic definition, and references that comprise formal external semantic definition, to such extent as that, do belong perhaps in the data dictionary.
5 Warwick Foster:At this stage our primary focus has been on the primary model. As such, at this stage, the primary model is more advanced than the secondary model with regards to our current thinking about XBRL.
6 Herm Fischer:This model represents a secondary layer of XBRL Instances, as using top layer meta model constructs. The ordinary instance seems substantially different from that of PWD 1.0 but I think it maps nicely into data points (and DTS). It also ties some stuff of great interest to auditors to the semantics (the document, or serialized XML media)
7 Herm Fischer:One may realize that versioning could evolve to a 2.0 to re-invent the concept-based event reporting into aspect-based event reporting.
8 Herm Fischer:This model makes me want to propose a GL aspect model (for formula and versioning), and stop using the FR aspect model for formulas upon GL entries.
9 Warwick Foster:This section is no longer reference by the Magic files. I suggest we pull it out.
10 Warwick Foster:This section is no longer reference by the Magic files. I suggest we pull it out.
11 Warwick Foster:This section is no longer reference by the Magic files. I suggest we pull it out.

Table of Contents

1 Overview
1.1 Charter
1.2 Scope
1.3 Model vs. meta-model
1.3.1 Domain modelling
1.4 Layered modelling
1.5 Relationship to other work
1.6 Language independence
2 PackagingColour Schemes
3 Primary model
3.1 Model Elements
3.1.1 Class DataPoint
3.1.2 Class Aspect
3.1.3 Class AspectValue
3.1.4 Class RelationshipType
3.1.5 Class RelationshipSet
3.1.6 Class Relationship
3.1.7 Class AxisOrdinate
3.2 Data Dictionary
3.2.1 Aspects
3.2.1.1 Class EnumerableAspect
3.2.1.2 Class NonEnumerableAspect
3.2.1.3 Class AspectValueSet
3.2.1.4 Class AspectValueRelationship
3.2.2 Relationships
3.2.2.1 Class Relationship
3.2.2.2 Class RelationshipType
3.2.2.3 Class RelatableElement
3.2.3 Resources
3.3 Instances Model
3.3.1 Class DataPoint
3.4 Valid Combinations Model
3.4.1 Cube
3.4.2 CubeRegion
3.4.3 AspectValueSelectionGroup
3.4.4 AspectValueSelection
3.5 Table Model
3.5.1 Table
3.5.2 Axis
3.5.3 Table Cells
3.6 Document Model
3.6.1 Manifest
3.7 DTS Model
3.8 Typing Model
3.8.1 AtomicAspect
3.8.2 StructuredAspect
4 Secondary model - XBRL
4.1 XBRL Instance
4.1.1 Exploded Diagrams
4.2 XBRL Inline Instance
4.3 XBRL DTS
4.3.1 Exploded Diagrams
4.4 XBRL Dimension
4.4.1 Exploded Diagrams
4.5 XBRL Table
4.6 XBRL and XML Typing
4.6.1 Exploded Diagrams
4.7 XBRL Formula
4.7.1 Exploded Diagrams
4.7.2 XBRL Formula Filters
4.8 XBRL Versioning
5 Secondary model - Global Ledger
5.1 XBRL Ledger Instance
6 Secondary model - Financial Report Logical Model
6.1 Finanacial Report
7 Feedback requested

Appendices

A
A.1 Extensible Element
A.1.1 Class ExtensibleElement
A.1.2 Class UserDefinedProperty
A.2 Appendix 1 - Examples of the models
A.2.1 Data DictionaryGAAP DictionaryIFRS Dictionary
A.2.2 Prime 1
A.2.3 Fixed predefined tables
A.2.4 Fixed predefined tables
A.2.4.1 Table example 0101
A.2.4.2 Table example 0102
A.2.4.3 Table example 0103
A.2.4.4 Table example 0104
A.2.4.5 Table example 0105
A.2.4.6 Table example 0106
A.2.4.7 Table example 0107
A.2.4.8 Table example 0108
A.2.4.9 Table example 0109
A.2.4.10 Table example 0110
A.2.4.11 Table example 0111
A.2.4.12 Table example 0112
A.2.4.13 Table example 0113
A.2.5 Fixed table with an open axis
A.2.5.1 Table example 0201
A.2.5.2 Table example 0202
A.2.5.3 Table example 0203
A.2.6 Financial Reports
A.2.6.1 Table example 0301
A.2.6.2 Table example 0302
A.2.6.3 Table example 0303
A.2.7 Unused contexts Reports
A.3 Global Ledger Reports
A.3.1 Table example 0401
A.3.2 Table example 0402
B References
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)
F Errata corrections in this document


1 Overview

This document presents a meta-model for XBRL 2.1 [XBRL 2.1] and Dimensions 1.0 [DIMENSIONS] that separates the semantics defined in those specifications from their syntactical representation.

The meta-model will serve as a valuable technical resource that communicates the fundamental semantic value of these specifications.

1.1 Charter

The charter for the Abstract Modelling Task Force was defined by the XBRL Standards Board in these terms:

  • Scope: The abstract modelling task force will be responsible for delivering an UML model which captures the semantics of the XBRL 2.1 core specification and the Dimensions 1.0 specification. The UML model will capture the fundamental¬structures and design of XBRL and XBRL Dimensions as standalone UML artefacts, decoupled from any specific XML syntactical details. The scope was expanded in December 2011 to include the use of these semantics by XBRL extension modules including Formula, Table Linkbase, Versioning, and to base the meta-model on accepted industry meta-modeling technology.
  • Deliverables: The abstract model is likely to include use case diagrams, class diagrams, object diagrams, sequence diagrams and other such diagrams as may be later defined by the task force.
  • Audience: The abstract model will be developed with a specific focus towards software engineering, as a means of establishing a common framework for communicating and understanding the XBRL technology. The audience was expanded in October 2011 to include using this meta-model to serve as the basis for the future rewrite of all of XBRL specifications, training material, and a future standard API.

1.2 Scope

The Abstract Model is intended to cover the current and future use of XBRL including by its extension modules, both in 2012 syntax (based on XML) and in future use anticipated by mapping onto database technologies such as modeled by OLAP [OMGCWM].

1.3 Model vs. meta-model

To frame the efforts of the Abstract Modelling Task Force properly, it is important to understand the distinction between modelling and meta-modelling. Whereas a model is typically a representation of some phenomena in the real world, a meta-model is more concerned about describing and defining the actual modelling framework that is used to construct the model.

As an example, consider how common modelling frameworks, such as SQL, XML and UML, would contrast against each other at the meta-model level:

  • SQL would be defined in terms of tables, rows, columns, primary keys, foreign keys, etc.
  • XML would be defined in terms of elements, attributes, namespaces, etc.
  • UML would be defined in terms of classes, attributes, operations, associations, generalizations, etc.

In the 1.0 version of the Abstract Model, XBRL at the meta-model level had been defined in terms of concepts, facts, relationships, etc. This was deemed by reviewers to be too close to the syntax based on XML, and not reflective of the meta modeling achievable for XBRL and needed for realization of XBRL with database technologies as needed for large-scale consumption. The meta-model presented in this document describes XBRL in terms of data points (based on common usage of the term, hypercubes and regions, based on OLAP meta-modelling, and Tables based on the XBRL Table Linkbase. This meta-model is described in layers that can be mapped down to the syntactical abstractions in XML realization of XBRL, as well as to alternative realization of XBRL by OLAP implementations and other semantic modelling facilities.

1.3.1 Domain modelling

Once the traits of a meta-model are understood, IT professionals can then apply the meta-model to their task of modelling a specific domain. Meta-models are not responsible for expressing domain characteristics, but rather it is during the application of the meta-model to a given domain that domain-specific characteristics can be introduced into that specific instance of the meta-model.

Consequently, the meta-model presented in this document does not represent any specific taxonomy or domain project. However, it is anticipated that instances of this meta-model will eventually be created to communicate how XBRL has been applied in specific projects and taxonomies.

1.4 Layered modelling

A common issue that is addressed during modelling is that of scale, and identifying what level of abstraction or scale will be appropriate for the task at hand.

A fundamental principle which has guided the work of the Abstract Modelling Task Force has been to separate this issue of scale into 2 distinct layers of abstraction:

  • the Primary Layer - captures the pure semantics of XBRL and thus, as much as possible, is independent of the XML syntax
  • the Secondary Layer - captures the artefacts introduced by the XML syntax, OLAP based implementation, and other semantics technologies, and is thus a more direct representation of the concrete realizations of the specifications
Primary Secondary

The model presented in this document is the Primary Model, with a mapping to the Secondary Model for XBRL, and is thus focused more on the semantics of XBRL than on the syntax. For this reason, the reader should be aware that syntactical artefacts of XBRL (such as Contexts, Arcs, and Locators) do not appear in this model as they have been considered to be artefacts of syntax rather than having any semantic significance.

1.5 Relationship to other work

  1. Table Linkbase 1.0 [TABLELINKBASE],
  2. Formula 1.0 [FORMULA],
  3. Versioning 1.0 [VERSIONING], and
  4. Global Ledger Taxonomy Framework [GLOBALLEDGER].

The meta-model is based on concepts and modeling technology, to the degree possible, of the Common Warehouse Metamodel [OMGCWM].

This document pertains to XBRL as defined in the XBRL 2.1 Specification [XBRL 2.1].

This document pertains to XBRL Dimensions as defined in the Dimensions 1.0 Specification [DIMENSIONS].

This document pertains to XBRL Table Linkbase as defined in the XBRL Table Linkbase 1.0 [TABLELINKBASE].

This document pertains to XBRL Formula as defined in the XBRL Formula 1.0 [FORMULA].

This document pertains to XBRL Versioning as defined in the XBRL Versioning 1.0 [VERSIONING].

This document pertains to XBRL Global Ledger as defined in the XBRL Global Ledger Taxonomy Framework [GLOBALLEDGER].

This document pertains to XBRL artefacts realized using database technologies implemented using OMG OLAP [OMGCWM].

1.6 Language independence

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

2 Packaging

The abstract model has been broken down into these packages, each of which builds upon the next:

2 Colour Schemes

A color-coding scheme has been applied to the packages, and this scheme has been propagated throughout the classes in the class diagrams. To reinforce how the packages are related to each other there has been an effort made to ensure that at least one class from each of the packages appears in the relevant class diagrams.

  1. Goldenrod - NonEnumeratedAspects (Data point values, typed dimensions)
  2. Green - Aspects and EnumeratedAspects (Explicit dimensions, enumerations)
  3. Cyan - Relationships
  4. Peach - Cubes
  5. Beige - Datapoints

3 Primary model

3.1 Model Elements

Captures the tools used in meta modeling XBRL, elements that can be abstract named classes, and used for data points, aspects (classes of descriptions of data points), aspect values (specific descriptive values), and axis coordinates (points in a view bound to descriptive values).

The primary model classes are derived from OMG MOF elements and named elements. The named elements are those that have a human readable name (such as an XBRL concept label)

Model Elements

3.1.1 Class DataPoint

Semantics

The DataPoint metaclass defines a reportable item of business information contextualized by a set of aspects that identify or describe the item (this is an XBRL primary item fact), and a corresponding data point value (the reported item of business information).

Rationale

Data Points model reportable business information as classes of facts definable by the type of the data point value (including structure), and aspect values that contextualize the data point in the aspect model of the contextualization.

Properties

An DataPoint has a set of aspects values that identify or describe its instances, and an aspect value that is the data point's value.

A DataPoint has a base item aspect and Type, given by the data point value's aspect model to aspect relationship. This specifies its StructuringRelationship with other DataPoints (if any).

3.1.2 Class Aspect

Semantics

The Aspect metaclass defines an identifying or describing characteristic of a business information item data point (which is instantiated as a Fact's AspectValue, and may be organized into an ontology and internal or external semantics model).

Rationale

Aspects are identifying or classifying properties of data points, such as dimensions, names, date and unit of measurement.

Properties

A human-readable name (of the class of aspect).

An optional Type (prescribing its value and structure), and an optional explicit known-values set. Its AspectValues set may be enumerable. AspectValues may be organized into relationships (forming an ontology and possibly a semantics model).

An optional reference to a semantic vocabulary entry.

3.1.3 Class AspectValue

Semantics

The AspectValue metaclass defines a specific instance of value of an Aspect. The value is an identifying or classifying characteristic that a potentially realizable (or excluded) data point may have. If values are enumerable and known in advance, they may be organized into AspectValueRelationships which may form an ontology for the Aspect. If they have associated internal or external descriptions, they may form a semantics model for a related data point.

An instance of AspectValue is also used to model the data point's value.

Rationale

Values of aspects may form an ontology for those aspects that are classifying in nature, and in turn form a semantics model for data points associated to the aspect metaclass.

Properties

The value, which may be scalar (atomic), or structured.

A human-readable name.

An optional reference to a semantic vocabulary entry.

3.1.4 Class RelationshipType

Semantics

The RelationshipType metaclass defines a classification of relationships.

Rationale

Relationships must be identifiable and validatable.

Properties

A human-readable name.

The relationships of a RelationshipType may be limited to directed relationships.

The relationships of a RelationshipType may be restrict cycles.

3.1.5 Class RelationshipSet

Semantics

The RelationshipSet metaclass defines a collection of relationships.

Rationale

Relationships collections are manipulable for presentation, validation and classification purposes.

Properties

A human-readable name.

3.1.6 Class Relationship

Semantics

The Relationship metaclass defines a logical relationship between pairs of Aspects, AspectValues, DataPoints, Resources, and between Aspect and AspectValue, Aspect or DataPoint and Resource.

Rationale

Relationships are used to model reported data, metadata, and supporting features (such as labeling and computation).

Properties

A relationship has a pair of related elements.

A relationship has a kind. Indicating whether its logical role is that of subtype, subset, part-whole, equivalence, near-equivalence, or user-defined.

A relationship may be ordered (by having an order number).

3.1.7 Class AxisOrdinate

Semantics

The AxisOrdinate metaclass defines a correlation between AspectValue and Table, representing a view rendering. In a Table, an AxisOrdinate of the x axis corresponds to an identification of aspect values partially specifying of data points that may participate in the column, and an AxisOrdinate of the y axis corresponds to identification of aspect values partially specifying data points that may participate in the row. An AxisOrdinate of the z axis corresponds to identification of aspects values specifying data points that may participate in the entire table (view). The intersection of table-wide (z axis), column (x axis) and row (y axis) AxisOrdinates (together called coordinates) specify and constrain the data point instance facts that may appear in a cell of a table on output (rendering) of existing facts to a table, or specify how to create a fact when a value is typed into a cell of a table-view grid control. For example if an x-axis coordinate selected aspect values corresponding to reporting period date of 2008 (for a column) and a y-axis coordinate selected an aspect value representing property type of farms (for a row), the cell of a table for these coordinates would display a fact for farms reported in 2008.

Rationale

View specification uses the notion of coordinates to select and filter data by their aspect values.

Entry forms use the notion of coordinates to specify aspect values for facts representing entry form cell values (such as XBRL instance facts and their corresponding context and unit).

Properties

Axis coordinates represent position in a view and aspect values specification for that position. In the primary model, values are represented abstractly. In a secondary model, such as the XBRL Table Linkbase, a declarator for an axis coordinate, may represent coordinate values by rules, declarative logic, reference to aspect value sets (ontologic and semantic models), and declarative expressions.

3.2 Data Dictionary

3.2.1 Aspects

The Data Dictionary models Aspects that are the classes of identifying or descriptive characteristics of data points, which may be reported as business information items (Facts).

Aspects may be enumerable or non-enumerable. If enumerable there is a fixed, finite, and known-in-advance set of AspectValues. If non-enumerable, AspectValues are not specified within a data dictionary (class definition) and may be of a nature to be known only when business information is made available (such as from names, numbers, locations, and aspects whose instances are structured data).

For the case of enumerable Aspects, organized in AspectValueRelationships representing an identifying nature of a DataPoint (such as an element name or dimension) the AspectValueRelationships of that Aspect form an ontology (model of states of being), and may with other Aspects of the DataPoint, form a semantics model of the data point, if described formally (internally or externally). Otherwise, Aspects such as period date (such as when an account balance is taken), reporting entity (such as the business for whom the business information is reported), have no traditional ontological significance (they don't model states of the business information).

Aspects

3.2.1.1 Class EnumerableAspect

Semantics

The EnumerableAspect metaclass defines aspects that have scalar values known when specifying the model, in terms of finite value sets (e.g., named values, versus infinitely large sets, such as taxpayer IDs).

Rationale

Aspects which are identifying in nature may have scalar values that are enumerable.

Properties

An EnumerableAspect has a Name and a Type specifying its values.

3.2.1.2 Class NonEnumerableAspect

Semantics

The NonEnumerableAspect metaclass defines aspects that have large value sets (such as taxpayer IDs, people's names, GPS coordinates, or structured data such as addresses).

Rationale

Aspect which are identifying can be treated as data, such as addresses or number sets.

Properties

A non-enumerable aspect may have a Typed value, which may have structure.

3.2.1.3 Class AspectValueSet

Semantics

The AspectValueSet metaclass defines known enumerable values that an aspect may have. These values may be organized in a hierarchy. The AspectValueSet may represent an ontology for the class represented by the Aspect. If the aspect values, of aspect-value relationships in such an ontology are formally described, such as by structured description labels, they form an internal semantics model for the ontology. Aspect value descriptions may also be external, such as by use of XBRL references to external citations of defining regulations and by references to external semantics (such as OWL/RDF or SBVR).

Rationale

Aspect Value Sets may represent hierarchical pre-specified values for an Aspect.

Properties

An AspectValueSet has AspectValues, possibly organized into a hierarchy (by AspectValueRelationships), and possibly defined by internal or external semantics definitions.

3.2.1.4 Class AspectValueRelationship

Semantics

The AspectValueRelationship metaclass defines a graph of values of an AspectValueSet, providing any hierarchy and organizational ontology.

Rationale

Aspect Value Sets may be hierarchical (or other style of) graph.

Properties

Set organization and membership.

3.2.2 Relationships

The Data Dictionary models Relationships that relate aspects, aspect values, resources, and datapoints.

Relationships

3.2.2.1 Class Relationship

Semantics

The Relationship metaclass defines a graph of values of a RelatableElement, providing any hierarchy and organization.

Rationale

RelatableElements may be organized in Relationship sets.

Properties

The relationshipKind specifies whether a Relationship is a subtype, subset, part-whole, equivalence, near-equivalence, or user-defined kind.

The order specifies an optional ordinal position of a Relationship in its Relationship set.

3.2.2.2 Class RelationshipType

Semantics

The RelationshipType metaclass defines a relationship type.

Rationale

Relationships are classified by type.

Properties

The isDirected specifies whether the relationships form a directed cycle.

The allowsCycles specifies whether the graph may contain cycles.

3.2.2.3 Class RelatableElement

Semantics

The RelatableElement metaclass defines a superclass of elements that can be related.

Rationale

Relatable elements may be Aspect, AspectValue, DataPoint, or Resource.

Properties

3.2.3 Resources

Resources are things that describe or specify Elements of the Abstract Model. Resources may be labels, documentation, references to specifications and legislation, and components of models that provide rendering and viewing, validation, transformation, documentation, and support of instances of abstract model features. Resources may be contextualized by a data type, may have a role and content (such as label).

Resources

3.3 Instances Model

Captures DataPoint class instances that are facts (such as within a Document instance), that are related to the set of AspectValues that identify or describe the DataPoint (fact).

Instances Table model

A DataPoint is a reportable business item (representing business item facts that are represented by XBRL 2.1 facts, by XBRL Global Ledger entry details, and by OMG CWM measures).

This model captures how instances of a DataPoint are identified or described by the value combinations of the identifying Aspects (from the ontology of the data dictionary model)

DataPoints may be modelled by Aspects in many ways, with Aspect modelling choices reflecting the architecture of a reporting system, politics of organizations and information technologists, opinions of the designers, and experience-set of the implementers. Earlier tradition has been to designate each ontologically identified Aspect class (such as a business reporting chart of accounts Aspect) as a DataPoint with a unique "primary item" AspectValue (e.g., a separate XBRL concept name for each chart of accounts entry). Aspect modelling provides flexibility in such approaches, allowing the architect to reduce a or expand a collection of AspectValues between aspect classes. From a legacy charts of accounts, one can re-model the model of chart of accounts by fewer primary item accounts with more dimensions, such as by designating a nominative Aspect class (like the XBRL primary item) to be "asset" for multiple classes of assets, and use dimensions (additional Aspect classes) for identification of "asset" ontology.

For example, parties reporting agricultural assets might have a separate classifying primary item AspectValue, such as an account code, for farms, wheat, corn, sheep, and cows, but in a highly dimensional reporting scheme, might identify as primary item AspectValue only 'asset', and then specify different Aspects (dimensions) for property, agriculture and livestock, with additional Aspects (dimensions) for type of animal, type of crop, and so on.

A Data Point may be related to formulas, using the Aspects pertinent to its definition, which may either be for validation purposes, informational purposes, or to produce derived information.

3.3.1 Class DataPoint

Semantics

The DataPoint metaclass defines a class that is a unit of reported information (either an element of such information with FactValue or a structured aggregate of such information).

Rationale

DataPoint instances of reportable business information are Facts.

Properties

A DataPoint may have an AspectValue instance that is its FactValue (reported business information).

Each DataPoint has a set of AspectValues that identify or describe the DataPoint. Each DataPoint is related to the AspectValues (that identify and describe it) whereas each DataPoint is related to the set of Aspects (that have AspectValues for the Fact instance).

A DataPoint may have a StructuringRelationship with other DataPoints according to its Type

3.4 Valid Combinations Model

Between models of DataPoints and Tables of views of DataPoint Facts, is the model that specifies which DataPoints are may exist as Facts, based on valid combinations of their Aspects' AspectValues. From the term hypercube, representing dimensional aspects of a DataPoint, the sections of value-space in the hypercube that may validly represent facts is defined as a "Cube Region" (OMG CWM OLAP). This model captures how groupings of Aspect AspectValues form Cubes and CubeRegions of allowed (or by subtraction, disallowed) AspectValues. When instantiated, valid combinations models hypercubes of XBRL Dimensions as well as equivalent realizations possible with OLAP technologies

This model is based on CWM OLAP, representing instances of AspectValues (not declarators of sets of AspectValues in the secondary model). This is where one can model XBRL's syntax to express hypercubes (that are aspect value selections specifying cube regions), whether they are declared by positive and negative hypercubes, OLAP, or any other kind technology.

[Herm Fischer: In this layer it has been difficult to get specific API of implementing OLAP products with both sparse and vast cubes (ROLAP vs MOLAP) and combinatorial (cross product) aspect selection groups. The OLAP product implementations seem to have neither API nor features for cross-dimensions-product area specification. They appear to implement single-dimension CubeRegion specifications only, as in the example of the CWM Developers Guide. A call with Christian Bremeau and his co-workers appears to confirm this issue. A way to think of it is that MOLAP is more like XBRL hypercube implementations, in that we're never going to completely enumerate the dimensional cartesian-product space (as ROLAP might), and as a MOLAP is implemented by dynamic queries, an XBRL engine is likely to implement XBRL dimensions by "assisted" dynamic DRS traversal at runtime (at least that's what Arelle does) instead of attempt to completely populate in advance the cube combinations (which might need Avigadro's number of RAM chips). ]

Valid Combinations

3.4.1 Cube

Cube

The Cube metaclass defines a collection of CubeRegions that are associated with specified aspects to report.

The Primary Model Cube meta class associates models of instance values with aspects to report (e.g., aspects that form the typed value of data points). The secondary model lower level classes may associate cubes with concrete syntax such as XBRL hypercubes, that associate dimensions to reportable base items (concept primary items).

Rationale

Reportable aspects (base items) are associated with reportable sets of AspectValueSets (cube regions).

Properties

A Cube is expressed by CubeRegions and AspectsToReport.

3.4.2 CubeRegion

CubeRegion

The CubeRegion metaclass defines a cartesian product, for a set of Aspects, of enumerable AspectValues (corresponding to XBRL hypercubes after subtraction of negative hypercubes from positive hypercubes).

The Primary Model CubeRegion meta class is a model of instance values. The secondary model lower level classes may use declarative techniques to specify CubeRegions compactly. Large dimensions of many members may have large cartesian product-spaces of the dimensions, which may be represented algebraically or by means other than by complete specification of all enumerable AspectValue combinations in the cartesian-product of AspectValues of each Aspect. The CubeRegion may thus be a PrimaryModel contrivance implemented in the Secondary Model by more efficient means (such as XBRL positive hypercubes subtracting XBRL negative hypercubes).

Rationale

AspectValueSets have specific sets of allowed values, by ontological modelling of specific aspects, legislative and prudential control of reportable values, etc. The set of potential values must be determinable when modelling AxisOrdinates that can correspond to DataPoint instance facts or are not allowed to have Fact instances. This is needed when displaying input forms, based on AxisOrdinate tables, for example.

Properties

A CubeRegion is expressed by AspectValueSelectionGroups.

3.4.3 AspectValueSelectionGroup

AspectValueSelectionGroup

The AspectValueSelectionGroup metaclass defines a set of cartesian products of enumerable AspectValues.

Rationale

An AspectValueSelectionGroup is a set of allowed DataPoint AspectValues of facts that may exist in a CubeRegion.

Properties

An AspectValueSelectionGroup has a set of AspectValueSelections.

3.4.4 AspectValueSelection

AspectValueSelection

The AspectValueSelection metaclass defines a set of enumerable AspectValues that identify or describe a single DataPoint (Fact instance) to be allowed in an AspectValueSelectionGroup.

Rationale

An AspectValueSelectionGroup is a set of allowed DataPoint AspectValues for a Fact.

Properties

An AspectValueSelectionGroup has a set of Aspects and their AspectValue(s).

3.5 Table Model

This is a view layer, taken from the Table ideas of Data Points Modeling. The source material is the XII website WGN table linkbase overview, which is a declarator for table linkbases. Here this model instead represents instances of table views, not declarators of table views. For declarators the table linkbase is still relevant (as secondary concrete syntax).

This model captures how tables provide views of valid combinations of data points by relating aspect values to coordinates of viewing axes. It forms a meta-model for various presentation schemes including those of traditional XBRL instance rendering.

[Warwick Foster: At this stage the relationship between the Cube and the Table will restrict the domain of the table to the associated cubes. If it is omitted the cube validity of the reported data is still achieved through the Aspects in the table.]

Table model

3.5.1 Table

Table

The Table metaclass defines a view of selected Facts in a matrix layout in a Cartesian Space of a determined number of Axes. Ordinates of each Axis specify by AspectValue which Fact may, by the intersection of coordinates, appear in each cell of the matrix. CubeRegions further specify which of such AspectValue combinations may have realized Facts.

Rationale

Tabular presentation of business reports information items, in matrix layouts, is generally required.

Properties

A set of Axes defines, by the AxisOrdinates of each Axis, sufficient AspectValue specificity, so that for each combination of axis coordinate, an ImpliedDataPoint can be realized, or the matrix cell can be recognized as being excluded from the CubeRegion (disallowed).

A set of CubeRegions may be associated with a Table (such as to specify the kind of accounting schedule to appear in the table).

3.5.2 Axis

Axis

The Axis metaclass (plural: axes) defines a set of combinations of the AspectValues of a subset of the Aspects of viewable DataPoint Facts, and a certain arrangement of them along an imaginary line.

Rationale

Specification of a Table by the coordinates along each Axis may be more compact than specifying each cell in the matrix represented by the table (e.g., for a table of three columns and ten rows, thirty cells may be defined by thirteen coordinates, three by column and ten by row, instead of thirty by cell).

Properties

The axisDisposition specifies the display orientation of its coordinates. Typical two dimensional tables have three axis dispositions: x-axis, y-axis, and z-axis. The x-axis represents a horizontal arrangement of columns in a table, the y-axis represents a fourth-quadrant vertical progression of rows (except for right-to-left language cultures, where it is third-quadrant), and the z-axis represents an orthogonal axis of choices constraining the two-dimensional view. The x-axis horizontal column progression may be left-to-right, or right-to-left for tables in right-to-left language cultures (e.g. Arabic and Hebrew, to correspond to spreadsheet behaviour). The y-axis vertical column progression is always top to bottom. The z-axis may have multiple values, which can be used either for selection of display (such as by combo-boxes on a GUI) or for multiple tables (such as selected by tab, or output as successive document components).

Each axis has an ordered specification of AxisOrdinates that define tabular display along an imaginary line following a certain order. The position of a coordinate in a graphical representation of an axis is a monotonic sequence expressing where each coordinate from the axis lies in the ordered representation.

Axis headers, if provided, label the axes to communicate heading information about the cells at the intersection of rows and columns. Header information for a column is displayed at the top of a column. Header information for a row is displayed at the left of a row except for right-to-left tables, where it is displayed on the right of the row. The location to display z-axis and table headers is not constrained by this specification, but would usually be at the top of the table. Axis headers for axis dispositions that have multiple coordinate aspect values may use row and/or column spanning to graphically provide clarity of aspect coverage. Axis header information may be simplified when tables are rendered on media not meant primarily for human readability (such as CSV files, which lack a way to span or merge column headers).

3.5.3 Table Cells

Instances of tables are shown, to illustrate how the coordinate locations map to cells (as on a spreadsheet or grid). Each cell may have a compatible DataPoint that would render in a view, be editable, or if the cell were empty, be created by entering into a cell.

A DataPoint is compatible with a cell if its aspect values match all the aspect values associated with each axis for the coordinate position of the cell

If a cube is associated with a table by a validCube relationship, the aspect values of coordinates of a cell must be valid in the cube in order for any DataPoint to be compatible with the cell. Otherwise the cell is disallowed (no data presented, and not editable for entry).

If no validCube relationships are provided, but Cubes are specified, at least one must allow the aspect values of coordinates of a cell in order to be presented or entered. If no Cubes exist in the current model, then any DataPoint aspects are allowed and cube-compatibility is not checked.

Data Points Semantic Grounding

3.6 Document Model

Captures the packaging of realized instances of data points with their data dictionary model instances, valid combinations model instances, and table model instances. In present XBRL realization, it may be an XBRL instance document filing with accompanying taxonomy and linkbases.

Document model

3.6.1 Manifest

Manifest

The Manifest metaclass defines what is packaged in the Documennt.

Rationale

Specification of document contents includes Facts (e.g., their AtomicAspect value and identifying Aspects AspectValues, with reference to or inclusion of DataDictionary, Typing model, CubeRegions, Table model, and any Formulae. In the cases such as Inline XBRL the manifest also includes a rendering of the Facts.

Properties

Facts contained in the document.

DataDictionary representing contents of the document.

CubeRegion representing contents of the document.

Tables representing view(s) of contents of the document.

Formulae representing validations and derived information for the document.

3.7 DTS Model

Captures labels and references, abstractions of prohibition/override, formula, and validation.

[Dave Frankel: We are not clear that labels and references will be first class objects in the metamodel. RAS-like stuff can go here. Not clear yet on relationship between the Document and DTS packages.]

[Herm Fischer: Labels that comprise formal internal semantic definition, and references that comprise formal external semantic definition, to such extent as that, do belong perhaps in the data dictionary.]

DTS model

3.8 Typing Model

Captures the underlying types that have been defined by both XBRL 2.1, for use in data points fact values and aspect values.

Document model

3.8.1 AtomicAspect

AtomicAspect

The AtomicAspect metaclass defines an atomic value that a singluar instance of its structure may contain (such as number type, date, or string contents, or entries in a list).

Rationale

A fact may have FactValue (of its AtomicAspect) and an AspectValue of each of its DataPoint Aspects, each according to its DataType.

Properties

DataType describes the atomic value constraints.

3.8.2 StructuredAspect

StructuredAspect

The StructuredAspect metaclass defines an composition structure for a FactValue or AspectValue.

Rationale

DataTypes may be composed of structures, such as lists and hierarchies of specified atomic content.

Properties

StructuredAspect describes the compositional constraints of a DataType.

4 Secondary model - XBRL

The secondary XBRL model represents a layer of XBRL realization of the primary model, representing instances, discoverable taxonomy sets of taxonomies and linkbases, supporting type and particle model declarations of XML constructs for elements, attributes, and concepts, and extension models of formula and versioning. Starting first are an "ordinary" financial reporting instance, an inline XBRL instance, an XBRL discoverable taxonomy set (of schemas and linkbases), XML element and concept Types (including particles because they are the elements that are all over the instance model), atomic types (which mirror the primary model types layer but as concrete XML types), Dimensions, and for completeness Formula, filters (sort of), and Versioning.

[Warwick Foster: At this stage our primary focus has been on the primary model. As such, at this stage, the primary model is more advanced than the secondary model with regards to our current thinking about XBRL.]

4.1 XBRL Instance

[Herm Fischer: This model represents a secondary layer of XBRL Instances, as using top layer meta model constructs. The ordinary instance seems substantially different from that of PWD 1.0 but I think it maps nicely into data points (and DTS). It also ties some stuff of great interest to auditors to the semantics (the document, or serialized XML media)]

XBRL Instance

4.1.1 Exploded Diagrams

The next five diagrams present aspects of the diagram above in isolated parts so that the various relationships can be understood in part and all together.

XBRL Instance Aspect
XBRL Instance Element
XBRL Instance Fact
XBRL Instance FactItem
XBRL Instance xmlDocument

4.2 XBRL Inline Instance

The inline instance ties the document (serialized instance and elements) "above the transform" that are of interest to auditors, to the data points (and sort of obfuscated aspects) that are of interest to the business analyst

XBRL Inline Instance

4.3 XBRL DTS

This secondary model represents how XBRL declares its structural and ontological semantics. A lot of XBRL DTS concrete implementation is not part of data points or aspects, but is how the aspect to aspect relationships and aspect value selection cube regions are mechanized. They represent both typing (structural and atomic) and ontological semantics (via aspect values relationships hierarchy).

XBRL DTS

4.3.1 Exploded Diagrams

The next three diagrams present aspects of the diagram above in isolated parts so that the various relationships can be understood in part and all together.

XBRL DTS ElmentDeclarator
XBRL DTS ElmentDeclaratorRelationship
XBRL DTS XMLDocument

4.4 XBRL Dimension

This secondary model represents how XBRL declares its dimensions. They correspond to three primary model elements, aspects (that are dimensions), aspect value relationship sets and hierarchies (that represent both allowed values, and usually provide a concrete model of ontological semantics), and they provide a concrete means of implementing cube regions. The cube region implementation is by substraction of cross products of dimensions from very large and sparce multi-dimensional spaces.

XBRL Dimensions Overview
XBRL Dimensions

4.4.1 Exploded Diagrams

The next three diagrams present aspects of the diagram above in isolated parts so that the various relationships can be understood in part and all together.

XBRL Dimension DTS
XBRL Dimension DRSRelationship
XBRL Dimension Concept

4.5 XBRL Table

This secondary model represents how XBRL declares tables, their axes, filters, and coordinates.

xbrlTableLinkbase
xbrlTableLinkbaseInstance

4.6 XBRL and XML Typing

This secondary model represents how XBRL declares its typing and structural semantics in dual-interwoven models (XML's typing model and XML's particle models). In effect they implement the primary typing model, but the concrete issues differ.

XBRL Typing

4.6.1 Exploded Diagrams

The next two diagrams present aspects of the diagram above in isolated parts so that the various relationships can be understood in part and all together.

XBRL Typing Type
XBRL Typing UserDefined

4.7 XBRL Formula

This secondary model represents how XBRL declares its assertion sets and variable sets (representing the managed result-producing constructs of XBRL formula).

XBRL Formula

4.7.1 Exploded Diagrams

The next two diagrams present aspects of the diagram above in isolated parts so that the various relationships can be understood in part and all together.

XBRL Formula Associations
XBRL Formula Inheritance

4.7.2 XBRL Formula Filters

This secondary model represents how XBRL declares the filtering model used by both formula and rendering.

XBRL Formula Filter

4.8 XBRL Versioning

This secondary model represents how XBRL reports versioining events. They are based on notions of XBRL concept and inter-concept changes, as well as aspect model issues. Only the aspect modeling reporting directly represents primary layer issues. [Herm Fischer: One may realize that versioning could evolve to a 2.0 to re-invent the concept-based event reporting into aspect-based event reporting.]

XBRL Versioning

5 Secondary model - Global Ledger

The secondary Global Ledger model represents that financial reports come from ledgers (and journals), to show how ledger entries (GL) fit to data points (when not viewed as syntax). [Herm Fischer: This model makes me want to propose a GL aspect model (for formula and versioning), and stop using the FR aspect model for formulas upon GL entries.]

5.1 XBRL Ledger Instance

XBRL Ledger Instance

6 Secondary model - Financial Report Logical Model

A Financial Report Logical Model and its Report Elements are described in section 5, including details in section 5.19 [MDLBUSINFOXBRL], and "SEC Logical Model" [MDLBUSINFOXBRLDIAG].

6.1 Finanacial Report

This diagram relates the primary model elements to the Financial Report Logical Model.

Financial Report

The notion of a document as a collection of tables ("SEC Filing") is in the fujitsu "Rendering Linkbase" and has been introduced to the primary layer as a result of this model.

This logical model interleaves taxonomy and instance, description of class and property of instance, in a profound manner, but nonetheless the elements map to the concepts of the primary model.

Network is a cube region's table, it is used as such by the SEC viewer, and Edgar Filer Manual requires that it be constructed for that purpose.

Network, corresponds to an XBRL ELR, and as thus a cube region's set of aspects that have relationships, represented by a dashed line from cube region to relationships to concept elements (the presentation/calc/dimensional-relationship-set relationships).

Table (the term of this logical model, not the term of the primary layer) is represets XBRL concepts that are abstract, being used as root elements in hierarchies (because XLink requires root elements in this manner), and has absolutely ontologic meaning in the instance, and only tree-building-purpose in the presentation linkbase. It is not an identifying aspect of a data point primary item and doesn't correspond to any primary layer model elements.

Table (logical model term) is a syntactic contrivance to associate concept-to-concept relationships with a cube region of the table (mapped, as an XBRL ELR).

Relationships in XBRL relate to a table (as an organizing abstract concept not in the instance), and actually belong to the primary layer aspects of the cube region (both concept element and dimensional element aspects).

The logical model XBRL presentation relationships are there to organize the "y-coordinates" order of the concept-element aspects into rows of the table.

In logical model calculation relationships, may either be used for computational validation, or to capture XBRL ontological semantics not otherwise communicated (See use to identify concept aspects which are chosen in a nonstandard manner, and figures 3 - 5.[XBRLSECFILINGRATIOS]), but aren't otherwise aspect relationships of a fact-identification aspect model.

Fact is an instance of a data point. It does have a concept-element aspect but also it has domain member aspects. It doesn't have axes (dimensions) or domains (hierarchy-head members).

This logical model is valuable to show what might be perceived by people examining XBRL syntax and in enforcing modelling discipline.

7 Feedback requested

The Abstract Modelling Task Force is seeking your input and opinions on these specific topics:

  1. TBD

Feedback can sent to modelling-feedback@xbrl.org.

A.1 Extensible Element

[Warwick Foster: This section is no longer reference by the Magic files. I suggest we pull it out.]

The ExtensibleElement is an abstract base class which models how various elements in XBRL are extensible through the ability to add custom XML attributes to those elements. This class diagram expresses which of the equivalent metaclasses in the model have that extensibility, and how that extensibility is provided through the UserDefinedProperty class.

Extensible Element

A.1.1 Class ExtensibleElement

[Warwick Foster: This section is no longer reference by the Magic files. I suggest we pull it out.]

Semantics

ExtensibleElement defines the ability that deriving metaclasses have for providing user extensibility. Users can extend deriving metaclasses by adding their own custom instances of UserDefinedProperty.

Rationale

The XML schemas for XBRL instance documents and linkbases allow for attributes from any namespace on certain elements. The ExtensibleElement metaclass and the UserDefinedProperty metaclass have been provided to capture those metaclasses in the model that need to reflect this extensibility, which has been defined by the underlying XBRL 2.1 specification.

Properties

ExtensibleElement is defined through related instances of UserDefinedProperty.

A.1.2 Class UserDefinedProperty

[Warwick Foster: This section is no longer reference by the Magic files. I suggest we pull it out.]

Semantics

The UserDefinedProperty enables users to add their own custom Properties to the set of Properties already occurring on an instance of the ExtensibleElement metaclass.

Rationale

The XML schemas for XBRL instance documents and linkbases allow for attributes from any namespace on certain elements. The UserDefinedProperty metaclass and the ExtensibleElement metaclass have been provided to capture those metaclasses in the model that need to reflect this extensibility, which has been defined by the underlying XBRL 2.1 specification.

Properties

Each occurrence of this metaclass has a name property and a value property. Occurrences of this metaclass belong to a single instance of ExtensibleElement, which is addressable through the extensibleElement property.

A.2 Appendix 1 - Examples of the models

The purpose of this section is to present working examples of the models to show how they work and to identify gaps. The Magic draw tool we have been allowed to us will validate the diagrams against the meta models above. Through these examples we are able to prove the correctness of our modelling by completely asserting a solutions.

These models are being continuously expanded upon as we identify gaps and advance the model. Some work has been done to try an bring the examples to be able to be printed on a songle page. This work is ongoing.

Some of the diagrams are still under-construction and have yet to be released.

A.2.1 Data Dictionary

This first example will show how the dictionary of the terms of the taxonomy can be articulates. To acheive this we have chosen to present Cash and Accounts Receivable from both IFRS and the US-GAAP taxonomies.

A.2.1 GAAP Dictionary

Example_GAAP_Dictionary
Example_GAAP_AR_With_Structure
Example_GAAP_Cash_With_Structure

A.2.1 IFRS Dictionary

Example_IFRS_AR_with_Structure
Example_IFRS_Both_with_Structure
Example_IFRS_Cash_with_Structure
Example_IFRS_Dictionary

A.2.2 Prime 1

The primary example shows the various levels of the structure of the models and is set up to be a simple walk through of the basics of the model. This will follow the explanation of table example 0101.

Simple table, two rows represent primary items, two columns represent members of one dimension

Level1_Prime_All
Level2_Prime_All
Level3_Prime_All
Level5Data_Prime_All
Level5Struct_Prime_All_Table_Structure

A.2.3 Fixed predefined tables

The primary example shows the various levels of the structure of the models and is demonstrate how a cube can be constructed that restricts the reportable data to a set less than what is visible in the table. This will follow the explanation of table example 0101.

Simple table, two rows represent primary items, two columns represent members of one dimension

Level1_Prime_One_point_Omitted
Level2_Prime_One_point_Omitted
Level3_Prime_One_point_Omitted
Level5Data_Prime_One_point_Omitted
Level5Struct_Prime_Table_Structure_One_point_Omitted

A.2.4 Fixed predefined tables

Corresponds to XBRL examples of Eurofiling forms, usually represented by spreadsheet workbooks with multiple worksheet tables, each in a fixed format.

A.2.4.1 Table example 0101

Simple table, two rows represent primary items, two columns represent members of one dimension

Example0101_Level1
Example0101_Level2
Example0101_Level3
Example0101_Level5Data
Example0101_Level5Struct

A.2.4.2 Table example 0102

Same but columns represent two dimensions with fixed assignment of members to columns, both columns dimension D = member d0, column 1 dimension E = member e1 and second column dimension E – member e2

Example0102_Level1
Example0102_Level2
Example0102_Level3
Example0102_Level5Data
Example0102_Level5Struct

A.2.4.3 Table example 0103

Similar to example 2, but three columns, first has no value for dimension E (E is not in the context, could be default or absent), may represent an aggregation for columns 2 (E = e1) and 3 (E = e2). Uses a non-abstract aspect rule member for D, which causes the row-spanned column header appearance

Example0103A_Level1
Example0103A_Level2
Example0103A_Level3
Example0103A_Level5Data
Example0103A_Level5Struct_AR
Example0103A_Level5Struct_Cash
Example0103B_Level1
Example0103B_Level2
Example0103B_Level3
Example0103B_Level5Data
Example0103B_Level5Struct_AR
Example0103B_Level5Struct_Cash
Example0103C_Level1
Example0103C_Level2
Example0103C_Level3
Example0103C_Level5Data
Example0103C_Level5Struct_AR
Example0103C_Level5Struct_Cash

A.2.4.4 Table example 0104

An alternative way to represent the column for no E value, by an explicit coordinate with no E-dimension rule, instead of a non-abstract D coordinate member rule.

Example0104_Level1
Example0104_Level2
Example0104_Level3

A.2.4.5 Table example 0105

Demonstrates coordinate inheritance and override, second column overrides dimension D inherited from first column coordinate member

Example0105_Level1
Example0105_Level2
Example0105_Level3
Example0105AR_Level5Struct
Example0105Cash_Level5Struct

A.2.4.6 Table example 0106

Introduces use of z-axis (for a third dimension, F)

Example0106_Level1
Example0106_Level2
Example0106_Level3

A.2.4.7 Table example 0107

Z-axis has two values (causing Cartesian product with x/y axes)

Example0107_Level1
Example0107_Level2
Example0107_Level3
Example0107_Level5Data
Example0107_Level5Struct

A.2.4.8 Table example 0108

Introduces nested coordinate members in the z-axis.

Example0108_Level1
Example0108_Level2
Example0108_Level3

A.2.4.9 Table example 0109

Introduces two separate z-axes (so that the Cartesian cross-product of their members represent the coordinates on the z-axis).

Example0109_Level1
Example0109_Level2
Example0109_Level3

A.2.4.10 Table example 0110

Same as 9 but the two z-axes are merged into a single z-axis specifying each of the Cartesian cross product members as separate coordinate members.

Example0110_Level1
Example0110_Level2
Example0110_Level3

A.2.4.11 Table example 0111

A transposed two row, two column example with primary items in columns and dimensional coordinates in rows, and dimension D is explicitly removed in the second row coordinate member.

Example0111_Level1
Example0111_Level2
Example0111_Level3

A.2.4.12 Table example 0112

Two x-axes (of dimensions), causing the columns to represent the cross product columns of both dimensions, e.g., first pair of columns for value of D = d1 with two E-value columns, and then the second pair of columns for value of D = d2 with each E-value columns.

Example0112_Level1
Example0112_Level2
Example0112_Level3

A.2.4.13 Table example 0113

Similar but two y-axes, first a primary item coordinate, and nested second a dimension coordinate.

Example0113_Level1
Example0113_Level2
Example0113_Level3

A.2.5 Fixed table with an open axis

Corresponds to XBRL examples of Eurofiling forms where a range of rows or columns represent a variable number of entries (here distinguished by a typed dimension value).

A.2.5.1 Table example 0201

Open axis example. Rows are primary items, column is a typed dimension value (example is a simple typed dimension with a string value). A rendered table from an instance would have a dynamic number of columns, to represent the typed dimension values that have either primary item represented by a fact. If this were used as an entry form, the string value of the typed dimension would require an editable column header cell corresponding to the string value of the dimension.

Example0201_Level1
Example0201_Level2
Example0201_Level3

A.2.5.2 Table example 0202

Two x-axes, one predefined and one open. The table shows the top five ranked country dimensions for primary items (in rows). The first coordinate (column) is predefined, having typed rank value 1, second has rank 2, etc. The second coordinate for each column is the country dimension, an open Axis using a filter for the country dimension. Causes the country having rank one to be in second column header row of column 1, country of rank two in second column header row of column 2, etc.

Example0202_Level1
Example0202_Level2
Example0202_Level3

A.2.5.3 Table example 0203

A deposits-on-hand table in local currency and equivalent in Euros: The y axis represents a primary item that reports deposits on hand in various currencies, each of which is a dimension. The y axis specifies the primary item and a relationship axis for the currency dimension values. Each fact is reported in the local currency, to be shown in the first column, and in equivalent Euros, to be shown in the second column. The first column has the local unit (non-Euro) and the second the Euro-equivalent (in EUR units), these facts are otherwise aspect equal to each other.

Example0203_Level1
Example0203_Level2
Example0203_Level3

A.2.6 Financial Reports

Corresponds to US-GAAP or IFRS filings.

The y-axis (rows) are:

A.2.6.1 Table example 0301

  1. a selection axis representing the extended link role (schedule) for the balance sheet, and
  2. a concept relationship axis representing concept hierarchy according to a linkbase (presentation used for 2010 examples), within the schedules (extended link roles) of the presentation linkbase according to the desired schedule display.

The schedule in these examples is assumed to be inferred from the type of filing, representing fact-related DTS information (because the fact specifying form type provides this association), and the hierarchy of members in the rows represents non-fact information (from the DTS). Concept names in the balance sheet must be shown for ancestors of a reported fact regardless of whether the concepts between the root and the reported descendant have values.

Example0301A_Level1
Example0301A_Level2
Example0301A_Level3
Example0301B_Level1
Example0301B_Level2
Example0301B_Level3

A.2.6.2 Table example 0302

A balance sheet. Columns represent periods. Rows represent presentation linkbase hierarchy of concepts in the extended link role for balance sheet. In this example the extended link role is known in advance.

Example0302_Level1
Example0302_Level2
Example0302_Level3

A.2.6.3 Table example 0303

A Risk-Return instance (partial) showing multiple relationship axes rendered.

Example0303_Level1
Example0303_Level2
Example0303_Level3

The y-axis provides the presentation linkbase. In the sample RR instances provided, standard link roles were used, so dynamic discovery (the case of US-GAAP filings) is not required.

The x-axis provides two dimensions in two axes (Cartesian products of member possibilities, with non-occupied combinations elided, because only some make sense.)

A.2.7 Unused contexts Reports

A report on unused contexts in instance document (This is not fact reporting in the traditional sense, however it is required by US-GAAP, IFRS, and SBR-NL)

A.3 Global Ledger Reports

Requires an open axis for the rows to identify participating tuples from the GL instance that have the required contents, based on their location. Uses selectionAxis to identify these tuples.

A.3.1 Table example 0401

A Global Ledger report of a trial balance (showing ending balance of XII website sample file BP_trial_balance.xml).

Example0401_Level1
Example0401_Level2
Example0401_Level3

A.3.2 Table example 0402

A Global Ledger report of assets (showing book and tax depreciations of XII website sample file BP_FixedAssetList.xml).

Example0402_Level1
Example0402_Level2
Example0402_Level3

Appendix B References

DIMENSIONS
XBRL International Inc.. "XBRL Dimensions 1.0"
Ignacio Hernández-Ros
, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm)
FORMULA
XBRL International Inc.. "XBRL Formula Overview 1.0"
Herm Fischer.

(See http://xbrl.org/WGN/XBRL-formula-overview/PWD-2011-12-21/XBRL-formula-overview-WGN-PWD-2011-12-21.html)
GLOBALLEDGER
XBRL International Inc.. "XBRL Global Ledger Framework"
Gianluca Garbellotto.

(See http://xbrl.org/int/gl/2007-04-17/GLFramework-REC-2007-04-17.htm)
MDLBUSINFOXBRL
Charles Hoffman, CPA. "Modelling Business Information Using XBRL"
Charles Hoffman, CPA.

(See http://xbrl.squarespace.com/storage/ModelingBusinessInformationUsingXBRL-2011-08-05.pdf)
MDLBUSINFOXBRLDIAG
Charles Hoffman, CPA. "Modelling Business Information Using XBRL, accompanying detailed diagram"
Charles Hoffman, CPA.

(See http://www.xbrlsite.com/US-GAAP-2011/LogicalModel/SEC-LogicalModel-2011-06-04.pdf)
OMGCWM
Object Management Group, Inc.. "Common Warehouse Metamodel 1.1"
(See http://www.omg.org/spec/CWM/1.1/PDF/)
TABLELINKBASE
XBRL International Inc.. "Table Linkbase Overview 1.0"
Herm Fischer
, and Victor Morilla.
(See http://xbrl.org/WGN/table-linkbase-overview/PWD-2011-12-21/table-linkbase-overview-WGN-PWD-2011-12-21.html)
VERSIONING
XBRL International Inc.. "Overview of Versioning 1.0"
Herm Fischer.

(See http://xbrl.org/WGN/versioning-overview/PWD-2011-10-19/versioning-overview-WGN-PWD-2011-10-19.html)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2008-07-02"
Phillip Engel
, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm)
XBRLSECFILINGRATIOS
KU EYCARAT 2011 XBRL Conference. "Feeding the Information Value Chain: Deriving Analytical Ratios from XBRL filings to the SEC"
Roger Debreceny
, d'Eri Alessandro, Carsten Felden, Stephanie Farewell, and Maciej Piechocki.
(See http://web.ku.edu/~eycarat/myssi/_pdf/2-Debreceny-XBRL%20Ratios%2020101213.pdf)

Appendix 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).

Appendix D Acknowledgements (non-normative)

This document could not have been written without the contributions of many people.

Appendix E Document history (non-normative)

DateAuthorDetails
15 May 2011Raymond Lam

Initial document.

12 July 2011Hugh Wallis

Updates for (internal) publication as IWD.

10 October 2011Raymond Lam

Updates for publication as PWD

19 October 2011Hugh Wallis

Editorial for grammar, typos, UK/US spelling reconciliation and clarification of ambiguous wording.

15 March 2012Herm Fischer

Revision for initial 2.0 version.

20 May 2012Herm Fischer

Edited documents. Updated reference of coordinate, to ordinate when it pertains to a single axis.

Appendix F Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Abstract Modelling Task Force up to and including 06 June 2012. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.