Versioning Dimensions 1.0

Recommendation 27 February 2013

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

This version:
<http://www.xbrl.org/Specification/versioning-dimensions/REC-2013-02-27/versioning-dimensions-REC-2013-02-27.html>
Editors:
Richard Ashby, CoreFiling <rna@corefiling.com>
Herm Fischer, Mark V Systems <fischer@markv.com>
Contributors:
Eric Jarry, Bank of France <eric@jarrymail.com>
Maciej Piechocki, IFRS Foundation <mpiechocki@ifrs.org>
Roland Hommes, Rhocon <roland@rhocon.nl>
Haiko Philipp, IFRS Foundation <hphilipp@ifrs.org>
Paul Warren, CoreFiling <pdw@corefiling.com>
Suguru Washio, Fujitsu Ltd. <wasio@jp.fujitsu.com>
Hugh Wallis, Standard Dimensions <hugh@standarddimensions.com>
Stuart Barker, CoreFiling <dsb@corefiling.com>

Status

Circulation of this Recommendation is unrestricted. This document is normative. Recipients are invited to submit comments to versioning-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This specification is a modular extension to the Versioning Base Specification [XVS-Base]. It specifies how to map and address changes to the aspects of fact items for a set of concepts using dimensional aspects, to document that changes have occurred between different DTSs which may indicate a change in the primary items and dimensions and domain-members which may distinguish fact items.

Table of Contents

1 Introduction
1.1 Relationship to other work
1.2 Language independence
1.3 Document conventions
1.3.1 Typographic conventions
1.3.1.1 Definition notation
1.3.1.2 Footnote notation
1.3.1.3 Element and attribute notation
1.3.2 Formatting conventions
1.4 Terminology
1.5 Namespaces and namespace prefixes
2 Events and Mappings
2.1 DTS Validation
2.2 Aspect Identifiers
2.3 Aspect Model Events
2.3.1 Event usage
2.3.2 Fact identification mappings
3 Syntax
3.1 Aspects
3.1.1 Concept Aspect
3.1.2 Explicit Dimension Aspect
3.1.2.1 Explicit Dimension Members
3.1.3 Typed Dimension Aspect
3.2 Aspect model
3.3 Related Concepts

Appendices

A Schema
B References
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)
F Errata corrections in this document

Tables

1 Namespaces and namespace prefixes
2 Aspect identifiers of change events
3 Aspect model events

Examples

1 Concept aspect
2 Explicit Dimension aspect
3 Typed Dimension aspect
4 Typed Dimension Aspect Change
5 Aspect Model

Definitions

aspect
aspect-equivalent facts
aspect-identifier
aspect-model
explicit-dimension-identifier
fact-identification mappings
member-identifier
typed-dimension-identifier

Error codes

verdime:duplicateExplicitDimensionAspect
verdime:duplicateTypedDimensionAspect
verdime:invalidArcElement
verdime:invalidExplicitDimensionIdentifier
verdime:invalidLinkElement
verdime:invalidTypedDimensionIdentifier
verdime:invalidURI


1 Introduction

1.1 Relationship to other work

This specification depends upon the following XBRL specifications:

In the event of any conflicts between this specification and the specifications upon which it depends, this specification does not prevail.

Several aspects of the aspect model depend on relationships expressed in the DTS. Concept to concept relationships and dimension relationships are expressed respectively with base sets and dimensional relationship sets that depend on link roles. Versioning Report documentation on link role mappings is specified in the base versioning specification [XVS-Base].

The aspect model of this specification is semantic, and does not communicate information about the detail of any arc relationships that compose these models in XBRL taxonomies. Taxonomy maintainers MAY require Versioning Reports that document relationships between concepts of a dimensional or non-dimensional nature. The reporting of such changes may be covered by a future specification, but is not within the scope of this specification.

1.2 Language independence

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

1.3 Document conventions

1.3.1 Typographic conventions

1.3.1.1 Definition notation

Definitions are highlighted with green text.

1.3.1.2 Footnote notation

Comments which are informative, but not essential to the understanding of the point at hand, are provided in footnotes. All footnotes are non-normative.

1.3.1.3 Element and attribute notation

When referring to a specific element, it will be identified by its namespace prefix and local name. For example, the root element of a versioning report would be referred to as <ver:report> .

Attributes are also identified by their local name and, where appropriate, their namespace prefix. Attributes are distinguished from elements by prefixing them by an @ symbol. Thus, @id refers to the attribute with the name id.

When referring to any attribute, so long as it has a specific namespace, the local name is replaced by an asterisk ( *). Thus, the notation @xml:* specifies any attribute in the namespace http://www.w3.org/XML/1998/namespace.

1.3.2 Formatting conventions

The following highlighting is used for normative technical material in this document:

Text of the normative example.

The following highlighting is used for non-normative examples in this document:

Text of the non-normative example.

The following highlighting is used for non-normative examples of poor, discouraged or disallowed usage.

Text of the discouraged example.

1.4 Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in [IETF RFC 2119].

The key words dimension, primary item, hypercube, member and default member in this document are to be interpreted as described in the XBRL Dimensions Specification [DIMENSIONS].

The key words fact and instance in this document are to be interpreted as described in the XBRL Specification [XBRL 2.1].

