Overview of Versioning 1.0

Working Group Note 15 August 2012

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

This version:
<http://www.xbrl.org/WGN/versioning-overview/WGN-2012-08-15/versioning-overview-WGN-WGN-2012-08-15.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, CoreFiling <pdw@corefiling.com>
Huan Wang, Fujitsu Ltd. <wang.huan@jp.fujitsu.com>
Suguru Washio, Fujitsu Ltd. <wasio@jp.fujitsu.com>
Warwick Foster, SBR Australia <warwick.foster@ato.gov.au>
Hugh Wallis, Standard Dimensions <hugh@standarddimensions.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, in particular those modules related to Dimensional versioning. It provides an introduction to the terms, features, and basic examples of XBRL Versioning. These are demonstrated with diagrams and XML examples.

Comments

1 Roland Hommes:Do we support exclusions on typed dimensions?
2 Roland Hommes:This figure is a duplicate and does not fit the example. Need to create 'typed-dim-without-value' example png.
3 Roland Hommes:There is only no way for XBRL processors to check on these allowed combinations.

Table of Contents

1 Introduction
2 Key Terms
3 Versioning report and base module events
4 Versioning concept events
5 When is an XBRL concept is Available For Use – Concept Delete event
5.1 Resulting report
5.2 Physical Deletion
5.2.1 Old
5.2.2 New
5.3 Logical Deletion
5.3.1 Old
5.3.2 Excel File published on Website
5.3.3 New
5.4 Deprecation
5.4.1 Old Schema
5.4.2 Old LinkBase
5.4.3 New Schema
5.4.4 New Linkbase
6 Versioning relationship-set and dimensions events
6.1 Relationship set model
6.2 Aspect model and aspects
6.3 Aspect-equivalent facts
6.4 Detail in models - minimalisation
6.5 Relating models to actions
6.6 Aspects
6.6.1 Explicit dimension aspect
6.6.2 Typed dimension aspect
6.6.3 Location aspect

Appendices

A Document history (non-normative)
B References
C Errata corrections in this document
D History of Dimensional Versioning
D.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 dimension modules
5 Section of Excel File

Examples

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


1 Introduction

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

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

This overview will orientate 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 the various modular specifications.

A separte document provides use cases that correspond to the Versioning Requirements.

The modular specifications follow a progression, as reflected in the diagrams, of increasingly complex nuanced versioning semantics, from base, concept use, concept details, to relationship sets and dimensional aspects. These versioning reports allow the user to identify the objects of the change activity: DTSs, concepts, concept attributes and features, relationship sets, and dimensional fact identification aspects.

2 Key Terms

The terms used in versioning modules that will be covered by this overview are shown in Figure 1. These are grouped 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, a black-box view of Versioning Report terms is shown in Figure 2.

Figure 2: Terms relating to inputs and outputs

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

and then DTSs and XBRL Instances which are referenced by the Versioning Report:

