1 Introduction
Suggested background for this overview includes reading the Versioning Primer, knowledge of XBRL 2.1 in general, some familiarity of XBRL Dimensions, and some experience with XBRL Instances and their DTSes.
Versioning describes changes to the architecture of XBRL instances as represented by their DTSes, and how information is represented in features of the instances.
This overview will orient the project manager and architect into what can be captured by versioning, for either production or consumption of XBRL Versioning Reports, and will introduce the developer to the features and syntax that are normatively described by module specifications
A compendium provides use cases that correspond to the Versioning Requirements.
In terms of approaching the module specifications, there is a progression as reflected in the diagrams, of increasingly complex nuanced versioning semantics, from base, concept basic, concept extended, to relationship sets and instance aspects. These versioning reports allow us to identify the objects of the change activity: DTSes, concepts, concept attributes and features, relationship sets, and fact identification aspects.
2 Key Terms
The terms used in versioning modules, that will be covered by this overview, are show in in Figure 1. These are diagrammed by the sources from which the versioning report is produced, the from DTS and its instances, to DTS and its instances, differences of technical and semantic nature, and those terms that are introduced by module specifications for the versioning report.
Considering the artefacts referenced by a Versioning Report as inputs and the artefacts produced as part of that Versioning Report as outputs, we produce the black-box view of Versioning Report terms in Figure 2.
The inputs can be divided into business oriented 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 characterize 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 characterized by common characteristics that are notedly different between the two versions and subject of the Versioning Report.
A versioning report does not have any facility of physically incorporating any of these referenced inputs (DTS or XBRL instances) to become part of the versioning report, and a consuming report processor does not need them for basic processing of the report. However for a report consumer to follow the references and have access to schema definitions and relationship-sets makes it desirable to have access to the referenced DTSes (and examples of instances for instance aspect model changes).
The output Versioning Report consists of:
- an XML document of technical differences between the two subject DTSes (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 concepts that pertain to the same action and event, that are documented together, such as a set of from DTS concepts deleted and to DTS concepts added, together, by the same action.
- Equivalent concepts: represents a pair of concepts that are the subjects of the a single concept rename event.
The terms that relate to the models of the relationship-sets and instance aspects 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 aspects model describes how information about a fact is split into aspects, each representing a characteristic of a fact. The aspect model supports documenting changes to the mapping information maintained by instance creators. The aspect model also supports documenting changes of disallowed dimensional aspects. The aspects of a fact item are:
- Concept aspect: represents a fact's defining concept
- Explicit dimension aspect: the dimension and member's value
- Typed dimension aspect: the dimension and XML fragments
- Segment aspects: represent non-dimensional XML fragments of a segment
- Scenario aspects: represent non-dimensional XML fragments of a scenario
- Entity-identifier aspect: represent information in the entity scheme and identifier value
- Period aspect: represent information in the period value
- Unit aspect: represents information in the unit element
- General aspect: an XPath predicate characterizing 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 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.
3 Versioning report and base module events
Example
1 shows the contents of a report which
contains an example of a report element, a
<linkbaseRef>
to the generic linkbase
of annotational labels, the
<fromDTS>
and
<toDTS>
elements that specify
the files of the two DTSes, an
<assignment>
of technicalCategory,
and a single
<action>
which references the assignment and has
one
<event>
, a namespaceRename.
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:xbrli="http://www.xbrl.org/2003/instance"
xmlns:xbrldt="http://xbrl.org/2005/xbrldt"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:label="http://xbrl.org/2008/label"
xmlns:gen="http://xbrl.org/2008/generic"
xmlns="http://www.xbrl.org/2003/linkbase"
xmlns:ver="http://xbrl.org/2010/versioning-base"
xmlns:vercb="http://xbrl.org/2010/versioning-concept-base"
xmlns:verrels="http://xbrl.org/2010/versioning-relationship-sets" xsi:schemaLocation="http://xbrl.org/2008/generic http://www.xbrl.org/2008/gnl.xsd http://xbrl.org/2008/label http://www.xbrl.org/2008/generic-label.xsd">
4 Versioning concept events
Example
3 shows the contents of a report which
adds additional events to the prior example, to show typical changes for an action that
renames a concept. There are three related events as a result of the renaming,
<conceptRename>
for the change of the element's QName,
<conceptIDChange>
for the related change of the element's ID, and
<conceptLabelChange>
for the
label linkbase resource which changes with the renaming. The conceptLabelChange
identifies both the concept changed, and the label linkbase resource element of the effective
label (that surviving any linkbase prohibition and override activities). (If ineffective
labels were also changed, such as one of lesser priority than the effective label, they are
not reflected in the versioning report.)
xmlns:verce="http://xbrl.org/2010/versioning-concept-extended"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:vercb="http://xbrl.org/2010/versioning-concept-basic"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:dts="http://www.xbrl.org/versioning/testcases"
xmlns="http://xbrl.org/2010/versioning-base">
5 When is an XBRL concept is Available For Use – Concept Delete event
As discussed in previous sections 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. In the basic use of the event 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.
For example, if a taxonomy had a yearly release cycle there may not be an opportunity to redeploy the taxonomy to physically remove a concept that is no longer valid for use. The taxonomy administrators publish a list on their website which provides an ongoing statement of the validity of concepts in the taxonomy. With a versioning report based on this information the taxonomy administrator is able to communicate changes in the conceptual use of the taxonomy without the burden of new version.
Alternately the taxonomy administrator in a subsequent release could embed status information in the taxonomy stating that the concept is not to be used. This could be used to hold the place holder for the concept for a future possible use or future possible deletion. 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 deletion.
5.1 Resulting report
xmlns:veria="http://xbrl.org/2010/versioning-instance-aspects"
xmlns:xbrli="http://www.xbrl.org/2003/instance"
xmlns:xbrldt="http://xbrl.org/2005/xbrldt"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:vercb="http://xbrl.org/2010/versioning-concept-basic"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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-basic ..\Schemas\versioning-concept-basic.xsd">
5.2 Physical Deletion
In this first example the concept is physically removed from the taxonomy from the first version to the next.
5.2.1 Old
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:prs="http://prs.example.com/xbrl/2010" targetNamespace="http://prs.example.com/xbrl/2010" elementFormDefault="qualified" attributeFormDefault="unqualified">
5.2.2 New
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:prs="http://prs.example.com/xbrl/2010" targetNamespace="http://prs.example.com/xbrl/2010" elementFormDefault="qualified" attributeFormDefault="unqualified">
5.3 Logical Deletion
Using a Excel published along side the taxonomy the Administrators are able to convey the changed status of a concept in a taxonomy.
5.3.1 Old
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:prs="http://prs.example.com/xbrl/2010" targetNamespace="http://prs.example.com/xbrl/2010" elementFormDefault="qualified" attributeFormDefault="unqualified">
5.3.3 New
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2001/XMLSchema"
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 lable dataElementStatus the taxonomy has the facility to stated in the taxonomy that the concept does exist but should is not valid for use.
5.4.1 Old Schema
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:prs="http://prs.example.com/xbrl/2009" 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:xbrli="http://www.xbrl.org/2003/instance"
xmlns:xbrldt="http://xbrl.org/2005/xbrldt"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xbrl.org/specification/2007"
xmlns:ver="http://xbrl.org/2010/versioning-base"
xmlns:vercb="http://xbrl.org/2010/versioning-concept-base"
xmlns:verrels="http://xbrl.org/2010/versioning-relationship-sets"
xmlns:prs="http://prs.example.com/xbrl/2009" 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:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2001/XMLSchema"
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:xbrli="http://www.xbrl.org/2003/instance"
xmlns:xbrldt="http://xbrl.org/2005/xbrldt"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xbrl.org/specification/2007"
xmlns:ver="http://xbrl.org/2010/versioning-base"
xmlns:vercb="http://xbrl.org/2010/versioning-concept-base"
xmlns:verrels="http://xbrl.org/2010/versioning-relationship-sets" xsi:schemaLocation="http://www.xbrl.org/2003/linkbase http://www.xbrl.org/2003/xbrl-linkbase-2003-12-31.xsd">
6 Versioning relationship-set and instance-aspect model events
The events of relationship-set and instance-aspect modules are based on models. This section introduces the relationship-set and instance-aspect models, and provides an overview of their version reporting.
6.1 Relationship set model
A relationship set model is a model of the relationships and their construction by base sets and dimensional consecutive relationship sets. This model is the 'net' result of the base set arcs and dimension relationship sets that become allowed and disallowed by arc equivalence, prohibition, and following relationship axes and (for dimensions) consecutive relationships.
For dimensional DTS maintainers, the relationship model provides the means to document
link role and dimensional relationship set construction syntax, particularly syntax elements
not visible to the aspects model such as conceptElement, usable, and dimension default (note that
@isDimensionDefault is proposed for the explicit dimension member aspect of aspect models,
but may be explicitly modeled in the relationship set.
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.
For facts with dimensional aspects the model also may identify excluded values. This permits specifying which values (and combinations) are not allowed, by the model, to be represented on facts.
The aspect models of the Variables specification are intended to be extensible and customizable, with aspects currently defined for common dimensional and non-dimensional use cases. The following aspects are introduced in this overview by example, and are deemed relevant to expected dimensions module use cases:
- Concept aspect, representing a fact item's taxonomy concept
- Explicit dimension aspect, one per dimension of a fact item (including defaulted dimensions, irrespective of segment or scenario location)
- Typed dimension aspect, one per typed dimension of a fact item (irrespective of segment or scenario location).
- Segment aspects, representing non-dimensional XML fragments of a segment
- Scenario aspects, representing non-dimensional XML fragments of a scenario
- Entity-identifier aspect, representing information in the entity scheme and identifier value
- Period aspect, representing information in the period value
- Location aspect, a predicate representing companion fact existence, values of related tuple contents and fact or related element attribute existence or values
- Unit aspect, representing information in the unit
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 - minimalization
The version report is meant to document change, but not to reproduce the detail in the DTS. Granularity is documented at the level of what was effected, sufficiently to be unambiguous. However the version report does not require providing a complete diff listing of unambiguous details below what is identified by actions and labels. When omitted, such details are obtainable by an XBRL processor when the changed items to be compared are specifically identified.
An example is the introduction of a set of dimensions to primary items, with a graph or even a complex algebra of allowed members, expressed by definition linkbase in the respective DTS. It is possible to represent the complete semantics of allowed and disallowed dimensions in a relationship sets model, but that is not appropriate beyond the level at which versioning report actions identify specific parts of the model and labels provide attached documentation to specific parts of the model. In general, it may be sufficient to have a single action identifying the dimensions as a dimensional relationship sets being introduced, and leave the full detail of the model to an XBRL processor.
A counter example is when an existing dimensional model is updated to respond to change in some reporting law or business practice, such as to exclude certain dimensional member values from being reported in given situations. That might be expressed by notAll has hypercube relations in a definition linkbase, and as an identification of excluded member values for the aspect models that identify concept and dimension member exclusions. For DTS maintenance, the documentation of link role networks such as primary-item member values can be specified in a relationship sets model. The relationship sets detail of link role and member value may be needed for the version report in this situation because the change is at the detailed level of the dimensional consecutive relationship sets.
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 only have relationship set models
- Actions that define facts aspect modeling changes
- These actions may only represent aspect model changes, such as specific concept naming changes and their dimensional aspects (possibly with separate actions per schedule or extended link role represented)
- Regularly occurring tweaks, such as during year taxonomy updates
- Tax and credit laws change, business and accounting practices change
- Actions may be grouped per regulation and practice change
- In this case an action has both (integrates) aspect and relationship set model changes
Current DTS architectures for financial reporting, now model and maintain structural and dimensional aspects in a model independent of the XBRL dimensions located in the definition linkbase. For example, a presentational linkbase may specifies and be the locus to maintain such a model using concepts denoted as tables, that have axes, dimension members, and line items, instead of primary items that relate to hypercubes, dimensions, and so on, in the definition linkbase. The definition linkbase entries that specify XBRL dimensions to an XBRL processor may be generated programmatically from the presentation linkbase entries that specify tables, axes, and line items. The versioning report, in such a case, MUST document such actions against the generated dimension semantics as represented by the definition linkbase, and MAY also document actions that modify the canonical model (such as tables/axes/line items in the presentation linkbase).
It is not required to report events of the explicit dimensions model that relate to dimension members maintained (by some process or project) using the presentational member hierarchy expressed by a producer's canonical model (such as of presentation relationships in financial reporting taxonomy practices), or dimensional primary item maintenance by hierarchy changes to the presentational relationships of table line items in a financial reporting taxonomy model. Because of this, tools which are used in such an environment would benefit from a two-way reflection of the duality of canonical models and XBRL semantic relationships, such that versioning reports documenting XBRL dimensions semantics can be related by the supportive tool set to the equivalent alternate in the model used for maintenance.
6.6 Aspects
6.6.1 Concept aspect
A concept aspect is used in an aspect model to represent which specific concept is used to report the business fact of instance document item.
There would usually be one concept aspect for any single aspect model of fact identification. If multiple concept aspects are provided in an aspect model, they represent a set of alternative concept aspects that are grouped together. But it is not specified what the meaning would be of having groups of multiple concept aspects for a aspect model, such a situation is explained by an accompanying label. (For example the action may report that a set of concepts have some joint change, such as to adopt a dimension, but do not specify sufficient information for an instance document mapping tool to unambiguously know how to apply this information.)
The concept aspect may identify a hierarchy of concepts, specified by relationships, to apply collectively to the given aspect model. For example, this can be useful when a dimensional primary item hierarchy (or any other relational set hierarchy) applies in entirety to an aspect model.
| Aspect | Example |
|---|---|
|
<veria:concept href="dts1.xsd#A"/>
|
The concept aspect of this aspect model is the dts1.xsd element with ID A. |
|
<veria:concept href="dts1.xsd#A"/> <veria:concept href="dts1.xsd#B"/> <veria:concept href="dts1.xsd#C"/> <veria:concept href="dts1.xsd#D"/>
|
The concept aspect of this aspect model is the dts1.xsd element with ID A, B, C or D, but the specifics of reporting four alternative concepts for this aspect may be conveyed by a label on the aspect model, or possibly even separate labels on each concept aspect. For example, one might be reporting that A, B, C, and D have a new dimension applied in to-DTS instances. |
The concept aspect pertains only to fact items. If these items are located in tuples, and it is necessary to provide more specifics to identify a particular aspect model, then the location aspect is used. (For example, in GL instances, the "amount" concept aspect of an item is insufficient to identify which financial account the value applies to, without further specification of other members of its containing tuple.)
6.6.2 Explicit dimension aspect
An explicit dimension aspect, as used in an aspect models, represents the presence or exclusion of a value for a dimension in the aspect model for a fact item. This expresses the validity of that dimension when it is a specified dimension of closed hypercubes. (It is not relevant to specifying unvalidated open dimensions.) This section will focus on the explicit dimension element as used for aspect modeling of specified dimensions (not of open unspecified dimensions).
When an explicit dimension aspect is provided by itself without further details, it simply specifies that the complete dimension as defined in the DTS is being applied.
| Aspect | Example |
|---|---|
|
<veria:concept href="dts1.xsd#A"/> <veria:concept href="dts1.xsd#B"/> <veria:concept href="dts1.xsd#C"/> <veria:explicitDimension href="dts1.xsd#Dimension1"/>
|
The concepts A, B, and C are reported with Dimension1 values. |
Further specific information may be provided by the member element and optional axis element. Specifying member is relevant when a version report identifies further details in fact identification mapping. When a member is just identified by itself, without axis information, then only that member value pertains to the reported change.
In this example the fromDTS is non-dimensional, with a concept hierarchy to represent breakdown
| Concept Hierarchy | No Dimension |
|---|---|
| PPEGross | (none) |
| PPEMachinesGross | (none) |
and the toDTS is dimensional, with a shared concept and member hierarchy to represent breakdown
| Concept | Dimension |
|---|---|
| PPEGross | TotalGross member (default) |
| PPEGross | MachinesGross member |
Two aspect models are provided, one for the mapping of relevant aspects to identify facts of the PPEGross total dimension member, and one for the machines breakdown dimension member. Note that the total gross member, though being default, is expressed explicitly in the aspects model, because it is semantically present.
In addition, a minimalist relationship set model is provided, just for completeness of this example, to document that the PPEAxis dimension is present in the toDTS (and not in the fromDTS).
Concept basic events are shown in this example, and then omitted in the remainder of this document. Events are needed for concepts that are primary items in the toDTS and replace non-dimensional concepts in the fromDTS, because these concepts represent business concepts (e.g., that are the concept aspect of items in the instance document). These events are grouped as a related set of events (as the single dimensional primary item is related to multiple non-dimensional business concept facts).
Events are shown separately for the concepts that represent the hypercube, dimension, and dimension members. These are not business concepts by the definition in concept-basic, as they aren't an abstract definition of an individual piece of business information, and perhaps as such aren't as necessary to report.
| Aspect | Example |
|---|---|
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="fromDTS.xsd#PPEGross"/> </veria:fromAspects><veria:toAspects> </veria:aspectModelChange><veria:concept href="toDTS.xsd#PPEGross"/> <veria:explicitDimension href="toDTS.xsd#PPEAxis"> </veria:toAspects><veria:member href="toDTS.xsd#TotalGrossDomain"/> </veria:explicitDimension> |
The aspect model change for the PPEGross concept, which in toDTS instances, is represented by the same concept with the TotalGrossDomain dimension member. |
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="fromDTS.xsd#PPEMachinesGross"/> </veria:fromAspects><veria:toAspects> </veria:aspectModelChange><veria:concept href="toDTS.xsd#PPEGross"/> <veria:explicitDimension href="toDTS.xsd#PPEAxis"> </veria:toAspects><veria:member href="toDTS.xsd#MachinesMember"/> </veria:explicitDimension> |
The aspect model change for PPEMachinesGross concept, which in toDTS instances, is also represented by the PPEGross concept, but with the MachinesMember dimension member. |
|
<verrels:relationshipSetModelAdd>
<verrels:toRelationshipSet> </verrels:relationshipSetModelAdd><verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/all"> </verrels:toRelationshipSet><verrels:relationships fromHref="toDTS.xsd#PPEGross" toHref="toDTS.xsd#PPETable" DRSaxis="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. |
|
<vercb:conceptDelete>
<vercb:fromConcept value="fromDTS.xsd#PPEMachinesGross"/> </vercb:conceptDelete> |
This table row shows concept basic events for the primary items, but the remainder of examples in this document omit concept basic event examples. The business concept PPEMachinesGross is removed from the toDTS as the business concept it represented is now a dimensional primary item sharing the prior and remaining business concept, PPEGross. |
|
<vercb:conceptAdd> <vercb:toConcept value="toDTS.xsd#PPETable"/> </vercb:conceptAdd><vercb:conceptAdd> <vercb:toConcept value="toDTS.xsd#PPEAxis"/> </vercb:conceptAdd><vercb:conceptAdd> <vercb:toConcept value="toDTS.xsd#TotalGrossDomain"/> </vercb:conceptAdd><vercb:conceptAdd>
<vercb:toConcept value="toDTS.xsd#MachinesMember"/> </vercb:conceptAdd> |
This table row shows concept basic events for the concepts used to construct the dimensional relationships, even though these concepts are not business concepts. The remainder of examples in this document omit concept basic event examples. Non- business concepts are added to the toDTS to represent the hypercube (table), dimension (axis), domain (total member), and machines member. |
An alternate versioning report might provide the preceeding example events and in addition provide detailed relationship set events for the dimensional relationships that are unnecessary to specify because they are already known to an XBRL processor. In this case the hypercube element has linkrole, closed, and contextElement, a primaryItem element is provided, dimension domain and the dimension member are provided.
This is not recommended that a tool to generate such a report with such additional redundant semantics as output, but a validation report processing tool must accept such a report as an input element is provided, dimension domain and the dimension member are provided.
| 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 fromHref="toDTS.xsd#PPEGross" toHref="toDTS.xsd#PPETable" DRSaxis="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 fromHref="toDTS.xsd#PPETable" toHref="toDTS.xsd#PPEAxis" DRSaxis="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 fromHref="toDTS.xsd#PPEAxis" toHref="toDTS.xsd#TotalGrossDomain" DRSaxis="self"/> </verrels:relationshipSet><verrels:relationshipSetModelAdd>
<verrels:toRelationshipSet> </verrels:relationshipSetModelAdd><verrels:relationshipSet linkrole="http://www.eg.com/linkRole" arcrole="http://xbrl.org/int/dim/arcrole/domain-member"> </verrels:toRelationshipSet><verrels:relationships fromHref="toDTS.xsd#TotalGrossDomain" toHref="toDTS.xsd#MachinesMember" DRSaxis="self"/> </verrels:relationshipSet> |
As the toDTS has a dimension which, for this example, did not exist in fromDTS, there are individual relationship model events to document that each of the hypercube is added to the primary item, the dimension to the hypercube, total member domain to dimension, and machines member to the domain. This detail is not necessary in a processor-supported reporting situation. |
In this example a set of primary items in a DRS hierarchy, inheriting from and including concept PriItemA, are all given an added dimension NewAxis, with its DRS hierarchy of members applied to these primary items.
| Aspect | Example |
|---|---|
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="fromDTS.xsd#PriItemA" DRS-axis="descendant-or-self" linkrole="http://abc.com/pri-item-linkrole"/> </veria:fromAspects><veria:toAspects> </veria:aspectModelChange><veria:concept href="toDTS.xsd#PriItemA" DRS-axis="descendant-or-self" linkrole="http://abc.com/pri-item-linkrole"/> <veria:explicitDimension href="toDTS.xsd#NewAxis"/> </veria:toAspects> |
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.3 Typed dimension aspect
A typed dimension aspect, as used in an aspect models, represents the presence or exclusion of a value for a typed dimension in the aspect model for a fact item.
When an typed dimension aspect is provided by itself without an XML fragment, it simply specifies that the complete dimension as defined in the DTS is being applied.
| Aspect | Example |
|---|---|
|
<veria:concept href="dts1.xsd#A"/> <veria:concept href="dts1.xsd#B"/> <veria:concept href="dts1.xsd#C"/> <veria:typedDimension href="dts1.xsd#Dimension1"/>
|
The concepts A, B, and C are reported with Dimension1 values. |
Further specific information may be provided by an XML fragment, contained within the typedDimension element, that is a typed dimension value. Specifying the typed dimension value is relevant when a version report identifies further details in fact identification mapping. When the value is provided, the change reported applies only to typed dimensions with the given value.
In this example the fromDTS concept PriItemA, typed dimension Dimension1 has values which are changed,
from <oldElt oldAttr1="1">oldVal</oldElt>
to <newElt newAttr1="1">newVal</newElt>.
| Aspect | Example |
|---|---|
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="fromDTS.xsd#PriItemA"/> <veria:typedDimension </veria:fromAspects>xmlns:abcdim="http://www.abc.com/abcOldDim" href="fromDTS.xsd#Dimension1"> <abcdim:oldElt oldAttr="1"> </veria:typedDimension>
oldVal
</abcdim:oldElt><veria:toAspects> </veria:aspectModelChange><veria:concept href="toDTS.xsd#PriItemA"/> <veria:typedDimension </veria:toAspects>xmlns:abcdim="http://www.abc.com/abcNewDim" href="toDTS.xsd#Dimension1"> <abcdim:newElt newAttr="1"> </veria: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.4 Location aspect
The location aspect provides a predicate expression, in XPath, to identify a fact by its location amongst other facts of the same context in other tuples, or to express a predicate including existence or value of an attribute(s) of the fact or related fact. The location aspect provides an XPath simple predicate that has the fact to be identified as the context item.
Use of XPath 1 is shown here, but it is likely that the current W3C recommendation of XPath 2 will be recommended by the Dimension Module, with intentional compatibility to prior XPath 1 expressions.
Examples studied for the location aspect may or may not involve dimensions but seem to be consistent in that between the fromDTS and toDTS there are alterations in the tuple structure that require specifying how facts of fromDTS instances are adopted to new family structures in the toDTS instance without loosing associativity of those tuple-originating facts that need to hang together in the different tuple-destination structure.
In the first examples, an adapted country business reporting taxonomy fromDTS instance has a different tuple structure from that of the toDTS, and the taxonomy details do not provide any indication of how the facts are remapped from fromDTS instances to toDTS instances without losing the associativity inherent in the tuple structure.
The first table row shows that the key difference between contexts for the payee tuple is the addition of a dimension. This is documented in the versioning report by the addition of a new hypercube model.
The second table row shows that although that a dimension is added in the toDTS and documented by addition of a dimension aspect, a more important key difference in fact identification (mapping) between the DTS instances is in how the family members of a payee tuple "hang together". In the fromDTS instance and toDTS instance, the tax identification number is considered the key basis to consider which fromDTS tuple facts are mapped to toDTS tuple (dimensioned) facts. Notice that although items like name details, payroll number, and birth date are siblings in both from and toDTS instances, the signature items, that were siblings of the tax identification number, have become nephews in the instance of the toDTS (therein nested in a new signature tuple).
The need to locate nephews and such tuple relatives, with a key identifier (here the tax identification number), is a key feature of the location aspect model (based on an XPath relative expression).
| 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 fromHref="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. |
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="prior/fromDTS.xsd#abc_TaxFilingNumber"/> <veria:concept href="prior/fromDTS.xsd#abc_PersonBirthDate"/> <veria:concept href="prior/fromDTS.xsd#abc_EmployeePayrollNumber"/> <veria:concept href="prior/fromDTS.xsd#abc_PaymentTerminationCode"/> <veria:location> </veria:fromAspects>
../abc:PayeeDetails/abc:TaxFilingNumber
</veria:location><veria:toAspects> </veria:aspectModelChange><veria:concept href="current/toDTS.xsd#abc_TaxFilingNumber"/> <veria:concept href="current/toDTS.xsd#abc_PersonBirthDate"/> <veria:concept href="current/toDTS.xsd#abc_EmployeePayrollNumber"/> <veria:concept href="current/toDTS.xsd#abc_PaymentTerminationCode"/> <veria:explicitDimension href="current/toDTS.xsd#abc_ReportPartyTypeDimension"> <veria:member href="current/toDTS.xsd#abc_ReportingParty"/> </veria:explicitDimension><veria:location> </veria:toAspects>
../abc:Payee/abc:TaxFilingNumber
</veria:location> |
The aspect model change for siblings of the tax file number keeps these siblings together (in same location with respect to tax file number) in fromDTS and toDTS instances, and adds the explicit dimension aspect in instances of the toDTS. |
|
<veria:fromAspects> <veria:concept href="prior/fromDTS.xsd#abc_SignatureDate"/> <veria:concept href="prior/fromDTS.xsd#abc_DeclarationHardcopyIndicator"/> <veria:location> </veria:fromAspects>
../abc:PayeeDetails/abc:TaxFilingNumber
</veria:location><veria:toAspects>
<veria:concept href="current/toDTS.xsd#abc_StatementType"/> <veria:concept href="current/toDTS.xsd#abc_AcceptanceIndicator"/> <veria:concept href="current/toDTS.xsd#bc_SignatureDate"/> <veria:explicitDimension href="current/toDTS.xsd#abc_ReportPartyTypeDimension"> <veria:member href="current/toDTS.xsd#abc_ReportingParty"/> </veria:explicitDimension><veria:location> </veria:toAspects>
../abc:Declaration/abc:Payee/abc:TaxFilingNumber
</veria:location> |
The aspect model change declaration signature and hardcopy indicator, which were siblings of the tax file number in instances of the fromDTS, are a larger set of concepts in the toDTS in a different location, now nested in the declaration subtuple, so these items have morphed from siblings to nephews, of the tax file number. |
In this example, four facts provide a Global-Ledger (GL) style of tuple in the fromDTS instance, and a Financial Reporting (FR) style of concept in the toDTS instance, using a Financial Reporting style of taxonomy with with dimensions. The prefix gl is used arbitrarily for the fromDTS, and fr for the toDTS.
This example differs from the country business reporting taxonomy preceding in that here specific tuples, identified by the value of an item in the tuple, are mapped to different concepts. In the country business reporting example, every tuple of the same family structure was mapped to a toDTS dimensioned tuple of a slightly different structure (there, some prior-siblings became nephews in the toDTS instance). Here the item that is mapped to the toDTS instance has a different concept based on the value of a nephew item (instead of 'hanging together' with the nephew item in a resulting tuple of different structure).
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 17: Location aspect non-dimensional global ledger architecture mapped to financial reporting dimensional concepts
| Aspect | Example |
|---|---|
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="fromDTS.xsd#amount"/> <veria:location> </veria:fromAspects>
../gl:account/gl:accountMainId = ‘3000’
</veria:location><veria:toAspects> </veria:aspectModelChange><veria:concept href="toDTS.xsd#IncreaseDecreaseThroughChangesInAccountingPolicies"/> <veria:explicitDimension href="toDTS.xsd#ComponentsOfEquityAxis"> </veria:toAspects><veria:member href="toDTS.xsd#IssuedCapitalMember"/> </veria:explicitDimension> |
The aspect model change for amount with nephew account 3000 to ifrs:IncreaseDecreaseThroughChangesInAccountingPolicies with dimension ComponentsOfEquityAxis, member IssuedCapitalMember. |
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="fromDTS.xsd#amount"/> <veria:location> </veria:fromAspects>
../gl:account/gl:accountMainId = ‘4000’
</veria:location><veria:toAspects> </veria:aspectModelChange><veria:concept href="toDTS.xsd#IncreaseDecreaseThroughCorrectionsOfErrors"/> <veria:explicitDimension href="toDTS.xsd#ComponentsOfEquityAxis"> </veria:toAspects><veria:member href="toDTS.xsd#SharePremiumMember"/> </veria:explicitDimension> |
The aspect model change for amount with nephew account 4000 to ifrs:IncreaseDecreaseThroughCorrectionsOfErrors with dimension ComponentsOfEquityAxis, member SharePremiumMember. |
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="fromDTS.xsd#amount"/> <veria:location> </veria:fromAspects>
../gl:account/gl:accountMainId = ‘5000’
</veria:location><veria:toAspects> </veria:aspectModelChange><veria:concept href="toDTS.xsd#IncreaseDecreaseThroughOtherContributionsByOwners"/> <veria:explicitDimension href="toDTS.xsd#ComponentsOfEquityAxis"> </veria:toAspects><veria:member href="toDTS.xsd#TreasurySharesMember"/> </veria:explicitDimension> |
The aspect model change for amount with nephew account 5000 to ifrs:IncreaseDecreaseThroughOtherContributionsByOwners with dimension ComponentsOfEquityAxis, member TreasurySharesMember. |
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="fromDTS.xsd#amount"/> <veria:location> </veria:fromAspects>
../gl:account/gl:accountMainId = ‘6000’
</veria:location><veria:toAspects> </veria:aspectModelChange><veria:concept href="toDTS.xsd#DividendsPaid"/> <veria:explicitDimension href="toDTS.xsd#ComponentsOfEquityAxis"> </veria:toAspects><veria:member href="toDTS.xsd#OtherEquityInterestMember"/> </veria: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 |
|---|---|
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="fromDTS.xsd#factX"/> <veria:location> </veria:fromAspects>
starts-with(@contextRef, 'currentYrQ1')
</veria:location><veria:toAspects> </veria:aspectModelChange><veria:concept href="toDTS.xsd#factX"/> <veria:explicitDimension href="toDTS.xsd#FYdim"> </veria:toAspects><veria:member href="toDTS.xsd#currentYrQ1"/> </veria:explicitDimension> |
The aspect model change for identifying fiscal quarter from starting letters of context ID to a dimension member. |