An aspect is information about a fact, specified by Variables 1.0 Aspects. The aspects that are initially covered by this specification are in Table 2.

This specification includes changes in the concept, typed dimension and explicit dimension aspects. It is anticipated that changes involving other aspects, such as tuple location, entity, period, and unit may be included in futher specifications.

An aspect model, as specified by Variables 1.0 Aspect Model, is a description of how the information about a fact will be split into different aspects.

For example, a change event could be reported when an aspect which was previously described only by a concept aspect is, after the change, described by a combination of concept aspect and dimension aspect.

Aspect-equivalent facts are facts which are considered equivalent within or across instances whether based on a single DTS or two versioned DTSs. Each fact has sets of aspects and their values, according to the model of their instance. Equivalency in this specification is meant only as the mapping between two different instances from two DTSs which are the subject of a Versioning Report.

For example, an instance based on Version 1 of a DTS could contain facts with concept aspect A which are aspect equivalent to facts with concept X and Dimension D = d1 in Version 2 instances. Facts with concept aspect B in instances based on Version 1 of a DTS, are equivalent to facts with concept X and Dimension D = d2 in Version 2 instances, and so on.

A member identifier, as used in this specification, is a concept identifier for a concept in the xbrli:item substitution group that can be used in conjunction with a dimension as contextual aspects on a fact. It is subject to the validation rules for a concept identifier.

An explicit dimension identifier, as used in this specification, is a concept identifier for a concept in the xbrldt:dimensionItem substitutionGroup that does not have the @xbrldt:typedDomainRef attribute. It is subject to the validation rules for a concept identifier.

A typed dimension identifier, as used in this specification, is a concept identifier for a concept in the substitutionGroup xbrldt:dimensionItem and has the @xbrldt:typedDomainRef attribute. It is subject to the validation rules for a concept identifier.

An aspect identifier as used in this specification is the combination of one more of the specific aspect identifiers defined in this or subsequent specifications that can be used together to identify a set of aspect-equivalent facts.

1.5 Namespaces and namespace prefixes

Namespace prefixes [XML Names] will be used for elements and attributes in the form ns:name where ns is the namespace prefix and name is the local name. Throughout this specification, the mappings from namespace prefixes to actual namespaces is consistent with Table 1.

The prefix column in Table 1 is non normative. The namespace URI column is normative.

Table 1: Namespaces and namespace prefixes
Prefix Namespace URI
verdim http://xbrl.org/2013/versioning-dimensions
verdime http://xbrl.org/2013/versioning-dimensions/error
xs http://www.w3.org/2001/XMLSchema
link http://www.xbrl.org/2003/linkbase
gen http://xbrl.org/2008/generic
ver http://xbrl.org/2013/versioning-base
vere http://xbrl.org/2013/versioning-base/error

2 Events and Mappings

The representation of fact items of a set of concepts in terms of their aspect models, is similar to the way the Variables Specification [VARIABLES], used for formula processing and filtering, defines its aspect model and aspects. It allows this specification to address concepts with dimensions that are explicit or typed and are an aspect on facts.

The aspect model tracks changes of aspects and supports the mapping of instance information. The model can specify changes to concept or dimensional aspect models that specify concepts individually or in a relationship set indicated by an axis, which allows a single concept that is at the head of a hierarchy of concepts or head of a dimensional relationship set of primary item concepts to include the hierarchy succinctly.

Dimensions, primary items, hypercubes and members are specified in terms of XBRL concepts [XBRL 2.1] so, as a consequence, Versioning Report documentation on XBRL concepts with dimensions [XBRL 2.1] is documented with the Concept Use Specification [XVS-Concept-Use] and Concept Details Specification [XVS-Concept-Details].

2.1 DTS Validation

Because this specification addresses dimensional material, each DTS Identifier MUST identify a DTS that is dimensionally valid according to the rules described in the XBRL Dimensions Specification [DIMENSIONS]. Error code vere:invalidDTSIdentifier, as defined in [XVS-Base], is raised otherwise. Note that this is a tightening of the rules for DTS validation required by [XVS-Base].

2.2 Aspect Identifiers

Table 2: Aspect identifiers of change events
Name Element Identification
concept aspect <verdim:concepts> concept identifier and optional related concept specifications (as per Section 3.3)
explicitDimension aspect (one aspect per dimension) <verdim:explicitDimension> , <verdim:member> explicit dimension identifier and member identifier with optional related concept specifications (as per Section 3.3).
typedDimension aspect (one aspect per dimension) <verdim:typedDimension> typed dimension identifier and XML fragment

2.3 Aspect Model Events

This specification defines three aspect model events. These events, in conjunction with fact-identification mappings, are based on pairs of aspect models representing information about facts, one from each of the From-DTS and To-DTS as being aspect-equivalent facts, as described in Section 2.3.2.

Table 3: Aspect model events
Code Element From Identifier To Identifier
[AspectModelChange] <verdim:aspectModelChange> AspectIdentifier AspectIdentifier
[AspectModelAdd] <verdim:aspectModelAdd> AspectIdentifier
[AspectModelDelete] <verdim:aspectModelDelete> AspectIdentifier