A versioning report does not physically incorporate any of these referenced inputs (DTS or XBRL instances) as part of the 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 it is desirable to have access to the referenced DTSs (and examples of instances for dimensional instance aspect 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 dimension modules are shown in Figure 4.

Figure 4: Terms relating to models of relationship-sets and dimension 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.

The relationship set versioning module supports the relationsip sets model including the dimensional relations. These relations DO NOT represent an aspect as defined for the aspect model. E.g. any relationship using a notAll arcrole could never end up in the instance but is covered by relationship set versioning module. The dimensions versioning module supports the aspects on fact items to the level of dimensional relevancy. E.g. the unit aspect is not covered, but Explicit and Typed dimension aspects are. Segment and scenario aspects are NOT covered by the dimensions versioning module.

3 Versioning report and base module events

Example 1 shows the contents of a report that 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 DTSs, an <assignment> of technicalCategory, and a single <action> that references the assignment and has one <event> , which is a namespaceRename event.

Example 1: Report organisation 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:vertp
="http://xbrl.org/2010/versioning-tuples"

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

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

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

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

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

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

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

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

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

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

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

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 that 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. It shows only the resource that has survived 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 organisation with concept change events

<report
xmlns:vercd
="http://xbrl.org/2010/versioning-concept-details"

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

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

xmlns:dts
="http://www.xbrl.org/versioning/testcases"

xmlns:vercu
="http://xbrl.org/2010/versioning-concept-use"

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>
<vercu:conceptRename>
<vercu:fromConcept name="dts:DebtOutstanding"/>
<vercu:toConcept name="dts:otalDebt"/>
</vercu:conceptRename>
<vercd:conceptIDChange>
<vercu:fromConcept name="dts:DebtOutstanding"/>
<vercu:toConcept name="dts:TotalDebt"/>
</vercd:conceptIDChange>
<vercd:conceptLabelChange>
<vercu:fromConcept name="dts:DebtOutstanding"/>
<vercd:fromResource value="../fromDTS-lbl.xml#label_DebtOutstanding"/>
<vercu:toConcept name="dts:TotalDebt"/>
<vercd:toResource value="../toDTS-lbl.xml#label_TotalDebt"/>
</vercd:conceptLabelChange>
</action>
</report>

5 When is an XBRL concept is Available For Use – Concept Delete event

A versioning report is presented at a business level. This may result in conceptual changes that are not reflected by an actual change in a taxonomy.

The Concept Delete event is a prime example of this. The basic use of the Concept Delete event is to communicate that a concept is no longer valid to be used. This may mean that it has been physically deleted from the taxonomy or that it still exists but no longer has a valid business use.

A taxonomy administrator could embed status information in the taxonomy stating that the concept is not to be used. This could be used to mark the concept for future possible use or future possible deletion in subsequent releases. Through this the taxonomy is able to be broader than the current usage.

The Delete Concept communicates the business usability of a concept. The following sections will demonstrate the same Versioning Report resulting from three different methods of implementing the logical delete.

5.1 Resulting report

Example 4: Delete Concept Report Example

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

xmlns:vertp
="http://xbrl.org/2010/versioning-tuples"

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

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

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

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

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

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

xmlns:vercu
="http://xbrl.org/2010/versioning-concept-use"

xmlns:prs-09
="http://prs.example.com/xbrl/2009"

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

xmlns:verrels
="http://xbrl.org/2010/versioning-relationship-sets"

xmlns
="http://xbrl.org/2010/versioning-base"
xsi:schemaLocation="http://xbrl.org/2010/versioning-base ..\schemas\versioning-base.xsd http://xbrl.org/2010/versioning-concept-use ..\Schemas\versioning-concept-use.xsd">
<link:linkbaseRef xlink:type="simple" xlink:href="labels.xml" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"/>
<fromDTS>
<link:schemaRef xlink:type="simple" xlink:href="PincusRevenueService-2009.xsd"/>
</fromDTS>
<toDTS>
<link:schemaRef xlink:type="simple" xlink:href="PincusRevenueService-2010.xsd"/>
</toDTS>
<assignment id="asmt-2010-final-budget-update">
<businessCategory/>
</assignment>
<action id="act-2010-statutory-changes">
<assignmentRef ref="asmt-2010-final-budget-update"/>
<vercu:conceptDelete id="evt-2010-ForeignCurrency-deletion">
<vercu:fromConcept name="prs-09:dts_ForeignCurrency"/>
</vercu:conceptDelete>
</action>
</report>

5.2 Physical Deletion

In this first example the concept is physically removed from the taxonomy between the first version and the next.

5.2.1 Old

Example 5: Delete Concept Report Example - Physical Deletion

<schema
xmlns
="http://www.w3.org/2001/XMLSchema"

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

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

xmlns:prs
="http://prs.example.com/xbrl/2010"
targetNamespace="http://prs.example.com/xbrl/2010" elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/>
<element name="Revenue" id="dts_Revenue" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Payroll" id="dts_Payroll" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="ForeignCurrency" id="dts_ForeignCurrency" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Capital" id="dts_Capital" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="TotalDebt" id="dts_TotalDebt" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
</schema>

5.2.2 New

<schema
xmlns
="http://www.w3.org/2001/XMLSchema"

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

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

xmlns:prs
="http://prs.example.com/xbrl/2010"
targetNamespace="http://prs.example.com/xbrl/2010" elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/>
<element name="Revenue" id="dts_Revenue" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Payroll" id="dts_Payroll" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<!-- Physically Removed -->
<element name="Capital" id="dts_Capital" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="TotalDebt" id="dts_TotalDebt" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
</schema>

5.3 Logical Deletion

Using an Excel worksheet published alongside the taxonomy the Administrators are able to convey the changed status of a concept in a taxonomy.

5.3.1 Old

Example 6: Delete Concept Report Example - Logical Deletion

<schema
xmlns
="http://www.w3.org/2001/XMLSchema"

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

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

xmlns:prs
="http://prs.example.com/xbrl/2010"
targetNamespace="http://prs.example.com/xbrl/2010" elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/>
<element name="Revenue" id="dts_Revenue" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Payroll" id="dts_Payroll" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="ForeignCurrency" id="dts_ForeignCurrency" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Capital" id="dts_Capital" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="TotalDebt" id="dts_TotalDebt" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
</schema>

5.3.2 Excel File published on Website

Figure 5: Section of Excel File

5.3.3 New

Example 7: Delete Concept Report Example - Deprecate 1

<schema
xmlns
="http://www.w3.org/2001/XMLSchema"

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

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

xmlns:prs
="http://prs.example.com/xbrl/2010"
targetNamespace="http://prs.example.com/xbrl/2010" elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/>
<element name="Revenue" id="dts_Revenue" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Payroll" id="dts_Payroll" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="ForeignCurrency" id="dts_ForeignCurrency" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Capital" id="dts_Capital" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="TotalDebt" id="dts_TotalDebt" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
</schema>

5.4 Deprecation

Using a linkbase label dataElementStatus provides the facility to state in the taxonomy that the concept does exist but is not valid for use.

5.4.1 Old Schema

Example 8: Delete Concept Report Example - Deprecate 2

<schema
xmlns:prs
="http://prs.example.com/xbrl/2009"

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

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

xmlns:xlink
="http://www.w3.org/1999/xlink"
targetNamespace="http://prs.example.com/xbrl/2009" attributeFormDefault="unqualified" elementFormDefault="qualified">
<annotation>
<appinfo>
<link:linkbaseRef xlink:type="simple" xlink:href="DcExcOld-label.xml" xlink:role="http://www.xbrl.org/2003/role/labelLinkbaseRef" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"/>
<link:roleType roleURI="http://dataElementStatus" id="dataElementStatus">
<link:definition>
Data Element Status
</link:definition>
<link:usedOn>
link:label
</link:usedOn>
</link:roleType>
</appinfo>
</annotation>
<import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/>
<element name="Revenue" id="dts_Revenue" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Payroll" id="dts_Payroll" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="ForeignCurrency" id="dts_ForeignCurrency" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Capital" id="dts_Capital" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="TotalDebt" id="dts_TotalDebt" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
</schema>

5.4.2 Old LinkBase

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

xmlns:vertp
="http://xbrl.org/2010/versioning-tuples"

xmlns:prs
="http://prs.example.com/xbrl/2009"

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

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

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

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

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

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

xmlns
="http://xbrl.org/specification/2007"

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

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

xmlns:verrels
="http://xbrl.org/2010/versioning-relationship-sets"
xsi:schemaLocation="http://www.xbrl.org/2003/linkbase http://www.xbrl.org/2003/xbrl-linkbase-2003-12-31.xsd">
<link:roleRef roleURI="http://dataElementStatus" xlink:type="simple" xlink:href="DcExccOld.xsd#dataElementStatus"/>
</link:linkbase>

5.4.3 New Schema

<schema
xmlns
="http://www.w3.org/2001/XMLSchema"

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

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

xmlns:prs
="http://prs.example.com/xbrl/2010"
targetNamespace="http://prs.example.com/xbrl/2010" attributeFormDefault="unqualified" elementFormDefault="qualified">
<annotation>
<appinfo>
<link:linkbaseRef xlink:type="simple" xlink:href="DcExcNew-label.xml" xlink:role="http://www.xbrl.org/2003/role/labelLinkbaseRef" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"/>
<link:roleType roleURI="http://dataElementStatus" id="dataElementStatus">
<link:definition>
Data Element Status
</link:definition>
<link:usedOn>
link:label
</link:usedOn>
</link:roleType>
</appinfo>
</annotation>
<import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/>
<element name="Revenue" id="dts_Revenue" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Payroll" id="dts_Payroll" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="ForeignCurrency" id="dts_ForeignCurrency" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="Capital" id="dts_Capital" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
<element name="TotalDebt" id="dts_TotalDebt" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" xbrli:periodType="instant"/>
</schema>

5.4.4 New Linkbase

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

xmlns:vertp
="http://xbrl.org/2010/versioning-tuples"

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

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

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

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

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

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

xmlns
="http://xbrl.org/specification/2007"

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

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

xmlns:verrels
="http://xbrl.org/2010/versioning-relationship-sets"
xsi:schemaLocation="http://www.xbrl.org/2003/linkbase http://www.xbrl.org/2003/xbrl-linkbase-2003-12-31.xsd">
<link:roleRef roleURI="http://dataElementStatus" xlink:type="simple" xlink:href="DcExcNew.xsd#dataElementStatus"/>
<link:labelLink xlink:type="extended" xlink:role="http://www.xbrl.org/2003/role/link">
<link:loc xlink:type="locator" xlink:href="DcExcNew.xsd#dts_ForeignCurrency" xlink:label="ForeignCurrency" xlink:title="ForeignCurrency"/>
<link:label xlink:type="resource" xlink:label="label_ForeignCurrency" xlink:role="http://dataElementStatus" xlink:title="label_ForeignCurrency" xml:lang="en" id="label_ForeignCurrency">
This element has been deprecated
</link:label>
<link:labelArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/concept-label" xlink:from="ForeignCurrency" xlink:to="label_ForeignCurrency" xlink:title="label: ForeignCurrency to label_ForeignCurrency"/>
</link:labelLink>
</link:linkbase>

6 Versioning relationship-set and dimensions events

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

6.1 Relationship set model

A relationship set model is a model of the relationships and their construction from 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, by prohibition, and by 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 the dimension default relationship is explicitly modelled in the relationship set, and not as an aspect in the instance.

6.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.

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

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

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

6.4 Detail in models - minimalisation

The versioning report is meant to document change, but not to reproduce the detail in the DTS. Granularity is documented at the level of what was affected, sufficiently to be unambiguous. However, the versioning report does not require providing a complete difference 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 for specific parts of the model. In general, it may be sufficient to have a single action identifying the dimensions as a dimensional relationship set being introduced, and leave the full detail of the model to an XBRL processor.

A contrasting 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 may 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 versioning report in this situation because the change is at the detailed level of the dimensional consecutive relationship sets.

6.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 have only relationship set models
    • Actions that define facts aspect modelling changes
      • These actions may represent only 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 annual 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 (i.e., integrates) aspect and relationship set model changes

Current DTS architectures for financial reporting model and maintain structural and dimensional aspects in a model independent of the XBRL dimensions located in the definition linkbase. For example, a presentation linkbase may specify and be the focus 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, documents 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 that are used in such an environment would benefit from a 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.

6.6 Aspects

6.6.1 Explicit dimension aspect

An explicit dimension aspect, as used in aspect models, represents the presence or exclusion of a (member)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 specifying unvalidated open dimensions.) This section will focus on the explicit dimension element as used for aspect modelling of specified dimensions (not of open unspecified dimensions).

