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.
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.
The inputs can be divided into business orientated information, consisting of:
- Assignment: represents a set of actions and their category, such as business, technical, or errata.
- Action: represents a grouping of events that characterise the difference(s) between the from DTS and the to DTS (and their instances). (Assignments and actions may have a many-to-many relationship.
and then DTSs and XBRL Instances which are referenced by the Versioning Report:
- From DTS, To DTS: The prior and subsequent collections of taxonomies and linkbases that are discoverable from instances of the respective version.
- Instances: An instance of the respective DTS that may be characterised by common characteristics that are notedly different between the two versions and subject of 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:
- an XML document listing technical differences between the two subject DTSs (and the characteristics of their instances).
- Assignment: a group of actions related to a single business issue.
- Action: a single discrete change to a DTS or instance aspects model.
- Event: a single technical difference item.
- Linkbases: generic label linkbases containing prose descriptions to supplement the XML report. These are not related to ordinary XBRL DTS linkbases (e.g. presentation, concept label) .
The terms that relate to the versioning concept modules are shown in Figure 3.
- Related concepts: represents a set of concepts that are the subject of the same action and event. They are documented together, such as a set of from DTS concepts that are deleted and to DTS concepts that are added as part the same action.
- Equivalent concepts: represents a pair of concepts that are the subjects of a single concept rename event.
The terms that relate to the models of the relationship-sets and dimension modules are shown in Figure 4.
The key terms used in modelling are relationship sets model, aspect model, and aspect equivalent facts.
- Relationship sets model: a model for maintainers of a DTS. A relationship set may be either an XBRL Base Set or a Dimensional Relationship Set. These model respectively a network of arcs having common link and arc element names, link roles, and arc roles, or a Dimensional Relationship Set, wherein base set relationships allow specific consecutive relationships to traverse arc roles.
- Instance aspects model: The instance aspects model describes how information about a fact is split into aspects, each representing a characteristic of that fact. The aspect model supports documenting changes to the mapping information maintained by instance creators. The aspects of a fact item are:
- Concept aspect: represents a fact's defining concept
- Explicit dimension aspect: represents the dimension and member's value
- Typed dimension aspect: represents the dimension and XML fragments
- Segment aspects: represents non-dimensional XML fragments of a segment
- Scenario aspects: represents non-dimensional XML fragments of a scenario
- Entity-identifier aspect: represents information in the entity scheme and identifier value
- Period aspect: represents information in the period value
- Unit aspect: represents information in the unit element
- General aspect: an XPath predicate characterising any XML identification such as:
- existence or values of related tuple facts
- existence or values of XML attributes
- Aspect-equivalent facts: Facts that, when in different instances, have equivalent aspects according to the model of their instance
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.
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://xbrl.org/2010/versioning-base">
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".
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">
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.
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">
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
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">
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
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">
5.2.2 New
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">
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
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">
5.3.3 New
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">
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
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">
5.4.2 Old 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">
5.4.3 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" attributeFormDefault="unqualified" elementFormDefault="qualified">
5.4.4 New 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">
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.
| 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.
| Aspect | Example |
|---|---|
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:concept name="fromDTS:TotalPPEGross"/> </verdim:fromAspects><verdim:toAspects> </verdim:aspectModelChange><verdim:concept name="toDTS:PPEGross"/> <verdim:explicitDimension name="toDTS:PPEAxis"> </verdim:toAspects><verdim:member name="toDTS:TotalMember"/> </verdim:explicitDimension> |
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:aspectModelChange><verdim:concept name="toDTS:PPEGross"/> <verdim:explicitDimension name="toDTS:PPEAxis"> </verdim:toAspects><verdim:member name="toDTS:MachinesMember"/> </verdim:explicitDimension> |
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:relationshipSetModelAdd><verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/all"> </verrels:toRelationshipSet><verrels:relationships fromName="toDTS.xsd#PPEGross" toName="toDTS.xsd#PPETable" axis="descendant-or-self"/> </verrels:relationshipSet> |
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.
| Aspect | Example |
|---|---|
|
<verrels:relationshipSetModelAdd> <verrels:toRelationshipSet> </verrels:relationshipSetModelAdd><verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/all"> </verrels:toRelationshipSet><verrels:relationships fromName="toDTS.xsd#PPEGross" toName="toDTS.xsd#PPETable" axis="self" xbrldt:closed="true" xbrldt:contextElement="segment"/> </verrels:relationshipSet><verrels:relationshipSetModelAdd> <verrels:toRelationshipSet> </verrels:relationshipSetModelAdd><verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/hypercube-dimension"> </verrels:toRelationshipSet><verrels:relationships fromName="toDTS.xsd#PPETable" toName="toDTS.xsd#PPEAxis" axis="self"/> </verrels:relationshipSet><verrels:relationshipSetModelAdd> <verrels:toRelationshipSet> </verrels:relationshipSetModelAdd><verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/dimension-default"> </verrels:toRelationshipSet><verrels:relationships fromName="toDTS.xsd#PPEAxis" toName="toDTS.xsd#TotalMember" axis="self"/> </verrels:relationshipSet><verrels:relationshipSetModelAdd> <verrels:toRelationshipSet> </verrels:relationshipSetModelAdd><verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/dimension-domain"> </verrels:toRelationshipSet><verrels:relationships fromName="toDTS.xsd#PPEAxis" toName="toDTS.xsd#TotalMember" axis="self" xbrldt:usable="true"/> </verrels:relationshipSet><verrels:relationshipSetModelAdd>
<verrels:toRelationshipSet> </verrels:relationshipSetModelAdd><verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/dimension-domain"> </verrels:toRelationshipSet><verrels:relationships fromName="toDTS.xsd#PPEAxis" toName="toDTS.xsd#MachinesMember" axis="self" xbrldt:usable="true"/> </verrels:relationshipSet> |
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.
| Aspect | Example |
|---|---|
|
<verdim:aspectModelAdd>
<verdim:toAspects> </verdim:aspectModelAdd><verdim:concepts> <verdim:concept name="toDTS:PriItemA"> </verdim:concepts><verdim:drsNetwork axis="descendant-or-self" linkrole="http://abc.com/pri-item-linkrole"/> </verdim:concept><verdim:explicitDimension name="toDTS:NewAxis"/> </verdim:toAspects> |
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.
[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>.
| Aspect | Example |
|---|---|
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:concepts> <verdim:concept name="fromDTS:PriItemA"/> </verdim:concepts><verdim:typedDimension </verdim:fromAspects>xmlns:abcdim="http://www.abc.com/abcOldDim" name="fromDTS:Dimension1"> <abcdim:oldElt oldAttr="1"> </verdim:typedDimension>oldVal </abcdim:oldElt><verdim:toAspects> </verdim:aspectModelChange><verdim:concepts> <verdim:concept name="toDTS:PriItemA"/> </verdim:concepts><verdim:typedDimension </verdim:toAspects>xmlns:abcdim="http://www.abc.com/abcNewDim" name="toDTS:Dimension1"> <abcdim:newElt newAttr="1"> </verdim:typedDimension>newVal </abcdim:newElt> |
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).
| Aspect | Example |
|---|---|
|
<verrels:relationshipSetModelAdd>
<verrels:toRelationshipSet> </verrels:relationshipSetModelAdd><verrels:relationshipSet linkrole="http://example.gov/roles/defRole" arcrole="http://xbrl.org/int/dim/arcrole/all"> </verrels:toRelationshipSet><verrels:relationships fromName="current/toDTS.xsd#abc_ReportPartyTypeDimension"/> </verrels:relationshipSet> |
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> </verdim:fromAspects><vertp:xpath> </vertp:location>
../../abc:PayeeDetails/abc:TaxFilingNumber
</vertp:xpath><verdim:toAspects> </verdim:aspectModelChange><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> </verdim:toAspects><vertp:xpath> </vertp:location>
../../abc:Payee/abc:TaxFilingNumber
</vertp:xpath> |
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> </verdim:fromAspects><vertp:xpath> </vertp:location>
../../abc:PayeeDetails/abc:TaxFilingNumber
</vertp:xpath><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> </verdim:toAspects><vertp:xpath> </vertp:location>
../../../abc:Payee[abc:Declaration and abc:TaxFilingNumber]
</vertp:xpath> |
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).
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> </verdim:fromAspects><vertp:xpath> </vertp:location>
../gl:account/gl:accountMainId = ‘3000’
</vertp:xpath><verdim:toAspects> </verdim:aspectModelChange><verdim:concept name="toDTS:IncreaseDecreaseThroughChangesInAccountingPolicies"/> <verdim:explicitDimension name="toDTS:ComponentsOfEquityAxis"> </verdim:toAspects><verdim:member name="toDTS:IssuedCapitalMember"/> </verdim:explicitDimension> |
The aspect model change for amount with nephew account 3000 to ifrs:IncreaseDecreaseThroughChangesInAccountingPolicies with dimension ComponentsOfEquityAxis, member IssuedCapitalMember. |
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:concept name="fromDTS:amount"/> <vertp:location> </verdim:fromAspects><vertp:xpath> </vertp:location>
../gl:account/gl:accountMainId = ‘4000’
</vertp:xpath><verdim:toAspects> </verdim:aspectModelChange><verdim:concept name="toDTS:IncreaseDecreaseThroughCorrectionsOfErrors"/> <verdim:explicitDimension name="toDTS:ComponentsOfEquityAxis"> </verdim:toAspects><verdim:member name="toDTS:SharePremiumMember"/> </verdim:explicitDimension> |
The aspect model change for amount with nephew account 4000 to ifrs:IncreaseDecreaseThroughCorrectionsOfErrors with dimension ComponentsOfEquityAxis, member SharePremiumMember. |
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:concept name="fromDTS:amount"/> <vertp:location> </verdim:fromAspects><vertp:xpath> </vertp:location>
../gl:account/gl:accountMainId = ‘5000’
</vertp:xpath><verdim:toAspects> </verdim:aspectModelChange><verdim:concept name="toDTS:IncreaseDecreaseThroughOtherContributionsByOwners"/> <verdim:explicitDimension name="toDTS:ComponentsOfEquityAxis"> </verdim:toAspects><verdim:member name="toDTS:TreasurySharesMember"/> </verdim:explicitDimension> |
The aspect model change for amount with nephew account 5000 to ifrs:IncreaseDecreaseThroughOtherContributionsByOwners with dimension ComponentsOfEquityAxis, member TreasurySharesMember. |
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:concept name="fromDTS:amount"/> <vertp:location> </verdim:fromAspects><vertp:xpath> </vertp:location>
../gl:account/gl:accountMainId = ‘6000’
</vertp:xpath><verdim:toAspects> </verdim:aspectModelChange><verdim:concept name="toDTS:DividendsPaid"/> <verdim:explicitDimension name="toDTS:ComponentsOfEquityAxis"> </verdim:toAspects><verdim:member name="toDTS:OtherEquityInterestMember"/> </verdim:explicitDimension> |
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.
| Aspect | Example |
|---|---|
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:concept name="fromDTS:factX"/> <vertp:location> </verdim:fromAspects><vertp:xpath> </vertp:location>
starts-with(@contextRef, 'currentYrQ1')
</vertp:xpath><verdim:toAspects> </verdim:aspectModelChange><verdim:concept name="toDTS:factX"/> <verdim:explicitDimension name="toDTS:FYdim"> </verdim:toAspects><verdim:member name="toDTS:currentYrQ1"/> </verdim:explicitDimension> |
The aspect model change for identifying fiscal quarter from starting letters of context ID to a dimension member. |