2.3.1 Event usage

The AspectModelChange event is intended to specify two combinations of aspects, one of which has superseded the other. The aspect identifiers on each side of the event can be used to select two sets of aspect-equivalent facts. Depending on the size of these sets and the aspects involved, this MAY allow software to work out an automated mapping from facts with the former aspect model to the current one.

The AspectModelAdd event is intended to convey the introduction of a newly allowed combination of aspects, without specifying that this be applied to any particular set of previously present facts.

The AspectModelDelete event is intended to convey that a combination of aspects is no longer to be reported, without specifying a new combination of aspects to be used instead.

2.3.2 Fact identification mappings

Fact identification mappings establish means of identifying facts that have equivalence in different instances referenced by two versioned DTSs.

For example, facts identified by their concept of a From-DTS may have equivalent identification in a To-DTS by means of a different concept and an explicit dimension of given member. (Note: This example leaves other aspects like unit, entity, location etc. out of scope here.)

Aspect model mapping information, which MAY include dimensional representation of a set of concepts, is obtained from the Versioning Report as follows:

  • For any action that contains at least one AspectModelChange event, then each aspect model identified by the <verdim:fromAspects> element of a AspectModelChange event and the <verdim:toAspects> element of a AspectModelChange event are to identify aspect-equivalent instance facts.
  • The AspectModelChanges are separate identifications of facts. They MAY be mutually exclusive if pertaining to independent issues (such as changing dimension aspect models for different dimensions), or they MAY be related (such as the specification of a concept and different members of a particular explicit dimension in the To-DTS for various concepts in the From-DTS).

3 Syntax

This specification only provides a textual declaration of syntax constraints when those constraints are not expressed by the normative schema supplied with this specification.

Explanations of elements and attributes are only supplied when explanations are not already provided in other specifications.

Unless explicitly stated otherwise, a reference to a specific element MUST be read as a reference to that element or to any element in its substitution group.

3.1 Aspects

This section describes the individual aspects that pertain to aspect models (for fact identification aspects), and to identify allowed and disallowed dimensional aspect combinations.

When there are multiple aspects reported for the same <verdim:fromAspects> or <verdim:toAspects> element, these aspects are all required to be present together to identify pertinent facts. In this way they behave as composite restricting filters. This allows the precise identification of facts with certain values for their concept and a specific combination of dimensional values.

The individual aspects are introduced first, with examples pertaining to individual aspects alone, and then examples are given showing the use of multiple aspects and the change from one aspect model to another.

3.1.1 Concept Aspect

The syntax for the <verdim:concepts> element is defined by the normative schema supplied with this specification.

The value for this aspect is the union of all concepts identified by the <verdim:concept> child elements of the <verdim:concepts> element. Multiple such child elements can be reported to indicate that facts that match any one of them are identified by this aspect.

Each <verdim:concept> element identifies a DTS concept by the @name attribute. For convenience and brevity of reporting it is possible to specify that the value for this aspect is a set of concepts related in some network in the DTS. This is achieved by combining the concept @name attribute with a nested <verdim:network> or <verdim:drsNetwork> , as described in Section 3.3. If no nested network element is provided, then the @name attribute is the single specified concept value identified by this <verdim:concept> element.

Example 1: Concept aspect

Aspect Reference
<verdim:concepts>
<verdim:concept name="dts:ConceptA"/>
<verdim:concept name="dts:ConceptB"/>
</verdim:concepts>
The concept aspect of this aspect model is ConceptA or ConceptB.
<verdim:concepts>
<verdim:concept name="dts:ConceptA">
<verdim:network axis="descendant-or-self" arc="link:presentationArc" arcrole="http://www.xbrl.org/2003/arcrole/parent-child" link="link:presentationLink" linkrole="http://www.xbrl.org/2003/role/link"/>
</verdim:concept>
</verdim:concepts>
The concept aspect of this aspect model is ConceptA or any of its descendants in the presentation network in the standard link role.

3.1.2 Explicit Dimension Aspect

The syntax for the <verdim:explicitDimension> element is defined by the normative schema supplied with this specification.

The explicit dimension identifier for this aspect is identified by the @name attribute. The @name attribute is a concept identifier and MUST resolve to a valid concept definition in the substitutionGroup xbrldt:dimensionItem which does not have the @xbrldt:typedDomainRef attribute, and which is in:

Error code verdime:invalidExplicitDimensionIdentifier is raised otherwise.

Each explicit dimension is deemed a separate aspect of a fact. The specification for this aspect is contained within a single <verdim:explicitDimension> element. Accordingly there MUST be at most one <verdim:explicitDimension> reported for each dimension concept within any given <verdim:toAspects> or <verdim:fromAspects> element. Error code verdime:duplicateExplicitDimensionAspect is raised otherwise.

3.1.2.1 Explicit Dimension Members

The <verdim:explicitDimension> element may have zero or more <verdim:member> elements.

  • If no <verdim:member> element is provided, then this aspect specifies the entire dimension. (For example a dimension aspect is being added or removed in entirety, with all members that are defined according to its DTS applying to that aspect).
  • If only one <verdim:member> element is provided, then that is the one dimension member that identifies the to/from fact being identified.
  • If multiple <verdim:member> elements are provided, they represent alternatives of member values for this dimension aspect.