In a versioning report: 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 9: Explicit dimension concept without member details

Aspect Example
<verdim:concept name="dts1:A"/>
<verdim:concept name="dts1:B"/>
<verdim:concept name="dts1:C"/>
<verdim:explicitDimension name="dts:Dimension1"/>
The concepts A, B, and C are reported with Dimension1 values.

Further specific information may be provided by the member element(s). Specifying member(s) is relevant when a version report identifies further (textual) details on the change. When member(s) are specified only those member(s) value pertains to the reported change.

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

Concept Hierarchy Dimension
TotalPPEGross (none)
PPEMachinesGross (none)

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

Concept Dimension 'PPEAxis'
PPEGross Total member (default)
PPEGross Machines 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 member, though being default, is expressed explicitly in the aspects model, because it is semantically present, even if it doesn't need to appear in an instance.

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. They MAY be reported as relationship changes.

Example 10: Explicit dimension replaces concept hierarchy

Aspect Example
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concept name="fromDTS:TotalPPEGross"/>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concept name="toDTS:PPEGross"/>
<verdim:explicitDimension name="toDTS:PPEAxis">
<verdim:member name="toDTS:TotalMember"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim:aspectModelChange>
The aspect model change for the TotalPPEGross concept, which is in toDTS instances, is represented by the concept PPEGross with the TotalMember dimension member.
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concept name="fromDTS:PPEMachinesGross"/>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concept name="toDTS:PPEGross"/>
<verdim:explicitDimension name="toDTS:PPEAxis">
<verdim:member name="toDTS:MachinesMember"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim:aspectModelChange>
The aspect model change for PPEMachinesGross concept, which is 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 fromName="toDTS.xsd#PPEGross" toName="toDTS.xsd#PPETable" axis="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.
<vercu:conceptDelete>
<vercu:fromConcept name="fromDTS:TotalPPEGross"/>
</vercu:conceptDelete>
<vercu:conceptDelete>
<vercu:fromConcept name="fromDTS:PPEMachinesGross"/>
</vercu:conceptDelete>

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

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

