Overview of Versioning 1.0

Working Group Note 03 November 2010

Copyright ©2010 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/WGN/versioning-overview/WGN-2010-11-03/versioning-overview-WGN-WGN-2010-11-03.html>
Editor:
Herm Fischer, Mark V Systems <fischer@markv.com>
Contributors:
Roland Hommes, Rhocon <roland@rhocon.nl>
Haiko Philipp, IFRS Foundation <hphilipp@ifrs.org>
Ian Stokes-Rees, CoreFiling <ijs@corefiling.com>
Paul Warren, DecisionSoft <pdw@decisionsoft.com>
Huan Wang, Fujitsu Ltd. <wang.huan@jp.fujitsu.com>
Suguru Washio, Fujitsu Ltd. <wasio@jp.fujitsu.com>

Status

Circulation of this Working Group Note is unrestricted. Other documents may supersede this document. 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 overview supplements the Versioning Primer with a more comprehensive non-normative discussion of the XBRL Versioning Specification and its extension modules. Here is introduction to the terms, features, and basic examples of XBRL Versioning. These are demonstrated with diagrams and XML examples.

Comments

1 Herm Fischer:Proposing to change the location aspect to a more descriptive term, such as general aspect, or maybe "Special" aspect, something indicating it is no longer just for tuples. Also moved it past the unit aspect.
2 Herm Fischer:Is it really necessary to have concept events for such dimensions-constructing concepts that aren't business concepts?
3 Herm Fischer:Clarification per WG discussion 2010-06-22, please review this subsection:
4 Herm Fischer:This same point is repeated from a different perspective, under "Relating Models to Actions", and needs editing to not bore the reader but express the dimensional evolution here and the relating models to actions situation there.

Table of Contents

1 Introduction
2 Key Terms
3 Versioning report and base module events
4 Versioning concept events
5 Versioning relationship-set and instance-aspect model events
5.1 Relationship set model
5.2 Aspect model and aspects
5.3 Aspect-equivalent facts
5.4 Detail in models - minimalization
5.5 Relating models to actions
5.6 Aspects
5.6.1 Concept aspect
5.6.2 Explicit dimension aspect
5.6.3 Typed dimension aspect
5.6.4 Location aspect

Appendices

A Document history (non-normative)
B Errata corrections in this document
C History of Dimensional Versioning
C.1 Evolution in Dimensional Maintenance

Figures

1 Terms used in versioning modules
2 Terms relating to inputs and outputs
3 Terms relating to concept modules
4 Terms relating to models of relationship-sets and instance aspects modules

Examples

1 Report organization with namespace change event
2 Labels linkbase for namespace change event
3 Report organization with concept change events
4 Concept aspect
5 Explicit dimension concept without member details
6 Explicit dimension replaces concept hierarchy
7 Explicit dimension details in relationship set model
8 Explicit dimension applied to a primary item concept hierarchy
9 Typed dimension concept without value details
10 Typed dimension value mapping change
11 Location aspect tuple structure changes
12 Location aspect non-dimensional global ledger architecture mapped to financial reporting dimensional concepts
13 Location aspect documents instance fact attribute changed to explicit dimension aspect


1 Introduction

Suggested background for this overview includes reading the Versioning Primer, knowledge of XBRL 2.1 in general, some familiarity of XBRL Dimensions, and some experience with XBRL Instances and their DTSes.

Versioning describes changes to the architecture of XBRL instances as represented by their DTSes, and how information is represented in features of the instances.

This overview will orient the project manager and architect into what can be captured by versioning, for either production or consumption of XBRL Versioning Reports, and will introduce the developer to the features and syntax that are normatively described by module specifications

A compendium provides use cases that correspond to the Versioning Requirements.

In terms of approaching the module specifications, there is a progression as reflected in the diagrams, of increasingly complex nuanced versioning semantics, from base, concept basic, concept extended, to relationship sets and instance aspects. These versioning reports allow us to identify the objects of the change activity: DTSes, concepts, concept attributes and features, relationship sets, and fact identification aspects.

2 Key Terms

The terms used in versioning modules, that will be covered by this overview, are show in in Figure 1. These are diagrammed by the sources from which the versioning report is produced, the from DTS and its instances, to DTS and its instances, differences of technical and semantic nature, and those terms that are introduced by module specifications for the versioning report.

Figure 1: Terms used in versioning modules

Considering the artefacts referenced by a Versioning Report as inputs and the artefacts produced as part of that Versioning Report as outputs, we produce the black-box view of Versioning Report terms in Figure 2.

Figure 2: Terms relating to inputs and outputs

The inputs can be divided into business oriented information, consisting of:

and then DTSs and XBRL Instances which are referenced by the Versioning Report: A versioning report does not have any facility of physically incorporating any of these referenced inputs (DTS or XBRL instances) to become part of the versioning report, and a consuming report processor does not need them for basic processing of the report. However for a report consumer to follow the references and have access to schema definitions and relationship-sets makes it desirable to have access to the referenced DTSes (and examples of instances for instance aspect model changes).

The output Versioning Report consists of:

The terms that relate to the versioning concept modules are shown in Figure 3.

Figure 3: Terms relating to concept modules

The terms that relate to the models of the relationship-sets and instance aspects modules are shown in Figure 4.

Figure 4: Terms relating to models of relationship-sets and instance aspects modules

The key terms used in modelling are relationship sets model, aspect model, and aspect equivalent facts.

The relationship sets model tracks changes to the DTS representation of dimensional and any other relationships. The aspect model tracks changes to the instance aspects and supports the mapping of instance information.

3 Versioning report and base module events

Example 1 shows the contents of a report which contains an example of a report element, a <linkbaseRef> to the generic linkbase of annotational labels, the <fromDTS> and <toDTS> elements that specify the files of the two DTSes, an <assignment> of technicalCategory, and a single <action> which references the assignment and has one <event> , a namespaceRename.

Example 1: Report organization with namespace change event

<report
xmlns:link
="http://www.xbrl.org/2003/linkbase"

xmlns:xlink
="http://www.w3.org/1999/xlink"

xmlns
="http://xbrl.org/2010/versioning-base"
>
<link:linkbaseRef xlink:type="simple" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:title="documentation" xlink:href="gen-linkbase.xml"/>
<fromDTS>
<link:schemaRef xlink:type="simple" xlink:href="../fromDTS.xsd"/>
</fromDTS>
<toDTS>
<link:schemaRef xlink:type="simple" xlink:href="../toDTS.xsd"/>
</toDTS>
<assignment id="versioningTask">
<technicalCategory/>
</assignment>
<action id="eventGroup">
<assignmentRef ref="versioningTask"/>
<namespaceRename>
<fromURI value="http://example.com/test/2009"/>
<toURI value="http://example.com/test/2010"/>
</namespaceRename>
</action>
</report>