A dimension aspect specified for <verdim:toAspects> mappings SHOULD have a uniquely identified member, so that the Versioning Report can be used to uniquely identify the aspects of a fact in the To-DTS.

The DTS concept for a <verdim:member> element of the explicitDimension aspect is identified by the @name attribute. As with the concept aspect, it is possible to specify a set of related concepts by means of a nested <verdim:network> or <verdim:drsNetwork> , as defined in Section 3.3. If no related concepts are specified, then this member element is the specified member value for this explicitDimension aspect. If related concepts are specified, then the members thus identified are all alternatives member values for this explicitDimension aspect, just as if multiple <verdim:member> elements had been provided.

The explicit dimension members are specified regardless of whether they are the default member or not, since this property has no bearing on the identification of aspect-equivalent facts.

Example 2: Explicit Dimension aspect

Aspect Reference
<verdim:explicitDimension name="dts:Dimension1">
<verdim:member name="dts:Member2"/>
</verdim:explicitDimension>
The explicit dimension aspect for the Dimension1 dimension element of this aspect model is the dimension member Member2.
<verdim:explicitDimension name="dts:Dimension1">
<verdim:member name="dts:Total">
<verdim:drsNetwork axis="descendant-or-self" linkrole="http://www.xbrl.org/2003/role/link"/>
</verdim:member>
</verdim:explicitDimension>
<verdim:explicitDimension name="dts:Dimension2">
<verdim:member name="dts:Member2"/>
</verdim:explicitDimension>
The aspect model identifies facts which have the concept Total or its descendants in the domain-member hierarchy as a member of Dimension 1, and also Member2 as a member of Dimension2. Facts which only report one of these dimensions are not identified by this aspect model.
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:explicitDimension name="dts:Country">
<verdim:member name="dts:Czechoslovakia"/>
</verdim:explicitDimension>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:explicitDimension name="dts:Country">
<verdim:member name="dts:CzechRepublic"/>
<verdim:member name="dts:Slovakia"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim:aspectModelChange>
The aspect model change event specifies that the Country dimension member Czechoslovakia has split into two members CzechRepublic and Slovakia.
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:explicitDimension name="dts:Country">
<verdim:member name="dts:CzechRepublic"/>
<verdim:member name="dts:Slovakia"/>
</verdim:explicitDimension>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:explicitDimension name="dts:Country">
<verdim:member name="dts:CzechSlovHyperUnion"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim:aspectModelChange>
The aspect model change event specifies that the Country dimension members CzechRepublic and Slovakia have merged to the imaginary future new member CzechSlovHyperUnion.
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concepts>
<verdim:concept name="dts:PrimaryItemA"/>
</verdim:concepts>
<verdim:explicitDimension name="dts:Dimension1">
<verdim:member name="dts:MemberA"/>
</verdim:explicitDimension>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concepts>
<verdim:concept name="dts:PrimaryItemA"/>
</verdim:concepts>
<verdim:explicitDimension name="dts:Dimension1">
<verdim:member name="dts:MemberC"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim:aspectModelChange>

Assume a model in which a primary item PrimaryItemA can have MemberA or MemberB for Dimension1 in the fromDTS but in the toDTS MemberA is replaced by MemberC. The aspect model change event here shows only the aspect which is changed as this is sufficient for fact identification mapping change tracking. There is only one change event, from the combination of PrimaryItemA as the concept aspect, and MemberA in Dimension1 for the dimension aspect, to an aspect model of PrimaryItemA and MemberC in Dimension1.

Note that for fact identification mapping purposes, no change event is documented for the combination of PrimaryItemA, MemberB in Dimension1, as this aspect model has not changed.

<verdim:aspectModelDelete>
<verdim:fromAspects>
<verdim:concepts>
<verdim:concept name="dts:PrimaryItemA"/>
</verdim:concepts>
<verdim:explicitDimension name="dts:Dimension1">
<verdim:member name="dts:MemberA"/>
</verdim:explicitDimension>
</verdim:fromAspects>
</verdim:aspectModelDelete>
Assume a model in which PrimaryItemA can have Dimension1 members MemberA and MemberB in the fromDTS, but in the toDTS MemberA is excluded. This event specifies the aspect model of PrimaryItemA, Dimension1 with MemberA, has been deleted (rather than this combination of fact identification aspects changed to some other set of aspects for the to DTS). There is no need to specify anything about PrimaryItemA with Dimension member MemberB as its fact identification aspects are unchanged.
<verdim:aspectModelDelete>
<verdim:fromAspects>
<verdim:explicitDimension name="dts:D">
<verdim:member name="dts:DMem1"/>
</verdim:explicitDimension>
<verdim:explicitDimension name="dts:E">
<verdim:member name="dts:EMem2"/>
</verdim:explicitDimension>
</verdim:fromAspects>
</verdim:aspectModelDelete>
Assume an aspect model in which in the fromDTS dimension D with members DMem1 or DMem2, and dimension E with members EMem1 or EMem2 are allowed. The toDTS excludes only the combination of D with DMem1 and E with EMem1 together. This is documented by deleting the specific combination D, DMem1 and E, EMem1 in the toDTS aspect model. In the absence of other events it should be understood that there has been no change in the permissibility of DMem1 and EMem1 as dimension members when used outside this specific combination.