Another accepted solution MAY have been to introduce the conceptRename event for the TotalPPEGross concept, renaming it to PPEGross in the toDTS, pending the definitions on both concepts.

<vercu:conceptAdd>
<vercu:toConcept name="toDTS:PPETable"/>
</vercu:conceptAdd>
<vercu:conceptAdd>
<vercu:toConcept name="toDTS:PPEAxis"/>
</vercu:conceptAdd>
<vercu:conceptAdd>
<vercu:toConcept name="toDTS:TotalMember"/>
</vercu:conceptAdd>
<vercu:conceptAdd>
<vercu:toConcept name="toDTS:MachinesMember"/>
</vercu:conceptAdd>
<vercu:conceptAdd>
<vercu:toConcept name="toDTS:PPEGross"/>
</vercu:conceptAdd>

This table row shows concept basic events for the concepts used to construct the dimensional relationships, even though these concepts are not all business concepts. The remainder of examples in this document will 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. The business concept PPEGross is also introduced.

An alternative 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 can be discovered by an XBRL processor. In this case the hypercube element has linkrole, a closed and contextElement attribute, a primaryItem element is provided, and dimension domain relationships to the dimension members are provided with an usable attribute.

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

Example 11: 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 fromName="toDTS.xsd#PPEGross" toName="toDTS.xsd#PPETable" axis="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 fromName="toDTS.xsd#PPETable" toName="toDTS.xsd#PPEAxis" axis="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-default">
<verrels:relationships fromName="toDTS.xsd#PPEAxis" toName="toDTS.xsd#TotalMember" axis="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 fromName="toDTS.xsd#PPEAxis" toName="toDTS.xsd#TotalMember" axis="self" xbrldt:usable="true"/>
</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 fromName="toDTS.xsd#PPEAxis" toName="toDTS.xsd#MachinesMember" axis="self" xbrldt:usable="true"/>
</verrels:relationshipSet>
</verrels:toRelationshipSet>
</verrels:relationshipSetModelAdd>
As the toDTS has a dimension which, for this example, did not exist in the fromDTS, there are individual relationship model events to document that the hypercube is added to the primary item, the dimension to the hypercube, total member and machines member to the dimension. 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 12: Explicit dimension applied to a primary item concept hierarchy

