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 a 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.
- 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.
1.2 Scope
The Abstract Modelling Task Force recognises that there have been significant advancements made in a variety of other modules related to the core XBRL 2.1 and Dimensions 1.0 specifications. In particular, specifications such as Formulae, Rendering and Versioning have all added substantial features and capabilities on top of the two existing core specifications. However, the scope of the modelling effort was defined at the outset to be inclusive of only the XBRL 2.1 and Dimensions 1.0 specifications.
The Abstract Modelling Task Force has been respectful of this scope boundary, and has thus been careful to ensure that all constructs in the abstract model are traceable back to either the XBRL 2.1 or Dimensions 1.0 specifications.
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.
Correspondingly, XBRL at the meta-model level would be defined in terms of concepts, facts, relationships, etc. The meta-model presented in this document describes XBRL in terms of the constructs that define it as a modelling framework.
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 Primary and secondary model
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 Model - captures the pure semantics of XBRL and thus, as much as possible, is independent of the XML syntax
- the Secondary Model - captures the artefacts introduced by the XML syntax and is thus a more direct representation of the current specifications
The model presented in this document is the Primary Model, and is thus focused more on the semantics of XBRL than on the syntax. For this reason, the reader should be aware that certain 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
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].
2 Packaging
The abstract model has been broken down into 3 packages, each of which builds upon the next:
- Fact Model - this package captures how XBRL facts can appear when they are instantiated. There is a sub package named Fact Types which further describes the hierarchy of fact types that are available. The Fact Model relies on the Concept Model to provide additional meta-information on Facts.
- Concept Model - this package captures how Concepts are defined along with the inter-Concept relationships, resources and axes. The Concept Model relies on the Typing Model to provide type information on the Concepts.
- Typing Model - this package captures the underlying types that have been defined by XBRL 2.1.
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.
3 Extensible Element
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.
3.1 Class ExtensibleElement
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.
3.2 Class UserDefinedProperty
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.
4 Fact Model
The Fact Model captures how XBRL data manifests itself when reported as business information.
The Fact is the core class of this model and has a direct association with a Concept, which provides additional meta-data about the Fact.
There are two types of Facts: a StructuringFact (i.e. an XBRL tuple) and an ItemFact. Subclasses of ItemFacts report actual values and these values can be further characterised through FactProperties. There are a minimum of two FactProperties - Entity and Period - and several other optional FactProperties including TypedAxisValue and ExplicitAxisValue.
4.1 Class Entity
Semantics
The Entity metaclass defines the entity (business, government department, individual, etc.) that an ItemFact describes.
Rationale
The Entity metaclass is a direct parallel to the entity element in the XBRL Instance Schema.
Properties
The Entity metaclass has two properties: identifier and scheme.
Hyperlink
4.2 Class ExplicitAxisValue
Semantics
The ExplicitAxisValue metaclass defines the instantiation of an explicit dimensional member, which further describes an ItemFact.
Rationale
The Dimensions 1.0 specification enables ItemFacts to be further described by specific values defined along zero-to-many dimensions or Axes. The ExplicitAxisValue metaclass is provided to capture explicit domain members, which may be associated with instances of an ItemFact.
Properties
The ExplicitAxisValue has a single property which is an explicit member along an ExplicitAxis.
4.3 Class Fact
Semantics
The Fact metaclass serves as the abstract base class for both ItemFacts and StructuredFacts. Facts are described by a corresponding Concept metaclass and are a specific instantiation of a Concept.
Rationale
The XBRL specification distinguishes between instance-based data and taxonomy-based data. Taxonomy-based data is defined through Concepts and instance-based data is defined through Facts. Facts and Concepts are tightly bound to one another, where a given Fact is a specific instantiation of a given Concept.
Properties
Facts are defined by a single Concept property named 'sourceConcept'. Facts can optionally have footnotes associated with them. Facts can be contained within zero or more FactCollections.
4.4 Class FactCollection
Semantics
The FactCollection metaclass represents a container that holds a flat list of Facts.
Rationale
The FactCollection provides a starting point for the set of Facts which are communicated, for example in an XBRL instance document. This metaclass is closely related to the xbrl element in the XBRL Instance Schema. A link to the definition of the XBRL element has been provided.
Properties
The Fact Collection can contain zero or many Facts.
Hyperlink
4.5 Class FactProperty
Semantics
FactProperty is an abstract base class for metaclasses that can define additional data characteristics about an ItemFact.
Rationale
For each ItemFact, XBRL stipulates that a minimum of 2 FactProperties be defined: an Entity and a Period. Additional FactProperties can be associated with an ItemFact including an optional Scenario, zero-to-many ExplicitAxisValues and zero-to-many TypedAxisValues.
4.6 Class FactStructuringRelationship
Semantics
The FactStructuringRelationship metaclass provides the means for a StructuredFact to express its parenting relationship(s) to other Facts.
Rationale
The XBRL specification provides a means for reporting a set of facts kept together through the tuple definition. The StructuredFact and FactStructuringRelationship metaclasses are intended to reflect this ability. The StructuredFact represents the instantiation of a tuple fact, whereas the FactStructuringRelationship represents the manner in which the StructuredFact is then related to other instantiations of Fact.
Properties
A FactStructuringRelationship is associated with one StructuredFact and with one-to-many Fact-derived classes. The property 'numberOfOccurrences' defines how many times a given Fact appears as a child of the StructuredFact.
4.7 Class Footnote
Semantics
Footnotes provide a means of associating additional commentary to a Fact.
Rationale
The XBRL specification defines Footnotes as a means of annotating Facts that occur in a FactCollection.
Properties
Footnotes have a single content property, which can be of any arbitrary type.
Hyperlink
4.8 Class ItemFact
Semantics
The ItemFact metaclass serves as the base class for Fact-derived classes that contain a value. Most of the Properties that are associated with item facts are provided at this level.
Rationale
The XBRL specification defines an item as a 'single fact or business measurement'. The hierarchy of classes that derive from ItemFact eventually leads to classes where a value of some type will be provided.
Properties
An ItemFact has a single Period, a single Entity, and an optional Scenario associated with it. An ItemFact can also have zero-to-many ExplitAxisValues / TypedAxisValues associated with it.
4.9 Class Period
Semantics
The Period metaclass defines the relevant time characteristics for an ItemFact. It can be a point in time, a duration, or 'forever'.
Rationale
Uses the natural concepts of stock (point) and flow (period).
Properties
Start date, end date.
4.10 Class Scenario
Semantics
The Scenario metaclass provides additional information about the status of an ItemFact.
Rationale
ItemFacts can exist in several possible worlds: budgeted, actual, etc. The Scenario metaclass provides metadata about which possible world is relevant for the ItemFact.
Properties
The Scenario metaclass has a single content property, which can be of any arbitrary type.
4.11 Class Segment
Semantics
The Segment metaclass defines the specific business unit of an Entity.
Rationale
The XBRL specification provides the segment element as a means of further identifying the business segment more completely, in cases where the entity identifier is insufficient or too broad.
Properties
The Segment metaclass has a single content property, which can be of any arbitrary type.
4.12 Class StructuredFact
Semantics
The StructuredFact metaclass represents facts which are parents of other Facts.
Rationale
The XBRL specification provides a means for reporting a set of facts kept together through the tuple definition. The StructuredFact and FactStructuringRelationship metaclasses reflect this ability. The StructuredFact represents the instantiation of a tuple fact, whereas the FactStructuringRelationship represents the manner in which the StructuredFact is then related to other instantiations of Fact.
Properties
The StructuredFact can be associated with zero-to-many FactStructuringRelationships.
4.13 Class TypedAxisValue
Semantics
The TypedAxisValue metaclass defines the instantiation of a typed dimensional member that further describes an ItemFact.
Rationale
The Dimensions 1.0 specification enables ItemFacts to be further described by specific values defined along zero-to-many dimensions or Axes. The TypedAxisValue metaclass is provided to capture a typed domain member that may be associated with instances of an ItemFact.
Properties
The TypedAxisValue has a single typedValue property. That property is a value that satisfies the type specification of a TypedAxis.
5 Fact Typing
The Fact Typing subpackage captures the library of fact types that are available as derived classes from ItemFact, and which of these add semantic significance to the meta-model. Only those that do add semantic significance have been explicitly documented below. NumericFacts have a unit property and NonFractionalNumericFacts have either a precision or decimals property.
5.1 Class AbstractDecimalFact
Semantics
The AbstractDecimalFact allows for any decimal value to be reported.
Properties
It will have the value as a decimal and will inherit the fact properties from the ItemFact abstract class which will provide contextualisation. This will optionally allow for a decimal or precision attribute to be set against the value. It will also have a Unit value required, which will specify the measure applied to the value.
5.2 Class DateOrDateTimeFact
Semantics
This is a metaclass which allows for a date or a dateTime to be stored for the value.
Rationale
This class is an Item data type defined by the XBRL standard v2.1 under section 5.1.1.3 and will hold a dateTimeItemType value. It has either a date or dateTime property.
Properties
The DateOrDateTimeFact metaclass has either a date property or a dateTime property, but not both.
Hyperlink
5.3 Class FractionalNumericFact
Semantics
The FractionalNumericFact metaclass allows for a value to be specified in terms of a numerator and a denominator.
Rationale
This class is an Item data type defined by the XBRL standard v2.1 under section 5.1.1.3 and will hold a fractionItemType value.
Properties
The FractionalNumericFact has a numerator property and a denominator property. It also inherits the Unit property, which will specify the measure applied to the value.
5.4 Class MonetaryFact
Semantics
The monetaryItemType allows for any decimal value to be reported. The Unit of the metaclass is restricted to the ISO4217 currency list. The currency reported must also be valid at the time of reporting.
Rationale
This class is an Item data type defined by the XBRL standard v2.1 under section 5.1.1.3 and will hold a monetaryItemType value.
Properties
It will have the monetary value as a real number (decimal) and will inherit the fact properties from the ItemFact abstract class, which will provide contextualization. This will optionally allow for a decimal or precision attribute to be set against the value. It will also have a Unit value required, which will specify the measure applied to the value.
Hyperlink
5.5 Class NonFractionalNumericFact
Semantics
The NonFractionalNumericFact is an abstract metaclass that allows for the separation between the fraction class and non fractional classes.
Rationale
This class allows for either Decimals or Precision properties to be set again the nonfractional numeric value.
Properties
Unit will be required. Either Decimals or Precision can be applied to communicate accuracy.
5.6 Class NonNumericFact
Semantics
The NonNumericFact metaclass is an abstract base class that serves as the common root for facts which have non-numeric values.
The NonNumeric class is a abstract class that is used to separate Numeric and nonnumeric classes.
Rationale
The XBRL specification makes a distinction between numeric and non-numeric items.
NonNumeric has no additional characteristic.
Properties
None.
5.7 Class NumericFact
Semantics
The NumericFact metaclass is an abstract base class that serves as the common root for facts which specifically have a numeric value.
Numeric Fact is an abstract class that is used to separate the numeric and NonNumeric classes
Rationale
The XBRL specification makes a distinction between numeric and non-numeric items. Numeric items are distinguished from non-numeric items by the presence of a unit property.
Properties
NumericFacts have a unit property of type Unit.
The unit property has been modelled in this manner:
5.8 Class PureNumericFact
Semantics
The pureItemType allows for any decimal value to be reported.
Rationale
This class is an Item data type defined by the XBRL standard v2.1 under section 5.1.1.3 and will hold a pureItemType value.
Properties
It will have the value as a real number (decimal) and will inherit the fact properties from the ItemFact abstract class, which will provide contextualization. This will optionally allow for a decimal or precision attribute to be set against the value. It will also have a Unit value required, which will specify the measure applied to the value.
Hyperlink
5.9 Class SharesNumericFact
Semantics
The timeItemType allows for either a Time value to be reported. The value of the Unit must be “Shares”
Rationale
This class is an Item data type defined by the XBRL standard v2.1 under section 5.1.1.3 and will hold a timeItemType value.
Properties
It will inherit the fact properties from the ItemFact abstract class, which will provide contextualization. This will optionally allow for a decimal or precision attribute to be set against the value. It will also have a Unit value required, which will specify the measure applied to the value.
Hyperlink
6 Concept Model
The Concept Model captures how elements can be defined for business reporting purposes.
The Concept is the core class of this model. There are two types of Concept: StructuredConcept (i.e. an XBRL tuple) and ItemConcept. The Relationship metaclass defines inter-Concept semantics such as Calculation and Presentation relationships.
FilterableElement and Toggle are abstractions of the prohibition and override capabilities that XBRL provides through relationship networks and base sets, and which are commonly leveraged through taxonomy extensions.
The ItemConcept to Axis association captures how the Dimensions 1.0 specification provides the ability to define Axes (e.g. dimensions) to further characterise how instances of a Concept might be realised.
6.1 Axis
Semantics
The Axis metaclass represents a dimension.
Rationale
The Dimensions specification provides the ability to define dimensions, which can be either typed or explicit. The Axis metaclass serves as the common abstract base class between the two.
Properties
The Axis metaclass has a name property which is of type QName.
Hyperlink
http://www.xbrl.org/Specification/XDT-REC-2006-09-18+Corrected-Errata-2009-09-07.htm#_Toc243301762
6.2 Class Calculation
Semantics
The Calculation metaclass is used to model aggregation of values from children to parents.
Rationale
Calculation is a specific type of parent/child relationship where the aggregation functionality is computable.
Properties
Weight as a weighting factor in the aggregation formula.
Hyperlink
6.3 Class Concept
Semantics
The Concept metaclass defines the business reporting elements that can occur in XBRL fact models.
Rationale
The XBRL specification defines two types of concepts: items and tuples. The Concept metaclass is the common abstract base class between the two of them.
Properties
The ItemConcept metaclass has a single name property.
6.4 Class ConceptContainer
Semantics
The ConceptContainer metaclass represents a container that holds a flat list of Concepts. ConceptContainers have the ability to export themselves and to import other ConceptContainers.
Rationale
The ConceptContainer provides a starting point for the set of Concepts and their Relationships that are typically communicated in XBRL taxonomies.
Properties
The ConceptContainer can contain zero or many Concepts.
6.5 Class Definition
Semantics
The Definition metaclass captures a variety of miscellaneous relationships between Concepts.
Rationale
The XBRL specification defines three specific types of relationships between concepts: presentation, calculation and definition.
Properties
None.
Hyperlink
6.6 Class ExplicitAxis
Semantics
The ExplicitAxis represents dimensions whose members are explicitly defined.
Rationale
The Dimensions specification makes a distinction between typed and explicit dimensions. The TypedAxis represents explicit dimensions.
Properties
The ExplicitAxis has zero-to-many members, which are the specific values permissible for the ExplicitAxis.
Hyperlink
http://www.xbrl.org/Specification/XDT-REC-2006-09-18+Corrected-Errata-2009-09-07.htm#_Toc243301765
6.7 Class FilterableElement
Semantics
The FilterableElement metaclass is an abstract base class from which derived classes inherit the ability to be toggled on or off.
Rationale
The XBRL specification defines a mechanism for prohibiting and overriding relationships. The FilterableElement defines a hierarchy of classes that participate in this mechanism.
Properties
The FilterableElement has an isEffective property, which is a derived property that determines whether a derived class has been toggled on or off. The role property is used to partition derived classes into networks of relationships and resources.
6.8 Class FilterableRelationship
Semantics
The FilterableRelationship is an abstract base class which derives from Relationship and FilterableElement. The combination of these two parent classes results in relationships which can be toggled on or off.
Rationale
The XBRL specification defines a mechanism for prohibiting and overriding relationships. The FilterableRelationship metaclass reflects this capability in XBRL.
Properties
None.
6.9 Class ItemConcept
Semantics
The ItemConcept metaclass defines specific elements that can be realized as facts in business reporting.
Rationale
The XBRL specification defines an item as a single fact or business measurement. ItemConcepts serve as the heart of the Concept Model.
Properties
ItemConcepts must be associated with a single ItemType. ItemConcepts can be on either the source or target end of Relationships. ItemConcepts can have zero or more Axes.
6.10 Class ItemRelationship
Semantics
The ItemRelationship metaclass is a specialisation of the Relationship metaclass and captures relationships specifically between ItemConcepts.
Rationale
The XBRL specification defines certain types of relationships that can exist only between ItemConcepts in particular, thereby excluding StructuredConcepts as possible sources or targets from the relationship.
Properties
None.
Hyperlink
6.11 Class Label
Semantics
The Label metaclass represents a human-readable name for Concepts.
Rationale
The XBRL specification defines labels as resources that can be defined to provide human-readable names and documentation for concepts.
Properties
The Label metaclass has a content property and a language property.
6.12 Class Member
Semantics
The Member metaclass defines a specific value along an ExplicitAxis.
Rationale
The Dimensions specification defines that an explicit dimension specifically names its members. The Member metaclass is used to represent those members.
Properties
The Member metaclass has a name property.
Hyperlink
http://www.xbrl.org/Specification/XDT-REC-2006-09-18+Corrected-Errata-2009-09-07.htm#_Toc243301742
6.13 Class ParentChildItemRelationship
Semantics
The ParentChildItemRelationship metaclass is a specialisation of the ItemRelationship metaclass where the source and target are effectively in a parent-child relationship.
Rationale
The XBRL specification defines relationships that can be interpreted as parent-child types of relationships.
Properties
None.
6.14 Class Presentation
Semantics
The Presentation metaclass captures presentational relationships between Concepts.
Rationale
The XBRL specification defines three specific types of relationships between concepts: presentation, calculation and definition.
Properties
The PresentationLink has a preferredLabel property.
Hyperlink
6.15 Class PrimaryItemRelationship
Semantics
The PrimaryItemRelationship metaclass captures parent-child relationships where the parent plays the role of a primary item and the child plays the role of a descendant of that primary item.
Rationale
The Dimensions specification provides for inheritance of ItemConcept-to-Axis associations. The PrimaryItemRelationship metaclass captures this capability as defined by the Dimensions specification.
Properties
6.16 Class Reference
Semantics
The Reference metaclass represents pointers to the authoritative statements for Concepts.
Rationale
The XBRL specification defines references as resources that can be defined to point at authoritative material for concepts.
Properties
The Reference metaclass has zero-to-many ReferenceParts.
6.17 Class ReferencePart
Semantics
The ReferencePart metaclass represents the discrete parts that make up a Reference.
Rationale
The XBRL specification defines that references are composed of parts. The ReferencePart metaclass mirrors that capability.
Properties
The ReferencePart has a content property that can be of any type.
6.18 Class Relationship
Semantics
The Relationship metaclass is an abstract base class that defines a relationship between a single source Concept and a single target Concept.
Rationale
The XBRL specification defines specific kinds of relationships that can exist between concepts, or between a concept and a resource (such as a label or a reference). The Relationship metaclass serves as the common abstract base class for these specific kinds of relationships.
Properties
The Relationship metaclass has a source property and a target property.
6.19 Class StructuredConcept
Semantics
The StructuredConcept metaclass represents Concepts that are parents of other Concepts.
Rationale
The XBRL specification provides a means for defining structured groupings of concepts through the tuple definition. The StructuredConcept and StructuringRelationship metaclasses reflect this ability in XBRL.
Properties
None.
6.20 Class StructuringRelationship
Semantics
The StructuringRelationship metaclass is a type of Relationship that can be used to define structured groupings of Concepts.
Rationale
The XBRL specification provides a means for defining structured groupings of concepts through the tuple definition. The StructuredConcept and StructuringRelationship metaclasses reflect this ability in XBRL. The StructuringRelationship has a source property that is a StructuredConcept and a target property that is a Concept (and hence can be an ItemConcept or another StructuredConcept ).
Properties
The StructuringRelationship has a minOccurrences property, a maxOccurrences property, and a structuringKind property. These Properties are a reflection of the constraints commonly used in defining tuple content models.
6.21 Class Toggle
Semantics
The Toggle metaclass is applied to FilterableElements to toggle them on or off.
Rationale
The XBRL specification defines a mechanism for prohibiting and overriding elements. The FilterableElement and Toggle metaclasses reflect this capability in XBRL.
Properties
The Toggle metaclass has a priority property, which is used to resolve Toggle precedence in cases where there are multiple Toggles applied to a FilterableElement. The ToggleKind determines whether the Toggle action is to turn a FilterableElement on or off.
6.22 Class TypedAxis
Semantics
The TypedAxis metaclass represents dimensions whose members are based on an external type definition.
Rationale
The Dimensions specification makes a distinction between typed and explicit dimensions. The TypedAxis represents typed dimensions.
Properties
The TypedAxis has a type property, which is a URI that references an external type definition.
7 Typing Model
The Typing Model captures how XBRL provides a library of types from which taxonomy designers can derive their own custom types. The inventory of XBRL types has a large intersection with the built-in datatypes provided by XML Schema, but it's not an identical set - there are some types from XML Schema which XBRL does not use, and conversely there are several types which XBRL has added to the original XML Schema set.
The ItemType metaclass plays the central role in the Typing Model. The ItemType metaclass is directly associated with the ItemConcept metaclass from the Concept Model, and through that association provides the typing information to the Concept Model.
While there are some similarities in the class structures between the Typing Model and the Fact Types, there are important semantic differences that can be seen through the model. One significant difference is that the Typing Model does not have any provision for actual values, whereas many of the Fact Types provides that specific ability through a value property.
8 Feedback requested
The Abstract Modelling Task Force is seeking your input and opinions on these specific topics:
- Abstraction Level - A side effect of the abstraction process is that some of the detail and granularity defined at the raw specification level has been dissolved away into higher level abstractions. For instance, readers who are familiar with XBRL will notice that some well-known XBRL artefacts such as contexts, locators, and arcs are not present in the model. Others, like tuples, have been modelled in a manner that is more consistent with a model that intends to capture XBRL at the semantic level. The reader is invited to provide comments on the level of abstraction found in the model, and whether they feel that specific abstractions should be made more or less abstract.
- Fact-Concept Association - The Fact Model currently expresses the relationship between the Fact and Concept metaclasses as a direct association. The reader is invited to provide their opinion on whether this association should be modelled differently, quite possibly as a separate class that derives from FactProperty.
- Concept and Axes - The Concept Model currently expresses that Concepts can have a number of Axes associated with it. The Abstract Modelling Task Force recognises that this may be insufficient to capture the kind of sophisticated hypercube models which the Dimensions 1.0 specification currently allows. The reader is invited to comment on this portion of the Concept Model and to provide opinions on how they would like to see the Axis modelling enhanced.
- Tuple Abstractions - Tuples in XBRL have the ability to leverage XML Schema to define complex content models. In lieu of replicating an entire metamodel that represents XML Schema, the Concept Model has instead abstracted XBRL Tuples in terms of the StructuredConcept and StructuringRelationship metaclasses. The Abstract Modelling Task Force recognises that this may not have equivalent utility with XML Schema, so the reader is invited to comment on what capabilities of tuple content modelling they feel would be necessary to round out the existing capabilities of the Concept Model.
- Precision and Decimals - The reader is invited to comment on the use of precision and decimals in defining the degree of numerical accuracy as reported by non-fractional numeric facts. Are both required at the semantic level, or is it more preferable to reduce the two of them into a single abstraction? (For instance, see this document from the W3C on the precisionDecimal type.)
Feedback can sent to modelling-feedback@xbrl.org.