Versioning Report information on concepts that represent primary items, hypercubes, dimensions and members are reported in the same manner as any other XBRL concepts, using the Concept Use Specification [XVS-Concept-Use] and Concept Details Specification [XVS-Concept-Details]. Versioning Report information on arcs that represent syntactical construction of dimensions and membership MAY be supported by a future specification. Versioning Report information on semantic validation rules for hypercubes are reported using the aspect model of this specification.

3.1.3 Typed Dimension Aspect

The syntax for the <verdim:typedDimension> element is defined by the normative schema supplied with this specification.

The typed dimension identifier for this aspect is identified by the @name attribute. The @name attribute is a concept identifier and MUST resolve to a valid concept definition in the substitutionGroup xbrldt:dimensionItem which has a @xbrldt:typedDomainRef attribute, and which is in:

Error code verdime:invalidTypedDimensionIdentifier is raised otherwise.

As with explicit dimensions, each typed dimension is deemed a separate aspect of a fact. The specification for this aspect is contained within a single <verdim:typedDimension> element. Accordingly there MUST be at most one <verdim:typedDimension> reported for each dimension concept within any given <verdim:toAspects> or <verdim:fromAspects> element. Error code verdime:duplicateTypedDimensionAspect is raised otherwise.

The value of the typed dimension is provided by the XML fragment contained by the <verdim:typedDimension> element. If no value is present, then the aspect specifies only the dimension (for example that a dimension is being added or removed, with all typed values that are defined according to its DTS).

Example 3: Typed Dimension aspect

Aspect Reference
<verdim:typedDimension
  xmlns:honahLee
="http://www.honahLee.com"
name="dts:DragonDimension">
<honahLee:dragon name="Puff"/>
</verdim:typedDimension>
The typed dimension aspect for the DragonDimension dimension value of this aspect model is the xml fragment <honahLee:dragon name="Puff"> .

When there is a change in a typed dimension's typed domain (the schema type of the element identified by the @xbrldt:typedDomainRef) then this should be reported as an aspect change. However there are no explicit events defined for reporting on individual XML schema elements and attributes composing the definition of a typed dimension's domain. A Versioning Report processor MAY discover the content model of such elements by inspection of the typed domain element when notified of an aspect change event which identifies only the dimension, without specification of a dimension value or a concept aspect. The example below illustrates such an event.

Example 4: Typed Dimension Aspect Change

Aspect Reference
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:typedDimension name="dts:DragonDimension"/>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:typedDimension name="dts2:DragonDimension"/>
</verdim:toAspects>
</verdim:aspectModelChange>
There has been a change in the typed dimension DragonDimension. No primary items are specified, so the change applies to all items which report the dimension. No typed value is specified, so there is no specific value for which a change in usage is being reported. As such this indicates a general change in this dimension and is the preferred mechanism for reporting a change in the typed domain of a typed dimension.

3.2 Aspect model

The aspects identified by the aspect model of <verdim:fromAspects> and <verdim:toAspects> elements are declared by the aspect elements ( Section 3.1) (corresponding to aspects of Table 2). These aspects are combined by "anding" to the others specified within the same element.

Whereas most of the examples in the previous section ( Section 3.1) addressed single aspect changes, this section provides examples where multiple aspects are combined.

Example 5: Aspect Model

Aspect Example
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concepts>
<verdim:concept name="dts:MachinesGross"/>
</verdim:concepts>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concepts>
<verdim:concept name="dts:PPEGross"/>
</verdim:concepts>
<verdim:explicitDimension name="dts:PPEAxis">
<verdim:member name="dts:MachinesMember"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim:aspectModelChange>
Assume that in the non-dimensional fromDTS, there is a hierarchy of concepts to represent breakdown of information: PPEGross->MachinesGross, where PPEGross is a parent and MachineGross a child concept (in the presentation and summation hierarchies). With the dimensional toDTS, fact items of the prior MachinesGross breakdown become fact items of the prior parent PPEGross concept with the member MachinesMember of the PPEAxis dimension. The purpose of the aspect model is to record fact identification mappings, e.g., that the items of MachinesGross become items of PPEGross with PPEAxis dimension MachinesMember

3.3 Related Concepts

It is possible to specify that the <verdim:concept> of a concept aspect or the <verdim:member> of an explicitDimension aspect applies to a hierarchy of concepts by means of either a <verdim:network> or <verdim:drsNetwork> child element. If no such child element is provided, then the @name attribute is the specified concept value for a concept aspect or member for an explicitDimension aspect.

Note that this mechanism is purely a means of identifying concepts for use in an aspect model. It does not convey any versioning information about any of the networks of relationships referenced.

If a <verdim:network> or <verdim:drsNetwork> is provided, then the concepts or members identified by the @axis attribute on that element, as related to the @name specified concept or member, are values of this aspect model.

The concept of axis as used in this specification is based on XPath's notion of axes (and has no relationship to multi-dimensional accounting notions of hypercubes or XBRL taxonomies that use the word axis to mean an XBRL dimension).