Aspect Example
<verdim:aspectModelAdd>
<verdim:toAspects>
<verdim:concepts>
<verdim:concept name="toDTS:PriItemA">
<verdim:drsNetwork axis="descendant-or-self" linkrole="http://abc.com/pri-item-linkrole"/>
</verdim:concept>
</verdim:concepts>
<verdim:explicitDimension name="toDTS:NewAxis"/>
</verdim:toAspects>
</verdim:aspectModelAdd>
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.

6.6.2 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.

[Roland Hommes: Do we support exclusions on typed dimensions?]

When a 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 13: Typed dimension concept without value details

[Roland Hommes: This figure is a duplicate and does not fit the example. Need to create 'typed-dim-without-value' example png.]

Aspect Example
<verdim:concepts>
<verdim:concept name="dts:A"/>
<verdim:concept name="dts:B"/>
<verdim:concept name="dts:C"/>
</verdim:concepts>
<verdim:typedDimension name="dts: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.

[Roland Hommes: There is only no way for XBRL processors to check on these allowed combinations.]

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

Example 14: Typed dimension value mapping change

Aspect Example
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concepts>
<verdim:concept name="fromDTS:PriItemA"/>
</verdim:concepts>
<verdim:typedDimension
xmlns:abcdim
="http://www.abc.com/abcOldDim"
name="fromDTS:Dimension1">
<abcdim:oldElt oldAttr="1">
oldVal
</abcdim:oldElt>
</verdim:typedDimension>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concepts>
<verdim:concept name="toDTS:PriItemA"/>
</verdim:concepts>
<verdim:typedDimension
xmlns:abcdim
="http://www.abc.com/abcNewDim"
name="toDTS:Dimension1">
<abcdim:newElt newAttr="1">
newVal
</abcdim:newElt>
</verdim:typedDimension>
</verdim:toAspects>
</verdim: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.