Example 2 shows the contents of an accompanying generic labels linkbase that contains annotational labels for the versioning report <assignment> and <action> elements. The assignment has the label "Compare two DTSs and report differences", and the action has the label "The schema target namespace was changed".

Example 2: Labels linkbase for namespace change event

<linkbase
xmlns:veria
="http://xbrl.org/2010/versioning-instance-aspects"

xmlns:xbrli
="http://www.xbrl.org/2003/instance"

xmlns:xbrldt
="http://xbrl.org/2005/xbrldt"

xmlns:link
="http://www.xbrl.org/2003/linkbase"

xmlns:xlink
="http://www.w3.org/1999/xlink"

xmlns:xsi
="http://www.w3.org/2001/XMLSchema-instance"

xmlns:label
="http://xbrl.org/2008/label"

xmlns:gen
="http://xbrl.org/2008/generic"

xmlns
="http://www.xbrl.org/2003/linkbase"

xmlns:ver
="http://xbrl.org/2010/versioning-base"

xmlns:vercb
="http://xbrl.org/2010/versioning-concept-base"

xmlns:verrels
="http://xbrl.org/2010/versioning-relationship-sets"
xsi:schemaLocation="http://xbrl.org/2008/generic http://www.xbrl.org/2008/gnl.xsd http://xbrl.org/2008/label http://www.xbrl.org/2008/generic-label.xsd">
<link:roleRef roleURI="http://www.xbrl.org/2008/role/link" xlink:href="http://www.xbrl.org/2008/generic-link.xsd#standard-link-role" xlink:type="simple"/>
<link:roleRef roleURI="http://www.xbrl.org/2008/role/label" xlink:href="http://www.xbrl.org/2008/generic-label.xsd#standard-label" xlink:type="simple"/>
<gen:link xlink:type="extended" xlink:role="http://www.xbrl.org/2008/role/link">
<link:loc xlink:type="locator" xlink:label="loc0" xlink:href="vers-report.xml#versioningTask"/>
<gen:arc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/2008/element-label" xlink:from="loc0" xlink:to="lbl0"/>
<label:label xml:lang="en" xlink:type="resource" xlink:label="lbl0" xlink:role="http://www.xbrl.org/2008/role/label">
Compare two DTSs and report differences.
</label:label>
<link:loc xlink:type="locator" xlink:label="loc1" xlink:href="vers-report.xml#eventGroup"/>
<gen:arc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/2008/element-label" xlink:from="loc1" xlink:to="lbl1"/>
<label:label xml:lang="en" xlink:type="resource" xlink:label="lbl1" xlink:role="http://www.xbrl.org/2008/role/label">
The schema target namespace was changed.
</label:label>
</gen:link>
</linkbase>

4 Versioning concept events

Example 3 shows the contents of a report which adds additional events to the prior example, to show typical changes for an action that renames a concept. There are three related events as a result of the renaming, <conceptRename> for the change of the element's QName, <conceptIDChange> for the related change of the element's ID, and <conceptLabelChange> for the label linkbase resource which changes with the renaming. The conceptLabelChange identifies both the concept changed, and the label linkbase resource element of the effective label (that surviving any linkbase prohibition and override activities). (If ineffective labels were also changed, such as one of lesser priority than the effective label, they are not reflected in the versioning report.)

Example 3: Report organization with concept change events

<report
xmlns:verce
="http://xbrl.org/2010/versioning-concept-extended"

xmlns:link
="http://www.xbrl.org/2003/linkbase"

xmlns:vercb
="http://xbrl.org/2010/versioning-concept-basic"

xmlns:xlink
="http://www.w3.org/1999/xlink"

xmlns
="http://xbrl.org/2010/versioning-base"
>
<link:linkbaseRef xlink:type="simple" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:title="documentation" xlink:href="gen-linkbase.xml"/>
<fromDTS>
<link:schemaRef xlink:type="simple" xlink:href="../fromDTS.xsd"/>
</fromDTS>
<toDTS>
<link:schemaRef xlink:type="simple" xlink:href="../toDTS.xsd"/>
</toDTS>
<assignment id="versioningTask">
<technicalCategory/>
</assignment>
<action id="eventGroup">
<assignmentRef ref="versioningTask"/>
<namespaceRename>
<fromURI value="http://example.com/test/2009"/>
<toURI value="http://example.com/test/2010"/>
</namespaceRename>
<vercb:conceptRename>
<vercb:fromConcept value="../fromDTS.xsd#dts_DebtOutstanding"/>
<vercb:toConcept value="../toDTS.xsd#dts_TotalDebt"/>
</vercb:conceptRename>
<verce:conceptIDChange>
<vercb:fromConcept value="../fromDTS.xsd#dts_DebtOutstanding"/>
<vercb:toConcept value="../toDTS.xsd#dts_TotalDebt"/>
</verce:conceptIDChange>
<verce:conceptLabelChange>
<vercb:fromConcept value="../fromDTS.xsd#dts_DebtOutstanding"/>
<verce:fromResource value="../fromDTS-lbl.xml#label_DebtOutstanding"/>
<vercb:toConcept value="../toDTS.xsd#dts_TotalDebt"/>
<verce:toResource value="../toDTS-lbl.xml#label_TotalDebt"/>
</verce:conceptLabelChange>
</action>
</report>

5 Versioning relationship-set and instance-aspect model events

The events of relationship-set and instance-aspect modules are based on models. This section introduces the relationship-set and instance-aspect models, and provides an overview of their version reporting.

5.1 Relationship set model

A relationship set model is a model of the relationships and their construction by base sets and dimensional consecutive relationship sets. This model is the 'net' result of the base set arcs and dimension relationship sets that become allowed and disallowed by arc equivalence, prohibition, and following relationship axes and (for dimensions) consecutive relationships.