The content of the @axis attribute can be:

The <verdim:drsNetwork> is used to define dimensional relationship sets in a domain-member hierarchy. The <verdim:network> is used to define any network, and accordingly requires more information to be specified. As well as @axis the @linkrole attribute must be specified on both elements. This is the URI of the extended link role in which related concepts are identified. The differences between <verdim:drsNetwork> and <verdim:network> are as follows:

  • The axes only respect @xbrldt:targetRole switches on dimensional relationship sets when used on an <verdim:drsNetwork> .
  • The @arcrole attribute is required on a <verdim:network> .
  • For the <verdim:drsNetwork> the link is fixed as <link:definitionLink> , the arc as <link:definitionArc> and the arcrole as http://xbrl.org/int/dim/arcrole/domain-member.

When supplied, the value of a @linkrole or @arcrole attribute MUST be an absolute URI defined for and used by the appropriate DTS. Error code verdime:invalidURI is raised otherwise.

For the <verdim:network> there are conditions when it is necessary to specify @link and @arc to disambiguate base sets identified by the link- and arc roles. The @link and @arc attributes are QNames of link and arc elements respectively which are only required only when:

  • XBRL 2.1 standard link and arc role combinations are used in non-customary link or arc elements (e.g. parent-child arcrole is used in other than a <link:presentationLink> or in other than a <link:presentationArc> ), or
  • a custom arcrole which may be used on more than one arc in a generic link is specified.

The @link attribute MUST be the QName of a link element. Error code verdime:invalidLinkElement is raised otherwise.

The @arc attribute MUST be the QName of an arc element. Error code verdime:invalidArcElement is raised otherwise.

Appendix A Schema

The normative version of this schema can be found at http://www.xbrl.org/2013/versioning-dimensions.xsd. For convenience, a copy of the schema is included below.

<!-- Copyright 2007-2013 XBRL International. All Rights Reserved. -->
<xs:schema
  xmlns:xs
="http://www.w3.org/2001/XMLSchema"

  xmlns:verdim
="http://xbrl.org/2013/versioning-dimensions"

  xmlns:ver
="http://xbrl.org/2013/versioning-base"
targetNamespace="http://xbrl.org/2013/versioning-dimensions" elementFormDefault="qualified">
<xs:import namespace="http://xbrl.org/2013/versioning-base" schemaLocation="versioning-base.xsd"/>
<!-- Aspect models of instance facts -->
<xs:simpleType name="aspect.relationships.axis.type">
<xs:restriction base="xs:token">
<xs:enumeration value="child-or-self"/>
<xs:enumeration value="child"/>
<xs:enumeration value="descendant"/>
<xs:enumeration value="descendant-or-self"/>
</xs:restriction>
</xs:simpleType>
<!-- Aspect model of instance facts -->
<xs:complexType id="xml-aspect.aspects.type" name="aspect-model.aspects.type">
<xs:choice>
<xs:sequence>
<!-- Concept container element exactly once -->
<xs:element name="concepts" id="xml-change.concepts.aspect" type="verdim:aspect.concepts.type"/>
<!-- Any event in the aspect substitution group -->
<xs:element ref="verdim:aspect" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:sequence>
<!-- Any event in the aspect substitution group. No concept aspect, so min occurs is now 1 to prevent empty aspect change. -->
<xs:element ref="verdim:aspect" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:choice>
<xs:attributeGroup ref="ver:common.attributes"/>
</xs:complexType>
<!-- Types for aspect model events-->
<xs:complexType id="xml-change.aspect-model.element.event.type" name="aspect-model-change.event.type">
<xs:complexContent>
<xs:extension base="ver:event.type">
<xs:sequence>
<xs:element name="fromAspects" type="verdim:aspect-model.aspects.type"/>
<xs:element name="toAspects" type="verdim:aspect-model.aspects.type"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType id="xml-add.aspect-model.element.event.type" name="aspect-model-add.event.type">
<xs:complexContent>
<xs:extension base="ver:event.type">
<xs:sequence>
<xs:element name="toAspects" type="verdim:aspect-model.aspects.type"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType id="xml-delete.aspect-model.element.event.type" name="aspect-model-delete.event.type">
<xs:complexContent>
<xs:extension base="ver:event.type">
<xs:sequence>
<xs:element name="fromAspects" type="verdim:aspect-model.aspects.type"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Types for concrete aspect model identifiers-->
<xs:complexType id="xml-aspect.concepts.type" name="aspect.concepts.type">
<xs:complexContent>
<xs:extension base="verdim:aspect.type">
<xs:sequence>
<xs:element name="concept" type="verdim:aspect.concept.type" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType id="xml-aspect.concept.type" name="aspect.concept.type">
<xs:choice minOccurs="0">
<xs:element name="network" type="verdim:aspect.network.type"/>
<xs:element name="drsNetwork" type="verdim:aspect.drsnetwork.type"/>
</xs:choice>
<xs:attribute name="name" type="xs:QName"/>
<!-- optional attributes when specifying a hierarchy of concepts applies to this concept aspect -->
<xs:attributeGroup ref="ver:common.attributes"/>
</xs:complexType>
<xs:complexType id="xml-aspect.dimensionMember.type" name="aspect.dimensionMember.type">
<xs:choice minOccurs="0">
<xs:element name="drsNetwork" type="verdim:aspect.drsnetwork.type"/>
</xs:choice>
<xs:attribute name="name" type="xs:QName" use="required"/>
<xs:attributeGroup ref="ver:common.attributes"/>
</xs:complexType>
<xs:complexType id="xml-aspect.network.type" name="aspect.network.type">
<xs:complexContent>
<xs:extension base="verdim:aspect.drsnetwork.type">
<xs:attribute name="arcrole" type="xs:anyURI" use="required"/>
<xs:attribute name="arc" type="xs:QName" use="optional"/>
<xs:attribute name="link" type="xs:QName" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType id="xml-aspect.drsnetwork.type" name="aspect.drsnetwork.type">
<xs:attribute name="axis" type="verdim:aspect.relationships.axis.type" use="required"/>
<xs:attribute name="linkrole" type="xs:anyURI" use="required"/>
<xs:attributeGroup ref="ver:common.attributes"/>
</xs:complexType>
<xs:complexType id="xml-aspect.explicitDimension.type" name="aspect.explicitDimension.type">
<xs:complexContent>
<xs:extension base="verdim:aspect.type">
<xs:sequence>
<xs:element name="member" type="verdim:aspect.dimensionMember.type" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:QName" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType id="xml-aspect.typedDimension.type" name="aspect.typedDimension.type">
<xs:complexContent>
<xs:extension base="verdim:aspect.type">
<!-- the contents of the typedDimension that is being mapped -->
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="name" type="xs:QName" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Elements for aspect events -->
<xs:element id="xml-aspect-model-change.element.event" name="aspectModelChange" type="verdim:aspect-model-change.event.type" substitutionGroup="ver:event"/>
<xs:element id="xml-aspect-model-add.element.event" name="aspectModelAdd" type="verdim:aspect-model-add.event.type" substitutionGroup="ver:event"/>
<xs:element id="xml-aspect-model-delete.element.event" name="aspectModelDelete" type="verdim:aspect-model-delete.event.type" substitutionGroup="ver:event"/>
<!-- Elements for concrete aspect identifiers defined in the Versioning Dimensions spec. These are the aspects identified by example in requirement U1702 -->
<xs:element name="explicitDimension" id="xml-change.explicit.dimension.aspect" type="verdim:aspect.explicitDimension.type" substitutionGroup="verdim:aspect"/>
<xs:element name="typedDimension" id="xml-change.typed.dimension.aspect" type="verdim:aspect.typedDimension.type" substitutionGroup="verdim:aspect"/>
<!-- Abstract supertype for all aspect identifiers -->
<xs:element id="xml-change.aspect" name="aspect" type="verdim:aspect.type" abstract="true"/>
<xs:complexType id="xml-aspect.type" name="aspect.type">
<xs:attributeGroup ref="ver:common.attributes"/>
</xs:complexType>
</xs:schema>

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)
IETF RFC 2119
IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.