6.6.3 Location aspect

The location aspect provides a predicate expression, in XPath, to identify a fact by its location from 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.

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 losing 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 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 15: 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 fromName="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.
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concept name="abc:TaxFilingNumber"/>
<verdim:concept name="abc:PersonBirthDate"/>
<verdim:concept name="abc:EmployeePayrollNumber"/>
<verdim:concept name="abc:PaymentTerminationCode"/>
<vertp:location>
<vertp:xpath>
../../abc:PayeeDetails/abc:TaxFilingNumber
</vertp:xpath>
</vertp:location>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concept name="abc:TaxFilingNumber"/>
<verdim:concept name="abc:PersonBirthDate"/>
<verdim:concept name="abc:EmployeePayrollNumber"/>
<verdim:concept name="abc:PaymentTerminationCode"/>
<verdim:explicitDimension name="abc:ReportPartyTypeDimension">
<verdim:member name="abc:ReportingParty"/>
</verdim:explicitDimension>
<vertp:location>
<vertp:xpath>
../../abc:Payee/abc:TaxFilingNumber
</vertp:xpath>
</vertp:location>
</verdim:toAspects>
</verdim: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.
<verdim:fromAspects>
<verdim:concept name="abc:SignatureDate"/>
<verdim:concept name="abc:DeclarationHardcopyIndicator"/>
<vertp:location>
<vertp:xpath>
../../abc:PayeeDetails/abc:TaxFilingNumber
</vertp:xpath>
</vertp:location>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concept name="abc:StatementType"/>
<verdim:concept name="abc:AcceptanceIndicator"/>
<verdim:concept name="abc:SignatureDate"/>
<verdim:explicitDimension name="abc:ReportPartyTypeDimension">
<verdim:member name="abc:ReportingParty"/>
</verdim:explicitDimension>
<vertp:location>
<vertp:xpath>
../../../abc:Payee[abc:Declaration and abc:TaxFilingNumber]
</vertp:xpath>
</vertp:location>
</verdim: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 the following 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 dimensions. The prefix gl is used arbitrarily for the fromDTS, and fr for the toDTS.

This example differs from the country business reporting taxonomy above 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 16: Location aspect non-dimensional global ledger architecture mapped to financial reporting dimensional concepts

