Copyright © 2011, 2012 XBRL International Inc., All Rights Reserved.
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 email@example.com, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
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].
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.
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
184.108.40.206 Class EnumerableAspect
220.127.116.11 Class NonEnumerableAspect
18.104.22.168 Class AspectValueSet
22.214.171.124 Class AspectValueRelationship
126.96.36.199 Class Relationship
188.8.131.52 Class RelationshipType
184.108.40.206 Class RelatableElement
3.3 Instances Model
3.3.1 Class DataPoint
3.4 Valid Combinations Model
3.5 Table Model
3.5.3 Table Cells
3.6 Document Model
3.7 DTS Model
3.8 Typing Model
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
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
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)
F Errata corrections in this document
The meta-model will serve as a valuable technical resource that communicates the fundamental semantic value of these specifications.
The charter for the Abstract Modelling Task Force was defined by the XBRL Standards Board in these terms:
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].
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:
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.
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.
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 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.
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].
The abstract model has been broken down into these packages, each of which builds upon the next:
The primary model is a meta-class layer independent of concrete realization considerations, such as XML syntax, type, and particle models, XBRL 2.1 relationship sets, instance, schema and linkbases, OLAP implementation schemes in databases, and ontology implementation schemes.
The XBRL 2.1 secondary model provides a mapping for the primary model to the concrete realization technology provided by XBRL 2.1 syntax elements of instance documents, taxonomy schemas, linkbases, and extension modules.
The Global Ledger secondary model provides a mapping for the primary model to the concrete realization technology provided by Global Ledger palette taxonomies and their instances.
The MOLAP secondary model provides a mapping for the primary model to the concrete realization technology XBRL meta model realizations using database technology implemented by MOLAP technology.
The financial report secondary model provides a mapping for the primary model to the concrete realization of a financial report filing such as to the U.S. SEC.
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.
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)
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).
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.
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).
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).
Aspects are identifying or classifying properties of data points, such as dimensions, names, date and unit of measurement.
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.
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.
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.
The value, which may be scalar (atomic), or structured.
A human-readable name.
An optional reference to a semantic vocabulary entry.
The RelationshipType metaclass defines a classification of relationships.
Relationships must be identifiable and validatable.
A human-readable name.
The relationships of a RelationshipType may be limited to directed relationships.
The relationships of a RelationshipType may be restrict cycles.
The RelationshipSet metaclass defines a collection of relationships.
Relationships collections are manipulable for presentation, validation and classification purposes.
A human-readable name.
The Relationship metaclass defines a logical relationship between pairs of Aspects, AspectValues, DataPoints, Resources, and between Aspect and AspectValue, Aspect or DataPoint and Resource.
Relationships are used to model reported data, metadata, and supporting features (such as labeling and computation).
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).
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.
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).
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.
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).
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).
Aspects which are identifying in nature may have scalar values that are enumerable.
An EnumerableAspect has a Name and a Type specifying its values.
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).
Aspect which are identifying can be treated as data, such as addresses or number sets.
A non-enumerable aspect may have a Typed value, which may have structure.
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).
Aspect Value Sets may represent hierarchical pre-specified values for an Aspect.
An AspectValueSet has AspectValues, possibly organized into a hierarchy (by AspectValueRelationships), and possibly defined by internal or external semantics definitions.
The AspectValueRelationship metaclass defines a graph of values of an AspectValueSet, providing any hierarchy and organizational ontology.
Aspect Value Sets may be hierarchical (or other style of) graph.
Set organization and membership.
The Data Dictionary models Relationships that relate aspects, aspect values, resources, and datapoints.
The Relationship metaclass defines a graph of values of a RelatableElement, providing any hierarchy and organization.
RelatableElements may be organized in Relationship sets.
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.
The RelationshipType metaclass defines a relationship type.
Relationships are classified by type.
The isDirected specifies whether the relationships form a directed cycle.
The allowsCycles specifies whether the graph may contain cycles.
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).
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).
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.
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).
DataPoint instances of reportable business information are Facts.
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
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). ]
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).
Reportable aspects (base items) are associated with reportable sets of AspectValueSets (cube regions).
A Cube is expressed by CubeRegions and AspectsToReport.
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).
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.
A CubeRegion is expressed by AspectValueSelectionGroups.
The AspectValueSelectionGroup metaclass defines a set of cartesian products of enumerable AspectValues.
An AspectValueSelectionGroup is a set of allowed DataPoint AspectValues of facts that may exist in a CubeRegion.
An AspectValueSelectionGroup has a set of AspectValueSelections.
The AspectValueSelection metaclass defines a set of enumerable AspectValues that identify or describe a single DataPoint (Fact instance) to be allowed in an AspectValueSelectionGroup.
An AspectValueSelectionGroup is a set of allowed DataPoint AspectValues for a Fact.
An AspectValueSelectionGroup has a set of Aspects and their AspectValue(s).
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.]
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.
Tabular presentation of business reports information items, in matrix layouts, is generally required.
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).
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.
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).
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).
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.
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.
The Manifest metaclass defines what is packaged in the Documennt.
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.
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.
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.]
Captures the underlying types that have been defined by both XBRL 2.1, for use in data points fact values and aspect values.
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).
A fact may have FactValue (of its AtomicAspect) and an AspectValue of each of its DataPoint Aspects, each according to its DataType.
DataType describes the atomic value constraints.
The StructuredAspect metaclass defines an composition structure for a FactValue or AspectValue.
DataTypes may be composed of structures, such as lists and hierarchies of specified atomic content.
StructuredAspect describes the compositional constraints of a DataType.
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.]
[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)]
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
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).
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.
This secondary model represents how XBRL declares tables, their axes, filters, and coordinates.
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.
This secondary model represents how XBRL declares its assertion sets and variable sets (representing the managed result-producing constructs of XBRL formula).
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.
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.]
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.]
This diagram relates the primary model elements to the Financial Report Logical Model.
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.
The Abstract Modelling Task Force is seeking your input and opinions on these specific topics:
Feedback can sent to firstname.lastname@example.org.
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.
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.
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.
ExtensibleElement is defined through related instances of UserDefinedProperty.
The UserDefinedProperty enables users to add their own custom Properties to the set of Properties already occurring on an instance of the ExtensibleElement metaclass.
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.
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.
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.
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.
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
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
Corresponds to XBRL examples of Eurofiling forms, usually represented by spreadsheet workbooks with multiple worksheet tables, each in a fixed format.
Simple table, two rows represent primary items, two columns represent members of one dimension
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
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
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.
Demonstrates coordinate inheritance and override, second column overrides dimension D inherited from first column coordinate member
Introduces two separate z-axes (so that the Cartesian cross-product of their members represent the coordinates on the z-axis).
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.
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.
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.
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).
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.
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.
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.
Corresponds to US-GAAP or IFRS filings.
The y-axis (rows) are:
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.
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.
A Risk-Return instance (partial) showing multiple relationship axes rendered.
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.)
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 Global Ledger report of a trial balance (showing ending balance of XII website sample file BP_trial_balance.xml).
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).
This document could not have been written without the contributions of many people.
|15 May 2011||Raymond Lam||
|12 July 2011||Hugh Wallis||
Updates for (internal) publication as IWD.
|10 October 2011||Raymond Lam||
Updates for publication as PWD
|19 October 2011||Hugh Wallis||
Editorial for grammar, typos, UK/US spelling reconciliation and clarification of ambiguous wording.
|15 March 2012||Herm Fischer||
Revision for initial 2.0 version.
|20 May 2012||Herm Fischer||
Edited documents. Updated reference of coordinate, to ordinate when it pertains to a single axis.
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.