(See http://www.ietf.org/rfc/rfc2119.txt)
VARIABLES
XBRL International Inc.. "XBRL Variables 1.0"
Phillip Engel
, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/variables/REC-2009-06-22/variables-REC-2009-06-22.html)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2012-01-25"
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-2012-01-25.htm)
XML Names
W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Third Edition)"
(See http://www.w3.org/TR/REC-xml-names/REC-xml-names-20091208)
XML Schema Structures
W3C (World Wide Web Consortium). "XML Schema Part 1: Structures Second Edition"
Henry S. Thompson
, David Beech, Murray Maloney, and Noah Mendelsohn.
(See http://www.w3.org/TR/xmlschema-1/REC-xmlschema-1-20041028/)
XPath 1.0
W3C (World Wide Web Consortium). "XML Path Language (XPath) 1.0"
James Clark
, and Steve DeRose.
(See http://www.w3.org/TR/xpath/)
XVS-Base
XBRL International Inc. "XBRL Versioning Base 1.0"
Roland Hommes
, and Paul Warren.
(See http://www.xbrl.org/Specification/versioning-base/PR-2013-01-15/versioning-base-PR-2013-01-15.html)
XVS-Concept-Details
XBRL International. "Versioning Concept Details 1.0 Specification"
Roland Hommes
, Paul Warren, and Herm Fisher.
(See http://www.xbrl.org/Specification/versioning-concept-details/PR-2013-01-15/versioning-concept-details-PR-2013-01-15.html)
XVS-Concept-Use
XBRL International. "Versioning Concept Use 1.0 Specification"
Roland Hommes
, and Paul Warren.
(See http://www.xbrl.org/Specification/versioning-concept-use/PR-2013-01-15/versioning-concept-use-PR-2013-01-15.html)

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
20 December 2009Herm Fischer

Genesis based on suggestion by Maciej Piechocki, working group discussions at CEBS November 2009, and VWG e-mails in December 2009.

21 December 2009Herm Fischer

Enhanced descriptions of aspects and examples.

14 February 2010Herm Fischer

Fixed element and attribute xml codes formatting. Added optional explicitDimension attributes link and arc required only when standard link or arc roles are used on non-customary elements, and for generic link and arc roles used on multiple elements. Fixed typo example 5, member 66, removed axis. Initial specification of veria:hypercube, for the reporting of events concerning hypercube semantics that are not expressable by simple dimension attributes.

15 February 2010Herm Fischer

Clarified and separated of aspect model events from hypercube model events.

21 February 2010Herm Fischer

For explicitDimension, to facilitate axes that are domain-relationship-sets (respecting targetRole in domain-member relationship sets, alternate @DRS-axis is defined.

Improved text according to comments by Roland Hommes per e-mail 2010-02-16.

28 February 2010Herm Fischer

Improved text according to comments by Haiko Philipp per e-mail 2010-02-25. Reorganized section 3 from aspect model, individual aspects, hypercube model, to individual aspects first, then the two models (aspect and hypercube). Added example HP2.

29 May 2010Herm Fischer

Renamed and revised per Brussels F2F 2010-05-25, to reconsider aspects model as an instance aspects versioning module, and discontinue hypercube model. Added a relationship-sets module/model, of concept-to-concept relationships, which allows DTS authors to document changes to base sets and dimensional relationship sets, replacing use of the prior hypercube model for documenting extended link roles and their dimensional relationships. Added that location aspect can be used as an attribute predicate (instead of elements predicate as previously described) with example in dimensions overview document. Added relationship set option to concept aspect, so that it may apply to a hierarchy of concepts in a base set or dimensional relationship set of relationships.

07 June 2010Roland Hommes

Textual edits and comments placed.

10 July 2010Herm Fischer

Textual edits, and location aspect XPath context item clarified.

19 July 2010Herm Fischer

Editorial improvements per feedback by Suguru Washio, including adding comments on issues to be discussed.

08 August 2010Herm Fischer

Editorial improvements per feedback by Suguru Washio: Clarified example on aspect entity identifer.

29 August 2010Herm Fischer

Merged @axis and @DRS-axis to single attribute with separate value tokens for ordinary and DRS axes. Moved the previously-duplicated description of axis specifications to a new common section Section 3.3. Editorial improvements per working group meeting 2010-08-24.

23 January 2011Herm Fischer

Updated schema for QName concept identifier, dimension, member, link, arc, and unit.

14 October 2011Hugh Wallis

Corrected error codes veriae:missingAxisLinkroleAttribute and veriae:missingAxisArcroleAttribute

Fixed references to other specs

Minor editorial changes

15 October 2011Hugh Wallis

Added wording to make clear that the scenario and segment content is not made explicit per Roland Hommes.

16 April 2012Richard Ashby

Separated out the former Instance Aspects Spec into three more focussed specs: Dimensions, Tuples and other Instance Aspects. This, the Versioning Dimensions specification, has become the foundation specification for the versioning of fact aspects. Still contains the definitions of aspects and aspect change events, but the only aspect identifiers defined are those of concept, explicit dimensions, member and typed dimension. Created new namespace and namespace prefix of verdim for this spec and added a schema that matches the scope of the specification.

27 April 2012Richard Ashby

Added a container element verdim:concepts which can appear zero or once in an aspect event, and which contains as many concept elements as required to identify a range of concepts. It is now consistent that the immediate children of an aspect model add/change/delete event are to be ANDed together to restrict the range of identified facts.

28 June 2012Richard Ashby

Added <verdim:network> and <verdim:drsNetwork> as optional child elements of <verdim:concept> and <verdim:member> aspect identifiers. These contain the network axes information, if applicable, replacing the various conditionally required attributes on the concept or member elements. The schema now enforces more of the requirements, removing the need for error codes verdime:missingAxisLinkroleAttribute and verdime:missingAxisArcroleAttribute. Changes as per working group meeting 2012-05-01.

09 July 2012Richard Ashby

Clarified that the <verdim:network> and <verdim:drsNetwork> mechanism is just a device for identifying concepts and does not of itself convey versioning information about networks. Added example of related concepts through presentation network for concept aspect.

13 July 2012Stuart Barker

Added validation that explicit an dimension identifier must point to a valid explicit dimension declaration in the relevant DTS. Changes discussed on call on 2012-05-01.

16 July 2012Richard Ashby

Renamed the various verdim:bad* error codes to verdim:invalid*, to make them consistent with the error codes in the other versioning specs.

17 July 2012Richard Ashby

Add requirement that the From-DTS and To-DTS must be dimensionally valid, and not just XBRL valid. Reuse existing error code vere:invalidDTSIdentifier from base spec so no new code defined. Added validation for invalid typed dimension identifiers as equivalent to the recently introduced validation for explicit dimensions. Added error code verdime:invalidTypedDimensionIdentifier.

21 December 2012Richard Ashby

Removed the incorrect suggestion of reporting changes in @typedDomainRef using custom attribute events, as such events are not permitted for attributes in the xbrldt namespace. Supplied description and example for alternative means of reporting such a change, using an aspect model change for the typed dimension, unqualified by concept or dimension value.

08 January 2013Richard Ashby

Updated schema namespace to http://xbrl.org/2013/versioning-dimensions and error namespace to http://xbrl.org/2013/versioning-dimensions/error.

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 Versioning Working Group up to and including 27 February 2013. 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.