Aspect Example
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concept name="fromDTS:amount"/>
<vertp:location>
<vertp:xpath>
../gl:account/gl:accountMainId = ‘3000’
</vertp:xpath>
</vertp:location>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concept name="toDTS:IncreaseDecreaseThroughChangesInAccountingPolicies"/>
<verdim:explicitDimension name="toDTS:ComponentsOfEquityAxis">
<verdim:member name="toDTS:IssuedCapitalMember"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim:aspectModelChange>
The aspect model change for amount with nephew account 3000 to ifrs:IncreaseDecrease­ThroughChanges­InAccountingPolicies with dimension ComponentsOfEquityAxis, member IssuedCapitalMember.
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concept name="fromDTS:amount"/>
<vertp:location>
<vertp:xpath>
../gl:account/gl:accountMainId = ‘4000’
</vertp:xpath>
</vertp:location>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concept name="toDTS:IncreaseDecreaseThroughCorrectionsOfErrors"/>
<verdim:explicitDimension name="toDTS:ComponentsOfEquityAxis">
<verdim:member name="toDTS:SharePremiumMember"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim:aspectModelChange>
The aspect model change for amount with nephew account 4000 to ifrs:IncreaseDecrease­Through­CorrectionsOfErrors with dimension ComponentsOfEquityAxis, member SharePremiumMember.
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concept name="fromDTS:amount"/>
<vertp:location>
<vertp:xpath>
../gl:account/gl:accountMainId = ‘5000’
</vertp:xpath>
</vertp:location>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concept name="toDTS:IncreaseDecreaseThroughOtherContributionsByOwners"/>
<verdim:explicitDimension name="toDTS:ComponentsOfEquityAxis">
<verdim:member name="toDTS:TreasurySharesMember"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim:aspectModelChange>
The aspect model change for amount with nephew account 5000 to ifrs:IncreaseDecrease­ThroughOther­ContributionsByOwners with dimension ComponentsOfEquityAxis, member TreasurySharesMember.
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concept name="fromDTS:amount"/>
<vertp:location>
<vertp:xpath>
../gl:account/gl:accountMainId = ‘6000’
</vertp:xpath>
</vertp:location>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concept name="toDTS:DividendsPaid"/>
<verdim:explicitDimension name="toDTS:ComponentsOfEquityAxis">
<verdim:member name="toDTS:OtherEquityInterestMember"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim: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 17: Location aspect documents instance fact attribute changed to explicit dimension aspect

Aspect Example
<verdim:aspectModelChange>
<verdim:fromAspects>
<verdim:concept name="fromDTS:factX"/>
<vertp:location>
<vertp:xpath>
starts-with(@contextRef, 'currentYrQ1')
</vertp:xpath>
</vertp:location>
</verdim:fromAspects>
<verdim:toAspects>
<verdim:concept name="toDTS:factX"/>
<verdim:explicitDimension name="toDTS:FYdim">
<verdim:member name="toDTS:currentYrQ1"/>
</verdim:explicitDimension>
</verdim:toAspects>
</verdim: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 D.1 and Section 6.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 12 and Section 6.6.2.

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.

01 February 2011Warwick Foster

Addition of concept delete section by Huan Wang.

12 October 2011Hugh Wallis

Overall review and tidy. Editorial changes for grammar etc. Ensure dimensional versioning is comprehensively described.

15 March 2012

Updated to current format for identifying to/from concepts.

20 March 2012

Removed implication that toDTS could be "virtual". Various stylistic changes.

27 April 2012

Updated namespaces and prefixes.

31 July 2012Roland Hommes

Changed to new naming of versioning modules, removed parts on non supported aspects.

Appendix B References

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)

Appendix C 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 15 August 2012. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.

Appendix D 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 serialised 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 a 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 modelling 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 generalised model of documenting differences in terms of the aspects of a business fact, and minimising 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.

D.1 Evolution in Dimensional Maintenance

The current approach to documenting 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, utilise 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 artefact) may be an result of some tool that generates them from a canonical form. The versioning report, however, documents the business and tasking decisions according to the dimensions aspects that represent XBRL semantics, instead of relating them to the taxonomy or non-XBRL artefacts actually maintained by tools or process steps. (In this example, the presentation 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.