For dimensional DTS maintainers, the relationship model provides the means to document link role and dimensional relationship set construction syntax, particularly syntax elements not visible to the aspects model such as conceptElement, usable, and dimension default (note that @isDimensionDefault is proposed for the explicit dimension member aspect of aspect models, but may be explicitly modeled in the relationship set.

5.2 Aspect model and aspects

The aspect model, is a notion of the Variables 1.0 specification; it is a description of how the information about a fact will be split into different aspects.

For facts with dimensional aspects the model also may identify excluded values. This permits specifying which values (and combinations) are not allowed, by the model, to be represented on facts.

The aspect models of the Variables specification are intended to be extensible and customizable, with aspects currently defined for common dimensional and non-dimensional use cases. The following aspects are introduced in this overview by example, and are deemed relevant to expected dimensions module use cases:

  • Concept aspect, representing a fact item's taxonomy concept
  • Explicit dimension aspect, one per dimension of a fact item (including defaulted dimensions, irrespective of segment or scenario location)
  • Typed dimension aspect, one per typed dimension of a fact item (irrespective of segment or scenario location).
  • Segment aspects, representing non-dimensional XML fragments of a segment
  • Scenario aspects, representing non-dimensional XML fragments of a scenario
  • Entity-identifier aspect, representing information in the entity scheme and identifier value
  • Period aspect, representing information in the period value
  • Location aspect, a predicate representing companion fact existence, values of related tuple contents and fact or related element attribute existence or values
  • Unit aspect, representing information in the unit

5.3 Aspect-equivalent facts

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

Full identification of a fact, as used in formula processing for example, requires specifying details usually not relevant to version reporting, such as period dates, units, and entity. In general the purpose of version reporting is to identify aspect equivalence sufficiently to report on the nature of a change, and not provide details beyond that except where they are relevant to reporting the change (such as when a from DTS instance tuple fact is denoted to be beginning or ending balance by a sibling tuple item value, and the corresponding to DTS instance fact uses context period date for the same purpose).

5.4 Detail in models - minimalization

The version report is meant to document change, but not to reproduce the detail in the DTS. Granularity is documented at the level of what was effected, sufficiently to be unambiguous. However the version report does not require providing a complete diff listing of unambiguous details below what is identified by actions and labels. When omitted, such details are obtainable by an XBRL processor when the changed items to be compared are specifically identified.

An example is the introduction of a set of dimensions to primary items, with a graph or even a complex algebra of allowed members, expressed by definition linkbase in the respective DTS. It is possible to represent the complete semantics of allowed and disallowed dimensions in a relationship sets model, but that is not appropriate beyond the level at which versioning report actions identify specific parts of the model and labels provide attached documentation to specific parts of the model. In general, it may be sufficient to have a single action identifying the dimensions as a dimensional relationship sets being introduced, and leave the full detail of the model to an XBRL processor.

A counter example is when an existing dimensional model is updated to respond to change in some reporting law or business practice, such as to exclude certain dimensional member values from being reported in given situations. That might be expressed by notAll has hypercube relations in a definition linkbase, and as an identification of excluded member values for the aspect models that identify concept and dimension member exclusions. For DTS maintenance, the documentation of link role networks such as primary-item member values can be specified in a relationship sets model. The relationship sets detail of link role and member value may be needed for the version report in this situation because the change is at the detailed level of the dimensional consecutive relationship sets.

5.5 Relating models to actions

There are situations where these models might be independent, part of separate actions, and others where they might be together part of the same action.

  • Major transitions might have separate actions for aspect and relationship set models
    • From tuple or multi-concept architectures to dimensional shared-concept architectures
    • Actions that just define the new dimensional taxonomy
      • These actions may only have relationship set models
    • Actions that define facts aspect modeling changes
      • These actions may only represent aspect model changes, such as specific concept naming changes and their dimensional aspects (possibly with separate actions per schedule or extended link role represented)
  • Regularly occurring tweaks, such as during year taxonomy updates
    • Tax and credit laws change, business and accounting practices change
    • Actions may be grouped per regulation and practice change
      • In this case an action has both (integrates) aspect and relationship set model changes

Current DTS architectures for financial reporting, now model and maintain structural and dimensional aspects in a model independent of the XBRL dimensions located in the definition linkbase. For example, a presentational linkbase may specifies and be the locus to maintain such a model using concepts denoted as tables, that have axes, dimension members, and line items, instead of primary items that relate to hypercubes, dimensions, and so on, in the definition linkbase. The definition linkbase entries that specify XBRL dimensions to an XBRL processor may be generated programmatically from the presentation linkbase entries that specify tables, axes, and line items. The versioning report, in such a case, MUST document such actions against the generated dimension semantics as represented by the definition linkbase, and MAY also document actions that modify the canonical model (such as tables/axes/line items in the presentation linkbase).

It is not required to report events of the explicit dimensions model that relate to dimension members maintained (by some process or project) using the presentational member hierarchy expressed by a producer's canonical model (such as of presentation relationships in financial reporting taxonomy practices), or dimensional primary item maintenance by hierarchy changes to the presentational relationships of table line items in a financial reporting taxonomy model. Because of this, tools which are used in such an environment would benefit from a two-way reflection of the duality of canonical models and XBRL semantic relationships, such that versioning reports documenting XBRL dimensions semantics can be related by the supportive tool set to the equivalent alternate in the model used for maintenance.

5.6 Aspects

5.6.1 Concept aspect

A concept aspect is used in an aspect model to represent which specific concept is used to report the business fact of instance document item.

There would usually be one concept aspect for any single aspect model of fact identification. If multiple concept aspects are provided in an aspect model, they represent a set of alternative concept aspects that are grouped together. But it is not specified what the meaning would be of having groups of multiple concept aspects for a aspect model, such a situation is explained by an accompanying label. (For example the action may report that a set of concepts have some joint change, such as to adopt a dimension, but do not specify sufficient information for an instance document mapping tool to unambiguously know how to apply this information.)

The concept aspect may identify a hierarchy of concepts, specified by relationships, to apply collectively to the given aspect model. For example, this can be useful when a dimensional primary item hierarchy (or any other relational set hierarchy) applies in entirety to an aspect model.

Example 4: Concept aspect

Aspect Example
<veria:concept href="dts1.xsd#A"/>
The concept aspect of this aspect model is the dts1.xsd element with ID A.
<veria:concept href="dts1.xsd#A"/>
<veria:concept href="dts1.xsd#B"/>
<veria:concept href="dts1.xsd#C"/>
<veria:concept href="dts1.xsd#D"/>
The concept aspect of this aspect model is the dts1.xsd element with ID A, B, C or D, but the specifics of reporting four alternative concepts for this aspect may be conveyed by a label on the aspect model, or possibly even separate labels on each concept aspect. For example, one might be reporting that A, B, C, and D have a new dimension applied in to-DTS instances.

The concept aspect pertains only to fact items. If these items are located in tuples, and it is necessary to provide more specifics to identify a particular aspect model, then the location aspect is used. (For example, in GL instances, the "amount" concept aspect of an item is insufficient to identify which financial account the value applies to, without further specification of other members of its containing tuple.)

5.6.2 Explicit dimension aspect

An explicit dimension aspect, as used in an aspect models, represents the presence or exclusion of a value for a dimension in the aspect model for a fact item. This expresses the validity of that dimension when it is a specified dimension of closed hypercubes. (It is not relevant to specifying unvalidated open dimensions.) This section will focus on the explicit dimension element as used for aspect modeling of specified dimensions (not of open unspecified dimensions).

When an explicit dimension aspect is provided by itself without further details, it simply specifies that the complete dimension as defined in the DTS is being applied.

Example 5: Explicit dimension concept without member details

Aspect Example
<veria:concept href="dts1.xsd#A"/>
<veria:concept href="dts1.xsd#B"/>
<veria:concept href="dts1.xsd#C"/>
<veria:explicitDimension href="dts1.xsd#Dimension1"/>
The concepts A, B, and C are reported with Dimension1 values.

Further specific information may be provided by the member element and optional axis element. Specifying member is relevant when a version report identifies further details in fact identification mapping. When a member is just identified by itself, without axis information, then only that member value pertains to the reported change.

In this example the fromDTS is non-dimensional, with a concept hierarchy to represent breakdown

Concept Hierarchy No Dimension
PPEGross (none)
PPEMachinesGross (none)

and the toDTS is dimensional, with a shared concept and member hierarchy to represent breakdown

Concept Dimension
PPEGross TotalGross member (default)
PPEGross MachinesGross member

Two aspect models are provided, one for the mapping of relevant aspects to identify facts of the PPEGross total dimension member, and one for the machines breakdown dimension member. Note that the total gross member, though being default, is expressed explicitly in the aspects model, because it is semantically present.

In addition, a minimalist relationship set model is provided, just for completeness of this example, to document that the PPEAxis dimension is present in the toDTS (and not in the fromDTS).

Concept basic events are shown in this example, and then omitted in the remainder of this document. Events are needed for concepts that are primary items in the toDTS and replace non-dimensional concepts in the fromDTS, because these concepts represent business concepts (e.g., that are the concept aspect of items in the instance document). These events are grouped as a related set of events (as the single dimensional primary item is related to multiple non-dimensional business concept facts).

Events are shown separately for the concepts that represent the hypercube, dimension, and dimension members. These are not business concepts by the definition in concept-basic, as they aren't an abstract definition of an individual piece of business information, and perhaps as such aren't as necessary to report.

[Herm Fischer: Is it really necessary to have concept events for such dimensions-constructing concepts that aren't business concepts?]

Example 6: Explicit dimension replaces concept hierarchy

Aspect Example
<veria:aspectModelChange>
<veria:fromAspects>
<veria:concept href="fromDTS.xsd#PPEGross"/>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="toDTS.xsd#PPEGross"/>
<veria:explicitDimension href="toDTS.xsd#PPEAxis">
<veria:member href="toDTS.xsd#TotalGrossDomain"/>
</veria:explicitDimension>
</veria:toAspects>
</veria:aspectModelChange>
The aspect model change for the PPEGross concept, which in toDTS instances, is represented by the same concept with the TotalGrossDomain dimension member.
<veria:aspectModelChange>
<veria:fromAspects>
<veria:concept href="fromDTS.xsd#PPEMachinesGross"/>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="toDTS.xsd#PPEGross"/>
<veria:explicitDimension href="toDTS.xsd#PPEAxis">
<veria:member href="toDTS.xsd#MachinesMember"/>
</veria:explicitDimension>
</veria:toAspects>
</veria:aspectModelChange>
The aspect model change for PPEMachinesGross concept, which in toDTS instances, is also represented by the PPEGross concept, but with the MachinesMember dimension member.
<verrels:relationshipSetModelAdd>
<verrels:toRelationshipSet>
<verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/all">
<verrels:relationships fromHref="toDTS.xsd#PPEGross" toHref="toDTS.xsd#PPETable" DRSaxis="descendant-or-self"/>
</verrels:relationshipSet>
</verrels:toRelationshipSet>
</verrels:relationshipSetModelAdd>
As the toDTS has a table (hypercube and descendants) which, for this example, did not exist in fromDTS, there is a relationship set event to document that the PPETable (hypercube and descendants) is added to the toDTS.
<vercb:conceptDelete>
<vercb:fromConcept value="fromDTS.xsd#PPEMachinesGross"/>
</vercb:conceptDelete>

This table row shows concept basic events for the primary items, but the remainder of examples in this document omit concept basic event examples.

The business concept PPEMachinesGross is removed from the toDTS as the business concept it represented is now a dimensional primary item sharing the prior and remaining business concept, PPEGross.

<vercb:conceptAdd>
<vercb:toConcept value="toDTS.xsd#PPETable"/>
</vercb:conceptAdd>
<vercb:conceptAdd>
<vercb:toConcept value="toDTS.xsd#PPEAxis"/>
</vercb:conceptAdd>
<vercb:conceptAdd>
<vercb:toConcept value="toDTS.xsd#TotalGrossDomain"/>
</vercb:conceptAdd>
<vercb:conceptAdd>
<vercb:toConcept value="toDTS.xsd#MachinesMember"/>
</vercb:conceptAdd>

This table row shows concept basic events for the concepts used to construct the dimensional relationships, even though these concepts are not business concepts. The remainder of examples in this document omit concept basic event examples.

Non- business concepts are added to the toDTS to represent the hypercube (table), dimension (axis), domain (total member), and machines member.

An alternate versioning report might provide the preceeding example events and in addition provide detailed relationship set events for the dimensional relationships that are unnecessary to specify because they are already known to an XBRL processor. In this case the hypercube element has linkrole, closed, and contextElement, a primaryItem element is provided, dimension domain and the dimension member are provided.

This is not recommended that a tool to generate such a report with such additional redundant semantics as output, but a validation report processing tool must accept such a report as an input element is provided, dimension domain and the dimension member are provided.

Example 7: Explicit dimension details in relationship set model

Aspect Example
<verrels:relationshipSetModelAdd>
<verrels:toRelationshipSet>
<verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/all">
<verrels:relationships fromHref="toDTS.xsd#PPEGross" toHref="toDTS.xsd#PPETable" DRSaxis="self" xbrldt:closed="true" xbrldt:contextElement="segment"/>
</verrels:relationshipSet>
</verrels:toRelationshipSet>
</verrels:relationshipSetModelAdd>
<verrels:relationshipSetModelAdd>
<verrels:toRelationshipSet>
<verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/hypercube-dimension">
<verrels:relationships fromHref="toDTS.xsd#PPETable" toHref="toDTS.xsd#PPEAxis" DRSaxis="self"/>
</verrels:relationshipSet>
</verrels:toRelationshipSet>
</verrels:relationshipSetModelAdd>
<verrels:relationshipSetModelAdd>
<verrels:toRelationshipSet>
<verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/dimension-domain">
<verrels:relationships fromHref="toDTS.xsd#PPEAxis" toHref="toDTS.xsd#TotalGrossDomain" DRSaxis="self"/>
</verrels:relationshipSet>
</verrels:toRelationshipSet>
</verrels:relationshipSetModelAdd>
<verrels:relationshipSetModelAdd>
<verrels:toRelationshipSet>
<verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/domain-member">
<verrels:relationships fromHref="toDTS.xsd#TotalGrossDomain" toHref="toDTS.xsd#MachinesMember" DRSaxis="self"/>
</verrels:relationshipSet>
</verrels:toRelationshipSet>
</verrels:relationshipSetModelAdd>
As the toDTS has a dimension which, for this example, did not exist in fromDTS, there are individual relationship model events to document that each of the hypercube is added to the primary item, the dimension to the hypercube, total member domain to dimension, and machines member to the domain. This detail is not necessary in a processor-supported reporting situation.

In this example a set of primary items in a DRS hierarchy, inheriting from and including concept PriItemA, are all given an added dimension NewAxis, with its DRS hierarchy of members applied to these primary items.

Example 8: Explicit dimension applied to a primary item concept hierarchy

Aspect Example
<veria:aspectModelChange>
<veria:fromAspects>
<veria:concept href="fromDTS.xsd#PriItemA" DRS-axis="descendant-or-self" linkrole="http://abc.com/pri-item-linkrole"/>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="toDTS.xsd#PriItemA" DRS-axis="descendant-or-self" linkrole="http://abc.com/pri-item-linkrole"/>
<veria:explicitDimension href="toDTS.xsd#NewAxis"/>
</veria:toAspects>
</veria:aspectModelChange>
The primary item PriItemA, and its descendants in primary item inheritance, are changed by addition of a dimension, NewAxis, and all of NewAxis's members are applied to all these primary items.

5.6.3 Typed dimension aspect

A typed dimension aspect, as used in an aspect models, represents the presence or exclusion of a value for a typed dimension in the aspect model for a fact item.

When an typed dimension aspect is provided by itself without an XML fragment, it simply specifies that the complete dimension as defined in the DTS is being applied.

Example 9: Typed dimension concept without value details

Aspect Example
<veria:concept href="dts1.xsd#A"/>
<veria:concept href="dts1.xsd#B"/>
<veria:concept href="dts1.xsd#C"/>
<veria:typedDimension href="dts1.xsd#Dimension1"/>
The concepts A, B, and C are reported with Dimension1 values.

Further specific information may be provided by an XML fragment, contained within the typedDimension element, that is a typed dimension value. Specifying the typed dimension value is relevant when a version report identifies further details in fact identification mapping. When the value is provided, the change reported applies only to typed dimensions with the given value.

In this example the fromDTS concept PriItemA, typed dimension Dimension1 has values which are changed, from <oldElt oldAttr1="1">oldVal</oldElt> to <newElt newAttr1="1">newVal</newElt>.

Example 10: Typed dimension value mapping change

Aspect Example
<veria:aspectModelChange>
<veria:fromAspects>
<veria:concept href="fromDTS.xsd#PriItemA"/>
<veria:typedDimension
xmlns:abcdim
="http://www.abc.com/abcOldDim"
href="fromDTS.xsd#Dimension1">
<abcdim:oldElt oldAttr="1">
oldVal
</abcdim:oldElt>
</veria:typedDimension>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="toDTS.xsd#PriItemA"/>
<veria:typedDimension
xmlns:abcdim
="http://www.abc.com/abcNewDim"
href="toDTS.xsd#Dimension1">
<abcdim:newElt newAttr="1">
newVal
</abcdim:newElt>
</veria:typedDimension>
</veria:toAspects>
</veria:aspectModelChange>
The facts of concept PriItemA, and typed dimension value <oldElt> as specified, are re-mapped to have a typed dimension value <newElt> as specified.

5.6.4 Location aspect

The location aspect provides a predicate expression, in XPath, to identify a fact by its location amongst other facts of the same context in other tuples, or to express a predicate including existence or value of an attribute(s) of the fact or related fact. The location aspect provides an XPath simple predicate that has the fact to be identified as the context item.

Use of XPath 1 is shown here, but it is likely that the current W3C recommendation of XPath 2 will be recommended by the Dimension Module, with intentional compatibility to prior XPath 1 expressions.

Examples studied for the location aspect may or may not involve dimensions but seem to be consistent in that between the fromDTS and toDTS there are alterations in the tuple structure that require specifying how facts of fromDTS instances are adopted to new family structures in the toDTS instance without loosing associativity of those tuple-originating facts that need to hang together in the different tuple-destination structure.

In the first examples, an adapted country business reporting taxonomy fromDTS instance has a different tuple structure from that of the toDTS, and the taxonomy details do not provide any indication of how the facts are remapped from fromDTS instances to toDTS instances without losing the associativity inherent in the tuple structure.

The first table row shows that the key difference between contexts for the payee tuple is the addition of a dimension. This is documented in the versioning report by the addition of a new hypercube model.

The second table row shows that although that a dimension is added in the toDTS and documented by addition of a dimension aspect, a more important key difference in fact identification (mapping) between the DTS instances is in how the family members of a payee tuple "hang together". In the fromDTS instance and toDTS instance, the tax identification number is considered the key basis to consider which fromDTS tuple facts are mapped to toDTS tuple (dimensioned) facts. Notice that although items like name details, payroll number, and birth date are siblings in both from and toDTS instances, the signature items, that were siblings of the tax identification number, have become nephews in the instance of the toDTS (therein nested in a new signature tuple).

The need to locate nephews and such tuple relatives, with a key identifier (here the tax identification number), is a key feature of the location aspect model (based on an XPath relative expression).

Tuple non-dimensional fromDTS Refactored tuple, dimensional toDTS
<xbrli:context id="C001">
<xbrli:entity>
<xbrli:identifier scheme="http://example.gov">
ABC
</xbrli:identifier>
</xbrli:entity>
<xbrli:period>
<xbrli:startDate>
2008-10-10
</xbrli:startDate>
<xbrli:endDate>
2008-10-10
</xbrli:endDate>
</xbrli:period>
</xbrli:context>
<xbrli:context id="C001">
<xbrli:entity>
<xbrli:identifier scheme="http://example.gov/abc">
123456789
</xbrli:identifier>
<xbrli:segment>
<xbrldi:explicitMember dimension="dim:ReportPartyTypeDimension">
dim:ReportingParty
</xbrldi:explicitMember>
</xbrli:segment>
</xbrli:entity>
<xbrli:period>
<xbrli:startDate>
2009-07-01
</xbrli:startDate>
<xbrli:endDate>
2010-06-30
</xbrli:endDate>
</xbrli:period>
</xbrli:context>
<abc:PayeeDetails>
<abc:TaxFilingNumber contextRef="C001">
33917895334
</abc:TaxFilingNumber>
<abc:PersonNameDetails>
<abc:PersonCurrencyCode contextRef="C001">
C
</abc:PersonCurrencyCode>
<abc:LastName contextRef="C001">
Weier
</abc:LastName>
<abc:FirstName contextRef="C001">
Michael
</abc:FirstName>
</abc:PersonNameDetails>
<abc:PersonBirthDate contextRef="C001">
1974-05-14
</abc:PersonBirthDate>
<abc:EmployeePayrollNumber contextRef="C001">
SAL100070
</abc:EmployeePayrollNumber>
<abc:PaymentTerminationCode contextRef="C001">
T
</abc:PaymentTerminationCode>
<abc:PaymentBasisCode contextRef="C001">
F
</abc:PaymentBasisCode>
<abc:DeclarationHardcopyIndicator contextRef="C001">
true
</abc:DeclarationHardcopyIndicator>
<abc:SignatureDate contextRef="C001">
2008-08-01
</abc:SignatureDate>
</abc:PayeeDetails>
<abc:Payee>
<abc:TaxFilingNumber contextRef="C001">
33917895334
</abc:TaxFilingNumber>
<abc:PersonNameDetails>
<abc:PersonTypeCode contextRef="C001">
LGL
</abc:PersonTypeCode>
<abc:PersonCurrencyCode contextRef="C001">
C
</abc:PersonCurrencyCode>
<abc:LastName contextRef="C001">
Weier
</abc:LastName>
<abc:FirstName contextRef="C001">
Michael
</abc:FirstName>
</abc:PersonNameDetails>
<abc:PersonBirthDate contextRef="C001">
1974-05-14
</abc:PersonBirthDate>
<abc:EmployeePayrollNumber contextRef="C001">
SAL100070
</abc:EmployeePayrollNumber>
<abc:PaymentTerminationCode contextRef="C001">
T
</abc:PaymentTerminationCode>
<abc:PaymentBasisCode contextRef="C001">
F
</abc:PaymentBasisCode>
<abc:Declaration>
<abc:StatementType contextRef="C001">
HardCopy
</abc:StatementType>
<abc:AcceptanceIndicator contextRef="C001">
true
</abc:AcceptanceIndicator>
<abc:SignatureDate contextRef="C001">
2009-09-10
</abc:SignatureDate>
</abc:Declaration>
</abc:Payee>

Example 11: Location aspect tuple structure changes

Aspect Example
<verrels:relationshipSetModelAdd>
<verrels:toRelationshipSet>
<verrels:relationshipSet linkrole="http://example.gov/roles/defRole" arcrole="http://xbrl.org/int/dim/arcrole/all">
<verrels:relationships fromHref="current/toDTS.xsd#abc_ReportPartyTypeDimension"/>
</verrels:relationshipSet>
</verrels:toRelationshipSet>
</verrels:relationshipSetModelAdd>
The dimensional relationship set model is added for the reporting party dimension which is used in the toDTS.
<veria:aspectModelChange>
<veria:fromAspects>
<veria:concept href="prior/fromDTS.xsd#abc_TaxFilingNumber"/>
<veria:concept href="prior/fromDTS.xsd#abc_PersonBirthDate"/>
<veria:concept href="prior/fromDTS.xsd#abc_EmployeePayrollNumber"/>
<veria:concept href="prior/fromDTS.xsd#abc_PaymentTerminationCode"/>
<veria:location>
../abc:PayeeDetails/abc:TaxFilingNumber
</veria:location>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="current/toDTS.xsd#abc_TaxFilingNumber"/>
<veria:concept href="current/toDTS.xsd#abc_PersonBirthDate"/>
<veria:concept href="current/toDTS.xsd#abc_EmployeePayrollNumber"/>
<veria:concept href="current/toDTS.xsd#abc_PaymentTerminationCode"/>
<veria:explicitDimension href="current/toDTS.xsd#abc_ReportPartyTypeDimension">
<veria:member href="current/toDTS.xsd#abc_ReportingParty"/>
</veria:explicitDimension>
<veria:location>
../abc:Payee/abc:TaxFilingNumber
</veria:location>
</veria:toAspects>
</veria:aspectModelChange>
The aspect model change for siblings of the tax file number keeps these siblings together (in same location with respect to tax file number) in fromDTS and toDTS instances, and adds the explicit dimension aspect in instances of the toDTS.
<veria:fromAspects>
<veria:concept href="prior/fromDTS.xsd#abc_SignatureDate"/>
<veria:concept href="prior/fromDTS.xsd#abc_DeclarationHardcopyIndicator"/>
<veria:location>
../abc:PayeeDetails/abc:TaxFilingNumber
</veria:location>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="current/toDTS.xsd#abc_StatementType"/>
<veria:concept href="current/toDTS.xsd#abc_AcceptanceIndicator"/>
<veria:concept href="current/toDTS.xsd#bc_SignatureDate"/>
<veria:explicitDimension href="current/toDTS.xsd#abc_ReportPartyTypeDimension">
<veria:member href="current/toDTS.xsd#abc_ReportingParty"/>
</veria:explicitDimension>
<veria:location>
../abc:Declaration/abc:Payee/abc:TaxFilingNumber
</veria:location>
</veria:toAspects>
The aspect model change declaration signature and hardcopy indicator, which were siblings of the tax file number in instances of the fromDTS, are a larger set of concepts in the toDTS in a different location, now nested in the declaration subtuple, so these items have morphed from siblings to nephews, of the tax file number.

In this example, four facts provide a Global-Ledger (GL) style of tuple in the fromDTS instance, and a Financial Reporting (FR) style of concept in the toDTS instance, using a Financial Reporting style of taxonomy with with dimensions. The prefix gl is used arbitrarily for the fromDTS, and fr for the toDTS.

This example differs from the country business reporting taxonomy preceding in that here specific tuples, identified by the value of an item in the tuple, are mapped to different concepts. In the country business reporting example, every tuple of the same family structure was mapped to a toDTS dimensioned tuple of a slightly different structure (there, some prior-siblings became nephews in the toDTS instance). Here the item that is mapped to the toDTS instance has a different concept based on the value of a nephew item (instead of 'hanging together' with the nephew item in a resulting tuple of different structure).

GL Tuple fromDTS FR dimensional model toDTS
<gl:entryDetail>
<gl:amount>
1000
</gl:amount>
<gl:account>
<gl:accountMainId>
3000
</gl:accountMainId>
</gl:account>
</gl:entryDetail>
<xbrli:context id="c1">
<xbrli:entity>
<xbrli:segment>
<xbrldi:explicitMember dimension="fr:ComponentsOfEquityAxis">
fr:IssuedCapitalMember
</xbrldi:explicitMember>
</xbrli:segment>
</xbrli:entity>
</xbrli:context>
<!-- ... -->
<fr:IncreaseDecreaseThroughChangesInAccountingPolicies contextRef="c1">
1000
</fr:IncreaseDecreaseThroughChangesInAccountingPolicies>
<gl:entryDetail>
<gl:amount>
2000
</gl:amount>
<gl:account>
<gl:accountMainId>
4000
</gl:accountMainId>
</gl:account>
</gl:entryDetail>
<xbrli:context id="c2">
<xbrli:entity>
<xbrli:segment>
<xbrldi:explicitMember dimension="fr:ComponentsOfEquityAxis">
fr:SharePremiumMember
</xbrldi:explicitMember>
</xbrli:segment>
</xbrli:entity>
</xbrli:context>
<!-- ... -->
<fr:IncreaseDecreaseThroughCorrectionsOfErrors contextRef="c2">
2000
</fr:IncreaseDecreaseThroughCorrectionsOfErrors>
<gl:entryDetail>
<gl:amount>
3000
</gl:amount>
<gl:account>
<gl:accountMainId>
5000
</gl:accountMainId>
</gl:account>
</gl:entryDetail>
<xbrli:context id="c3">
<xbrli:entity>
<xbrli:segment>
<xbrldi:explicitMember dimension="fr:ComponentsOfEquityAxis">
fr:TreasurySharesMember
</xbrldi:explicitMember>
</xbrli:segment>
</xbrli:entity>
</xbrli:context>
<!-- ... -->
<fr:IncreaseDecreaseThroughOtherContributionsByOwners contextRef="c3">
3000
</fr:IncreaseDecreaseThroughOtherContributionsByOwners>
<gl:entryDetail>
<gl:amount>
4000
</gl:amount>
<gl:account>
<gl:accountMainId>
6000
</gl:accountMainId>
</gl:account>
</gl:entryDetail>
<xbrli:context id="c4">
<xbrli:entity>
<xbrli:segment>
<xbrldi:explicitMember dimension="fr:ComponentsOfEquityAxis">
fr:OtherEquityInterestMember
</xbrldi:explicitMember>
</xbrli:segment>
</xbrli:entity>
</xbrli:context>
<!-- ... -->
<fr:DividendsPaid contextRef="c4">
4000
</fr:DividendsPaid>

The amount item in a tuple of the instance of the fromDTS is aspect equivalent to the fr:IncreaseDecreaseThroughChangesInAccountingPolicies item in the instance of the toDTS when the amount has, in its tuple "family", a "nephew" item, gl:accountMainId, with the value "3000". The same pattern is applied for the other three items, resulting in three aspect models.

Example 12: Location aspect non-dimensional global ledger architecture mapped to financial reporting dimensional concepts

Aspect Example
<veria:aspectModelChange>
<veria:fromAspects>
<veria:concept href="fromDTS.xsd#amount"/>
<veria:location>
../gl:account/gl:accountMainId = ‘3000’
</veria:location>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="toDTS.xsd#IncreaseDecrease­ThroughChangesInAccountingPolicies"/>
<veria:explicitDimension href="toDTS.xsd#ComponentsOfEquityAxis">
<veria:member href="toDTS.xsd#IssuedCapitalMember"/>
</veria:explicitDimension>
</veria:toAspects>
</veria:aspectModelChange>
The aspect model change for amount with nephew account 3000 to ifrs:IncreaseDecrease­ThroughChanges­InAccountingPolicies with dimension ComponentsOfEquityAxis, member IssuedCapitalMember.
<veria:aspectModelChange>
<veria:fromAspects>
<veria:concept href="fromDTS.xsd#amount"/>
<veria:location>
../gl:account/gl:accountMainId = ‘4000’
</veria:location>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="toDTS.xsd#IncreaseDecrease­ThroughCorrectionsOfErrors"/>
<veria:explicitDimension href="toDTS.xsd#ComponentsOfEquityAxis">
<veria:member href="toDTS.xsd#SharePremiumMember"/>
</veria:explicitDimension>
</veria:toAspects>
</veria:aspectModelChange>
The aspect model change for amount with nephew account 4000 to ifrs:IncreaseDecrease­Through­CorrectionsOfErrors with dimension ComponentsOfEquityAxis, member SharePremiumMember.
<veria:aspectModelChange>
<veria:fromAspects>
<veria:concept href="fromDTS.xsd#amount"/>
<veria:location>
../gl:account/gl:accountMainId = ‘5000’
</veria:location>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="toDTS.xsd#IncreaseDecrease­ThroughOtherContributionsByOwners"/>
<veria:explicitDimension href="toDTS.xsd#ComponentsOfEquityAxis">
<veria:member href="toDTS.xsd#TreasurySharesMember"/>
</veria:explicitDimension>
</veria:toAspects>
</veria:aspectModelChange>
The aspect model change for amount with nephew account 5000 to ifrs:IncreaseDecrease­ThroughOther­ContributionsByOwners with dimension ComponentsOfEquityAxis, member TreasurySharesMember.
<veria:aspectModelChange>
<veria:fromAspects>
<veria:concept href="fromDTS.xsd#amount"/>
<veria:location>
../gl:account/gl:accountMainId = ‘6000’
</veria:location>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="toDTS.xsd#DividendsPaid"/>
<veria:explicitDimension href="toDTS.xsd#ComponentsOfEquityAxis">
<veria:member href="toDTS.xsd#OtherEquityInterestMember"/>
</veria:explicitDimension>
</veria:toAspects>
</veria:aspectModelChange>
The aspect model change for amount with nephew account 6000 to ifrs:DividendsPaid with dimension ComponentsOfEquityAxis, member OtherEquityInterestMember.

In this example, facts of the fromDTS have context IDs representing type fiscal quarter in the context ID character string, and in the toDTS have dimensional members representing the fiscal quarter. contextRef="currentYrQ1..." becomes explicit dimension FY member currentYrQ1, prior1YrYtd and prior2YrYtd become dimension FY members of the same name. The location aspect expresses the @contextRef attribute beginning string portion to obtain the dimension for instances of the toDTS.

contextRef fiscal period dimensional fiscal period
<eg:factX contextRef="currentYrQ1StartingBal">
1000
</eg:factX>
<xbrli:context id="c1">
<xbrli:entity>
<xbrli:segment>
<xbrldi:explicitMember dimension="eg:FYdim">
eg:currentYrQ1
</xbrldi:explicitMember>
</xbrli:segment>
</xbrli:entity>
</xbrli:context>
<!-- ... -->
<eg:factX contextRef="c1">
1000
</eg:factX>

Example 13: Location aspect documents instance fact attribute changed to explicit dimension aspect

Aspect Example
<veria:aspectModelChange>
<veria:fromAspects>
<veria:concept href="fromDTS.xsd#factX"/>
<veria:location>
starts-with(@contextRef, 'currentYrQ1')
</veria:location>
</veria:fromAspects>
<veria:toAspects>
<veria:concept href="toDTS.xsd#factX"/>
<veria:explicitDimension href="toDTS.xsd#FYdim">
<veria:member href="toDTS.xsd#currentYrQ1"/>
</veria:explicitDimension>
</veria:toAspects>
</veria:aspectModelChange>
The aspect model change for identifying fiscal quarter from starting letters of context ID to a dimension member.

Appendix A Document history (non-normative)

DateAuthorDetails
23 March 2010Herm Fischer

First draft.

12 April 2010Herm Fischer

Added Australian SBR tuple fromDTS to dimension toDTS example. Replaced GL example with one from GL Working Group based on IFRS dimensional taxonomy.

28 May 2010Herm Fischer

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, which allows DTS authors to document changes to base sets and dimensional relationship sets of concept-to-concept relationships, which replaces use of the prior hypercube model for documenting extended link roles and their dimensional relationships. Added an example of location aspect used as an attribute predicate (instead of elements predicate as previously described) to accommodate an example where fiscal quarter was denoted by starting characters of the contextRef/contextId in fromDTS and by a dimension in the toDTS. 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.

06 June 2010Herm Fischer

Added paragraph under "relating models to actions" about use of a DTS model that maintain dimensions which is not the ordinary XBRL dimensions relationship set, such as the tables/axis/line items structure of US-GAAP in 2009.

26 June 2010Herm Fischer

Revised discussion under C.1 and Section 5.5 about the need to report actions against dimensional XBRL semantic representations even when maintaining dimensions by alternate models, such as the presentation linkbase tables/axis/line items structure of US-GAAP in 2009 and IFRS in 2010.

03 July 2010Herm Fischer

Typos noted by Roland Hommes have been fixed, including adding Example 8 and Section 5.6.3.

10 July 2010Herm Fischer

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

18 July 2010Herm Fischer

Addition of concept basic events per feedback by Suguru Washio and editorial corrections per feedback by Huan Wang.

28 September 2010Herm Fischer

Adapted from a dimensions-overview to an über-overview for all modules.

Added figures and overview of terms for Section 2.

Added overview sections for versioning report of base module and concept modules, Section 3 and Section 4.

Removed dimensional use cases section in creating new use-cases document on this date.

Appendix B 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 03 November 2010. 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.

Appendix C History of Dimensional Versioning

The purpose of the original dimensions module was to represent semantics of the dimensions of a reported fact, in contrast to the syntax by which dimensional validity specifications are serialized in linkbases. The early versions began by representing a complete model of all valid dimension values. This rapidly became a hugely complex model, where half dozen and more dimensions, some having tens of thousands of values each, or even seemingly unlimited combinations possible with open positive hypercubes or isolated closed negative hypercubes. Different techniques of modeling sparse graphs were also attempted, but would require great labor to specify such full graphs.

Despite worry of model size, the key unfulfilled issue of prior approaches was in representing the notion of aspect differences, such that facts identified in one version by multiple concept names, segment XML elements, or tuple sibling values, that are identified in another version by shared concepts and combinations of dimension values. This led to the suggestion at CEBS in Vienna, for the current approach adapted from the formula specification, that of a generalized model of documenting differences in terms of the aspects of a business fact, and minimalizing reported difference information to that needed to guide an XBRL-aware processor to information already present in loaded DTS models, but not to reproduce fully the details already available to an XBRL-aware processor.

C.1 Evolution in Dimensional Maintenance

[Herm Fischer: Clarification per WG discussion 2010-06-22, please review this subsection:]

The current approach to documenting of dimensions aspects is based on a tacit assumption that dimensional features of taxonomies are edited and maintained manually, and that assignments and work actions can be associated with dimensional semantics. However the current DTS architectures, such as post-2009 US-GAAP and IFRSes, utilize canonical presentational linkbase relationships of concepts to model tables, axes (representing taxonomy hypercubes), domains and domain members, and line items (representing dimensional primary items). These presentational relationships may be the canonical model and the point of maintenance of the DTS, and the maintainers may use an automated process to generate dimensional relationships from the canonical presentational model. (The use of presentation may evolve to use of generic linkbases. Also it is known that some projects maintain canonical models in non-XBRL media, such as relational databases, and use them to generate the taxonomies.)

Dimensions (or any other XBRL feature or artifact) may be an result of some tool that generates them from a canonical form. The versioning report MUST document the business and tasking decisions according to the dimensions aspects that represent XBRL semantics, instead of relating them to the taxonomy or non-XBRL artifacts actually maintained by tools or process steps. (In this example, the presentational linkbase relationships MAY also have versioning actions reported, but if so they are not semantic to the identification of business facts or the maintenance of instance document mapping information.) Examples are to be provided, in this overview, for this situation.

[Herm Fischer: This same point is repeated from a different perspective, under "Relating Models to Actions", and needs editing to not bore the reader but express the dimensional evolution here and the relating models to actions situation there.]