Copyright ©2010 XBRL International Inc., All Rights Reserved.
Circulation of this Public Working Draft is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to versioning-feedback@xbrl.orgversioning-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
This specification is an extension to the Versioning Base Specification [XVS-Base]. It specifies how to map and address changes to the aspects of fact items of a set of concepts, including dimensional and other aspects, specifying that changes have occurred between different DTSes to items that may be a primary item and its dimensions and domain-members, or other aspects that may distinguish the fact item.
1 Herm Fischer:Clarification per WG discussion 2010-08-24, shortened paragraph and set off as non normative, suggestion
to delete entirely, or is it still relevant?
2 Herm Fischer:per 2010-08-24 New nonnormative suggesting there may be future new aspects
3 Herm Fischer:per 2010-08-24, added discussion above on location aspect.
4 Herm Fischer:per 2010-08-24, replaced "Identifier" with "identifer" in terms to harmonize with other specs
5 Herm Fischer:per 2010-08-24, complete and nonXDT segment/scenario aspects are merged. I changed the definition slightly
to fragments that are s-equal to fragments, meaning that one doesn't need to specify all of the XML in the
segment or scenario (which is how it is defined below)
6 Herm Fischer:I think s-equality must be specified, not exact duplication of elements
7 Herm Fischer:I think s-equality must be specified, not exact duplication of elements
8 Roland Hommes:Create asspectIdentifier definition, do we still need this?
9 Roland Hommes:Content is somehow messed up with two veria and veriae entries, not in source though!
10 Herm Fischer:Rewrote this section
11 :Need diagram here
12 Herm Fischer:The @isDefaultMember on the member element will be removed at the next revision if no use case is found.
13 Roland Hommes:There is a MUST in here (last line) but there is also the author freedom of (not) reporting.
14 Roland Hommes:Is it 2.1 compliant to have typedDimension values in a notAll construct?
15 Herm Fischer:Clarification per WG discussion 2010-08-24, combined complete and nonXDT segment and
scenario, changed to represent child elements of instance segment and scenario that identify facts,
which are not XDT elements.
16 Herm Fischer:Text changed to indicate that only change events are allowed involving unit.
1 Introduction
1.1 Relationship to other work
1.2 Language independence
1.3 Document conventions
1.3.1 Typographic conventions
1.3.1.1 Definition notation
1.3.1.2 Footnote notation
1.3.1.3 Element and attribute notation
1.3.2 Formatting conventions
1.4 Terminology
1.5 Namespaces and namespace prefixes
2 Events and Mappings
2.1 Aspect Identifiers
2.2 Aspect Model Events
2.2.1 Fact identification mappings
3 Syntax
3.1 Aspects
3.1.1 Concept Aspect
3.1.2 Explicit Dimension Aspect
3.1.3 Typed Dimension Aspect
3.1.4 Segment and Scenario Aspects
3.1.5 Entity-Identifier Aspect
3.1.6 Period Aspect
3.1.7 Unit Aspect
3.1.8 Location Aspect
3.2 Aspect model
3.3 Related Concepts
3.3.1 Validation Rules
A Normative schema
B References
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)
F Errata corrections in this document
1 Namespaces and namespace prefixes
2 Aspect identifiers of change events
3 Aspect model events
1 A normative example
2 A non-normative example
3 An example of poor usage
4 Concept aspect
5 Explicit Dimension aspect
6 Typed Dimension aspect
7 Segment and Scenario aspects
8 Entity Identifier aspects
9 Period aspects
10 Unit aspects
11 Location aspects
12 Aspect Model
aspect
aspect-equivalent facts
aspect-identifier
aspect-model
entity-identifier
explicit-dimension-identifier
fact-identification mappings
location-identifier
member-identifier
period-identifier
scenario-identifier
segment-identifier
typed-dimension-identifier
unit-identifier
veriae:bad-arc-element
veriae:bad-link-element
veriae:bad-uri
veriae:missingAxisArcroleAttribute
veriae:missingAxisLinkroleAttribute
This specification depends upon the following XBRL specifications:
In the event of any conflicts between this specification and the specifications upon which it depends, this specification does not prevail.
Several aspects of the aspect model depend on relationships expressed in the DTS. Concept to concept relationships and dimension relationships are expressed respectively with base sets and dimensional relationship sets that depend on link roles. Versioning Report documentation on link role mappings is specified in the base versioning specification [XVS-Base].
The aspect model of this specification is semantic, and does not depend on, or detail, any arc relationships that compose these models in XBRL taxonomies. However, taxonomy maintainers MAY require Version Reports that document relationships between concepts of a dimensional or non-dimensional nature. Dimensional relationships composing primary item has-hypercube inheritance, dimensions, domain, and members dimensional relation sets, MAY be documented with the relationship sets specification [XVS-Relationship-Sets]. Non-dimensional relationships between concepts, such as those that relate multiple concepts in composing concept aspects, MAY also be related with base sets of relationships in the relationship-sets specification [XVS-Relationship-Sets].
[Herm Fischer: Clarification per WG discussion 2010-08-24, shortened paragraph and set off as non normative, suggestion to delete entirely, or is it still relevant?]
The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.
Comments which are informative, but not essential to the understanding of the point at hand, are provided in footnotes. All footnotes are non-normative.
When referring to a specific element, it will be identified by
its namespace prefix and local name. For example, the root
element for a specification container element would be referred to as
<variable:generalVariable>
.
Attributes are also identified by their local name and, where
appropriate, their namespace prefix. Attributes are
distinguished from elements by prefixing them by an
@
symbol. Thus,
@id
refers to the attribute with the name id.
When referring to any attribute, so long as it has a specific
namespace, the local name is replaced by an asterisk (
*).
Thus, the notation
@xml:* specifies any attribute
in the namespace
http://www.w3.org/XML/1998/namespace.
The following highlighting is used for normative technical material in this document:
Text of the normative example.
The following highlighting is used for non-normative examples in this document:
Text of the helpful example.
Next paragraph of the helpful example.
Example 3 shows the formatting for non-normative examples of poor, discouraged or disallowed usage.
The example itself.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in [IETF RFC 2119].
The key words dimension, primary item, hypercube and member in this document are to be interpreted as described in the XBRL Dimensions Specification [DIMENSIONS].
The key words fact and instance in this document are to be interpreted as described in the XBRL Specification [XBRL 2.1].
An aspect is information about a fact, specified by Variables 1.0 Aspects. The aspects that are initially covered by this specification are in Table 2.
[Herm Fischer: per 2010-08-24 New nonnormative suggesting there may be future new aspects]
The Working Group has included changes in the concept,
<veria:unit>
,
<veria:entityIdentifier>
,
<veria:period>
and
<veria:location>
aspects
in the versioning report. The
<veria:concept>
aspect is needed to express primary item
manifestations in the aspect model. The
<veria:location>
aspect is a general XPath predicate
that may indicate location among other items (such as within tuples) as well as general issues
such as patterns within context IDs, and custom fact attribute predicates.
Although the rest of these aspects cannot be controlled from within the DTS, it is likely that they MAY be needed to uniquely identify the fact.
An aspect model, as specified by the Variables 1.0 Aspect Model, is a description of how the information about a fact will be split into different aspects.
Aspect-equivalent facts are facts which are considered equivalent within 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. Equivalency in this specification is meant only as the mapping between two different instances from two DTS's which are the subject of a Versioning Report.
[Herm Fischer: per 2010-08-24, replaced "Identifier" with "identifer" in terms to harmonize with other specs]
A memberIdentifier, as used in this specification, is a
conceptIdentifier for a concept
that has an effective http://xbrl.org/int/dim/arcrole/domain-member arcrole in the DTS.
An explicitDimensionIdentifier, as used in this specification, is a
conceptIdentifier for a concept
in the substitutionGroup xbrldt:dimensionItem and does not have the
@xbrldt:typedDomainRef and
has an effective http://xbrl.org/int/dim/arcrole/hypercube-dimension arcrole in the DTS.
A typedDimensionIdentifier, as used in this specification, is a
conceptIdentifier for a concept
in the substitutionGroup xbrldt:dimensionItem and has the
@xbrldt:typedDomainRef and
has an effective http://xbrl.org/int/dim/arcrole/hypercube-dimension arcrole in the DTS.
[Herm Fischer: per 2010-08-24, complete and nonXDT segment/scenario aspects are merged. I changed the definition slightly to fragments that are s-equal to fragments, meaning that one doesn't need to specify all of the XML in the segment or scenario (which is how it is defined below)]
A segmentIdentifier, as used in this specification, is a set of XML fragments
that are s-equal to corresponding XML fragments
parented by the
<xbrli:segment>
in the
<xbrli:context>
of the instance.
If the DTS is dimensional, these fragments exclude any in the http://xbrl.org/2005/xbrldt namespace.
A scenarioIdentifier, as used in this specification, is a set of XML fragments
that are s-equal to corresponding XML fragments
parented by the
<xbrli:scenario>
in the
<xbrli:context>
of the instance.
If the DTS is dimensional, these fragments exclude any in the http://xbrl.org/2005/xbrldt namespace.
An entityIdentifier, as used in this specification, is the complete set of XML fragments
parented by the
<xbrli:entity>
node in the
<xbrli:context>
of the instance.
[Herm Fischer: I think s-equality must be specified, not exact duplication of elements]
A periodIdentifier, as used in this specification, is the complete set of XML fragments
parented by the
<xbrli:period>
node in the
<xbrli:context>
of the instance.
[Herm Fischer: I think s-equality must be specified, not exact duplication of elements]
A locationIdentifier, as used in this specification, consists of an XML Path expression predicate usable to identify a fact. This may be any XPath effective boolean expression of existence, value or other XPath nature, such as determination of presence of a containing or relative fact, or expression involving attribute values. The locationIdentifier MUST NOT be an XPath ordinal position (index) predicate.
An unitIdentifier, as used in this specification, is a
set of XML elements that are s-equal to those of the
<xbrli:unit>
element of the instance (e.g., the unit, when
applied to numeric items would be u-equal to the unit represented
by the identifier).
An aspectIdentifier as used in this specification is . [Roland Hommes: Create asspectIdentifier definition, do we still need this? ]
Namespace prefixes [XML Names] will be used
for elements and attributes in
the form ns:name where ns is the
namespace prefix and name is the local name.
Throughout this specification, the mappings
from namespace prefixes to actual namespaces is consistent
with
Table
1.
The prefix column in Table 1 is non normative. The namespace URI column is normative.
| Prefix | Namespace URI |
|---|---|
veria
|
http://xbrl.org/2010/versioning-instance-aspects
|
veriae
|
http://xbrl.org/2010/versioning-instance-aspects/error
|
xs
|
http://www.w3.org/2001/XMLSchema
|
gen
|
http://xbrl.org/2008/generic
|
eg
|
http://example.com/
|
ver
|
http://xbrl.org/2010/versioning-base
|
vercb
|
http://xbrl.org/2010/versioning-concept-basic
|
verce
|
http://xbrl.org/2010/versioning-concept-extended
|
verr
|
http://xbrl.org/2010/versioning-relations
|
The representation of fact items of a set of concepts in terms of their aspect models, is similar to the way the Variables Specification [VARIABLES], used for formula processing and filtering, defines its aspect model and aspects. It allows this specification to address concepts with dimensions that are explicit or typed and are an aspect on facts. It can also address aspects that are segment and/or scenario content, tuple location, or have other aspects, like custom attributes and -elements or even different syntax (like XHTML).
The aspect model tracks changes of aspects and supports
the mapping of instance information. The aspect model also tracks changes of
the dimensional aspects that are not allowed for facts described by indicated concepts
by dimension aspects with the
@excluded attribute set to 'true'.
The aspect model tracks changes to concept or dimensional aspect models that specify concepts individually or in a relationship set indicated by an axis, which allows a single concept that is at the head of a hierarchy of concepts or head of a dimensional relationship set of primary item concepts to include the hierarchy succinctly.
Dimensions, primary items, hypercubes and members are specified in terms of XBRL concepts [XBRL 2.1] so, as a consequence, Versioning Report documentation on dimensionally pertinent XBRL concepts [XBRL 2.1] is documented with the Basic Concepts Specification [XVS-Concept-Basic] and Concept Details Specification [XVS-Concept-Extended].
Dimensional relationships sets, are specified in terms of XBRL concept hierarchies where aspects are reported for purposes of fact identification and mapping, however documentation of dimensional relationship sets, by their extended links and hypercubes, is documented using the Relationship Sets Specification [].
| Name | Element | Identification |
|---|---|---|
| concept aspect |
<veria:concept>
|
ConceptIdentifier and
optional
@axis specificiations |
| explicitDimension aspect (one aspect per dimension) |
<veria:explicitDimension>
,
<veria:member>
|
explicitDimensionIdentifier and
memberIdentifier with optional
@axis, and
optional
@isDefaultMember specificiations |
| typedDimension aspect (one aspect per dimension) |
<veria:typedDimension>
|
typedDimensionIdentifier and XML fragment |
| segment aspect |
<veria:segment>
|
segmentIdentifier |
| scenario aspect |
<veria:scenario>
|
scenarioIdentifier |
| entity-identifier aspect |
<veria:entityIdentifier>
|
entityIdentifier and/or scheme |
| period aspect |
<veria:period>
|
periodIdentifier and/or scheme |
| location aspect |
<veria:location>
|
locationIdentifier |
| unit aspect |
<veria:unit>
|
unitIdentifier |
This specification defines three aspect model events. These events, in conjunction with fact-identification mappings, are based on pairs of aspect models representing information about facts, one from each of the From-DTS and To-DTS as being aspect-equivalent facts, as described in Section 2.2.1.
| Code | Element | From Identifier | To Identifier |
|---|---|---|---|
| [AspectModelChange] |
<veria:aspectModelChange>
|
AspectIdentifier | AspectIdentifier |
| [AspectModelAdd] |
<veria:aspectModelAdd>
|
AspectIdentifier | |
| [AspectModelDelete] |
<veria:aspectModelDelete>
|
AspectIdentifier |
Fact identification mappings establish means of identifying facts that have equivalence in different instances referenced by two versioned DTS's.
For example, facts identified by their concept of a From-DTS may have equivalent identification in a To-DTS by means of a different concept and an explicit dimension of given member. (Note: This example leaves other aspects like unit, entity, location etc. out of scope here)
Another example is when some facts of a From-DTS were identified by a scenario fragment, in a To-DTS these facts are identified by a dimension with certain member. In this example facts of the From-DTS without the designated scenario element are identified in the To-DTS by facts with a different dimension member.
Aspect model mapping information, which MAY include dimensional representation of a set of concepts, is obtained from the Versioning Report as follows:
<veria:fromAspects>
element of a
AspectModelChange event
and the
<veria:toAspects>
element of a
AspectModelChange event
are to identify
aspect-equivalent instance facts.
This specification only provides a textual declaration of syntax constraints when those constraints are not expressed by the normative schema supplied with this specification.
Explanations of elements and attributes are only supplied when explanations are not already provided in other specifications.
Unless explicitly stated otherwise, a reference to a specific element MUST be read as a reference to that element or to any element in its substitution group.
This section describes the individual aspects that pertain to aspect models (for fact identification aspects), and to identify disallowed dimensional aspect combinations. The individual aspects are introduced first, with examples pertaining to individual aspects alone, and then two models are introduced, with examples showing the use of multiple aspects.
The syntax for the
<veria:concept>
element
is defined by the normative schema supplied with this specification.
The DTS concept for this aspect is identified by the
@href attribute.
| Aspect | Reference |
|---|---|
|
<veria:concept href="../dts1702a.xsd#dts_ConceptA"/>
|
The concept aspect of this aspect model is the xsd element of the parent directory's dts1702a.xsd schema, element with ID dts_ConceptA. |
It is possible to specify that the concept aspect MAY
include concepts related to the identified concept, as specified in
Section
3.3.
If no related concepts
@axis attribute is provided, then the
@href attribute is the
specified concept value for this concept aspect.
The syntax for the
<veria:explicitDimension>
element
is defined by the normative schema supplied with this specification.
The DTS concept for the dimension of this aspect is identified by the
@href attribute.
The
<veria:explicitDimension>
element may have zero or more
<veria:member>
elements.
<veria:member>
element is provided, then this aspect specifies
the entire dimension.
(For example a dimension aspect is being added or removed in entirety,
with all members that are defined according to its DTS applying to that aspect).
<veria:member>
element is provided,
then that is the one dimension member that identifies the to/from fact
being identified.
<veria:member>
elements are provided, they represent alternatives of member
values for this dimension aspect.
[Herm Fischer: Rewrote this section]
When there are multiple
<veria:explicitDimension>
elements of the same
DTS dimension concept, for the same
<veria:fromAspects>
or
<veria:toAspects>
element, these dimensions are
all required to be present together to identify pertinent facts (such
as to document allowable value sets and excluded some value(s)).
A dimension aspect specified for
<veria:toAspects>
mappings should have a uniquely identified
member, so that the
Versioning Report can be used to
uniquely identify the aspects of a fact in the
To-DTS.
The DTS concept for a
<veria:member>
element of the
explicitDimension aspect is identified by the
@href attribute
and related concepts, as specified in
Section
3.3.
If no related concepts
@axis attribute is provided, then this member element is the
specified member value for this explicitDimension aspect.
If a related concepts
@axis is provided, then the members identified by the
@axis attribute, related to the
member specified, are values of this aspect model.
If an
@excluded attribute is provided with value true, then the
memberIdentifier
specified by the
<veria:explicitDimension>
element are excluded from the values of this
dimension aspect in the aspect model.
The modeling of notAll hypercube effects may be documented by aspect models of explicit dimensions with
@excluded=true attributes.
For example, this can exclude notAll member values from
an aspect's set of members by being present in the same parent element with another non-excluding
<veria:explicitDimension>
element.
| Aspect | Reference |
|---|---|
|
<veria:explicitDimension href="../dts1.xsd#dts_Dimension1">
<veria:member href="../dts1.xsd#dts_Member2"/> </veria:explicitDimension> |
The explicit dimension aspect for the dts_Dimension1 dimension element of this aspect model is the xsd element of the parent directory's dts1.xsd schema, dimension member value element with ID dts_Member2. |
|
<veria:explicitDimension href="../dts1.xsd#dts_Dimension1"> <veria:member href="../dts1.xsd#dts_Total" linkrole="http://www.xbrl.org/2003/role/link" arcrole="http://xbrl.org/int/dim/arcrole/domain-member" axis="descendant-or-self"/> </veria:explicitDimension><veria:explicitDimension href="../dts1.xsd#dts_Dimension1" excluded="true">
<veria:member href="../dts1.xsd#dts_Member66"/> </veria:explicitDimension> |
The explicit dimension aspect for the dts_Dimension1 dimension element of this aspect model are all the dimension domain and member elements (those of the xsd element dts_Total and its descendants in the domain-member hierarchy), with the exception of dts_Member66, which is excluded from the members of this aspect model. |
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:explicitDimension href="../dts1.xsd#dts_Country"> </veria:fromAspects><veria:member href="../dts1.xsd#dts_Czechoslovakia"/> </veria:explicitDimension><veria:toAspects> </veria:aspectModelChange><veria:explicitDimension href="../dts2.xsd#dts_Country"> </veria:toAspects><veria:member href="../dts2.xsd#dts_CzechRepublic"/> <veria:member href="../dts2.xsd#dts_Slovakia"/> </veria:explicitDimension> |
The aspect model change event specifies that the Country dimension Czechoslovakia member has split into two members Czech Republic and Slovakia. |
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:explicitDimension href="../dts1.xsd#dts_Country"> </veria:fromAspects><veria:member href="../dts1.xsd#dts_CzechRepublic"/> <veria:member href="../dts1.xsd#dts_Slovakia"/> </veria:explicitDimension><veria:toAspects> </veria:aspectModelChange><veria:explicitDimension href="../dts2.xsd#dts_Country"> </veria:toAspects><veria:member href="../dts2.xsd#dts_CzechSlovHyperUnion"/> </veria:explicitDimension> |
The aspect model change event specifies that the Country dimension members Czech Republic and Slovakia have merged to the imaginary future new member CzechSlovHyperUnion. |
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="../dts1.xsd#PrimaryItemA"/> <veria:explicitDimension href="../dts1.xsd#Dimension"> </veria:fromAspects><veria:member href="../dts1.xsd#MemberA"/> </veria:explicitDimension><veria:toAspects> </veria:aspectModelChange><veria:concept href="../dts2.xsd#PrimaryItemA"/> <veria:explicitDimension href="../dts2.xsd#Dimension"> </veria:toAspects><veria:member href="../dts2.xsd#MemberC"/> </veria:explicitDimension> |
Use case HP-5: A primary item A can have Dimension members A and B in the from DTS, but in the to DTS member A is replaced by member C. The aspect model change event shown here is sufficient for fact identification mapping change tracking. In the aspect model change event, there is only one change event, from the combination of PrimaryItemA as the concept aspect, and a dimension aspect for a dimension named Dimension, member A, changing to an aspect model of concept aspect PrimaryItemA, dimension Dimension, member C. For fact identification mapping purposes, no change event is documented for the unchanged aspect model of primary item A, dimension Dimension, and member B. |
|
<veria:aspectModelDelete>
<veria:fromAspects> </veria:aspectModelDelete><veria:concept href="../dts1.xsd#PrimaryItemA"/> <veria:explicitDimension href="../dts1.xsd#Dimension"> </veria:fromAspects><veria:member href="../dts1.xsd#MemberA"/> </veria:explicitDimension> |
Use case HP-6: A primary item A can have Dimension members A and B in the from DTS, but in the to DTS member A is excluded. This event specifies the aspect model of PrimaryItemA, dimension Dimension, and members A, has been deleted (rather than this combination of fact identification aspects changed to some other set of aspects for the to DTS). There is no need to specify anything about concdpt A with Dimension member member B as its fact identification aspects are unchanged. |
|
<veria:aspectModelDelete>
<veria:fromAspects> </veria:aspectModelDelete><veria:explicitDimension href="../dts1.xsd#dts_D"> <veria:member href="../dts1.xsd#dts_d1"/> </veria:explicitDimension><veria:explicitDimension href="../dts1.xsd#dts_E"> </veria:fromAspects><veria:member href="../dts1.xsd#dts_e1"/> </veria:explicitDimension> |
Use case EJ-1: The fromDTS aspect model specifies that D:d1 and d2, E:e1 and e2 are allowed, the toDTS excludes only the combination D:d1 and E:e1. This is documented by deleting the combination D:d1 and E:e1 in the toDTS aspect model. |
Dimension members specified by the
@axis MAY refer to non-dimensional arc base sets,
such as for US-GAAP 2009, referring to table and axis structures located in the presentation linkbase.
Dimension members specified by the
@axis specify XBRL 2.1 base sets [XBRL 2.1].
If the specified arcrole
includes dimension-domain-member arcs, the
@xbrldt:targetRole dimensional semantics are NOT respected. Instead the
@DRS-axis is provided to specify dimension-domain-member arcs respecting dimensional relationship sets formed
with
@xbrldt:targetRole attributes.
Changes within a dimensional relationship set syntax, that does not affect the membership or hierarchy, will not imply any aspect change.
For example, intermediate arcs are moved between different
@xbrldt:targetRole connected linkroles, but the
hierarchy (or member content) remains the same. If appropriate to report for DTS maintainers (such as taxonomy extenders who
may refer to such linkrole changes, they can be provided with the relationship sets module.
Changes in the linkrole between From-DTS and To-DTS are represented in the Basic Concept Specification [XVS-Concept-Basic], and do not imply any aspect changes.
A DTS MAY specify a default member for any
explicit dimension, as specified by an http://xbrl.org/int/dim/arcrole/dimension-default
relationship.
A dimension member MAY be reported as default by the
@isDefaultMember attribute, or it may be
reported by a
Versioning Report of
the Versioning-Relationship-Sets module [XVS-Relationship-Sets]. The
explicitDimensionIdentifier
specifies explicit dimension value members regardless of whether default or not.
[Herm Fischer: The @isDefaultMember on the member element will be removed at the next revision if no use case is found.]
Versioning Report information on concepts that represent primary items, hypercubes, dimensions and members are reported in the same manner as any other XBRL concepts, using the Basic Concepts Specification [XVS-Concept-Basic] and Concept Details Specification [XVS-Concept-Extended]. Versioning Report information on arcs that represent syntactical construction of dimensions and membership MAY be reported with the Versioning Relationship Sets [XVS-Relationship-Sets]. Versioning Report information on semantic validation rules for hypercubes are reported using the aspect model of this specification. [Roland Hommes: There is a MUST in here (last line) but there is also the author freedom of (not) reporting. ]
The syntax for the
<veria:typedDimension>
element
is defined by the normative schema supplied with this specification.
The typedDimensionIdentifier is
communicated in the
@href attribute.
The value of the typed dimension is provided
by the XML fragment contained by the
<veria:typedDimension>
element.
If no value is present,
then the aspect specifies only the dimension
(for example that a dimension is being added or removed,
with all typed values that are defined according to its DTS).
If an
@excluded attribute is provided with value true, then the aspect value
specified by the
<veria:typedDimension>
element is excluded from the values of this
dimension aspect in the aspect model.
[Roland Hommes: Is it 2.1 compliant to have typedDimension values in a notAll construct? ]
The modeling of notAll hypercube effects may be documented by aspect models of typed dimensions with
@excluded=true attributes.
| Aspect | Reference |
|---|---|
|
<veria:typedDimension
xmlns:honahLee="http://www.honahLee.com" href="../dts1702f.xsd#DragonDimension"> <honahLee:dragon name="Puff"/> </veria:typedDimension> |
The typed dimension aspect for the DragonDimension dimension value
of this aspect model is the xml fragment
<honahLee:dragon name="Puff">
. |
|
<veria:typedDimension href="../dts1702f.xsd#DragonDimension"/> <veria:typedDimension
xmlns:honahLee="http://www.honahLee.com" href="../dts1702f.xsd#DragonDimension" excluded="true"> <honahLee:dragon name="Jackie Paper"/> </veria:typedDimension> |
The typed dimension aspect for the DragonDimension dimension includes all dragon elements, except for one named "Jackie Paper". |
Versioning Report information regarding the
type of a typed dimension is reported with the
Versioning Concept-Extended module [XVS-Concept-Extended] as a custom attribute event, for the
@xbrldt:typedDomainRef attribute.
When a typedDimensionIdentifier is changed in structure, schema validation rules or any XML specification aspect, this is reported as an aspect change. However there are no explicit events reporting on individual XML schema elements and attributes composing the definition of a typed dimension's defining element, a versioning Report processor MAY discover this by inspection of the typed domain element schema definition when notified of a change event.
The syntax for the
<veria:segment>
and
<veria:scenario>
elements
are defined by the normative schema supplied with this specification.
[Herm Fischer: Clarification per WG discussion 2010-08-24, combined complete and nonXDT segment and scenario, changed to represent child elements of instance segment and scenario that identify facts, which are not XDT elements.]
The segment and scenario aspects specify child elements of context
<xbrli:segment>
or
<xbrli:scenario>
elements
that identify a fact value.
The value for
<veria:segment>
and
<veria:scenario>
elements
is provided by the XML fragment contained by the elements, and is
non-exclusive, meaning there may be other elements but they do not apply to the aspect value
of the relevant versioning action.
If the DTS of an instance discovers the XBRL dimensional schema file then this aspect
excludes any dimensional elements from the
<xbrli:segment>
or
<xbrli:scenario>
values. A non-dimensional
DTS (which does not discover the XBRL dimensional schema file) MAY
include dimensional elements in segment and scenario aspects.
If an
@excluded attribute is provided with value true, then the aspect value
specified by this element is excluded from the values of this aspect in the aspect model.
| Aspect | Reference |
|---|---|
|
<veria:scenario
xmlns:dts="http://www.xbrl.org/versioning/testcases"> <dts:consolidated/> </veria:scenario> |
The scenario aspect for this aspect model contains the
element
<dts:consolidated>
. |
|
<veria:scenario
xmlns:dts="http://www.xbrl.org/versioning/testcases" excluded="true"> <dts:consolidated/> </veria:scenario> |
The scenario aspect for this aspect model does not contain the
element
<dts:consolidated>
. |
The syntax for the
<veria:entityIdentifier>
element
is defined by the normative schema supplied with this specification.
The value for
<veria:entityIdentifier>
MAY be provided by the
@scheme and/or
@value attributes. If neither
@scheme or
@value is present,
then the aspect
specifies only that entity-identification, as an aspect for fact identification, is being added, deleted, or changed,
but when attribute values are provided, the aspect pertains to specific scheme and/or identifier values.
| Aspect | Reference |
|---|---|
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:entityIdentifier/> </veria:fromAspects><veria:toAspects> </veria:aspectModelChange><veria:explicitDimension href="../dts2.xsd#dts_Company"/> </veria:toAspects> |
The aspect of facts which was represented by an entityIdentifier is changed to an aspect of explicit dimension called Company. No specific entity identifier scheme or value is provided, so this event only documents aspect change in general terms, but doesn't provide specific mapping between former entityIdentifier scheme/value aspects and subsequent dimension member replacements. This change event applies to all fact items (because neither scheme nor value are provided). |
|
<veria:aspectModelDelete>
<veria:fromAspects> </veria:aspectModelDelete><veria:entityIdentifier value="subsidiary07"/> </veria:fromAspects> |
Facts can no longer be reported with the entity identifier aspect that has the "subsidiary07" value, as this aspect has been deleted. |
The syntax for the
<veria:period>
element
is defined by the normative schema supplied with this specification.
The value for
<veria:period>
MAY be provided by a choice of
both
<startDate>
and
<endDate>
, or
<instant>
or
<forever>
elements.
If none of these elements is present,
then the aspect
specifies only that period, as an aspect for fact identification, is being added, deleted, or changed,
but when these elements are provided, the aspect pertains to period semantics of those elements.
| Aspect | Reference |
|---|---|
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:period> </veria:fromAspects><veria:instant> </veria:period>2012-12-21 </veria:instant><veria:toAspects> </veria:aspectModelChange><veria:explicitDimension href="mayan.xsd#Calendar"> </veria:toAspects><veria:member href="mayan.xsd#EndOfWorld"/> </veria:explicitDimension> |
The aspect of facts which was represented by an instant date representing the Mayan calendar "end of world" date is represented in the toDTS by an explicit dimension member. (As with XBRL periods, the Mayan belief system is that the endDate also is the startDate instant of the next cyclical "world age" period, so that one might make life choices in time, such that the transition instant is a non-cataclysmic event.) |
The syntax for the
<veria:unit>
element
is defined by the normative schema supplied with this specification.
The value for
<veria:unit>
MAY be provided by the
<veria:measure>
,
<veria:multiplyBy>
and/or
<veria:divideBy>
elements if
needed to identify unit value for
specific instance fact aspect mappings. If neither construct is present, then the aspect
specifies only that unit, as an aspect for fact identification, is being added, deleted, or changed,
but when attribute values are provided, the aspect pertains to specific values.
Only change events may be reported for units.
[Herm Fischer: Text changed to indicate that only change events are allowed involving unit.]
| Aspect | Reference |
|---|---|
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:unit> </veria:fromAspects><veria:measure namespace="http://www.xbrl.org/2003/iso4217" name="HLU"/> </veria:unit><veria:toAspects> </veria:aspectModelChange><veria:unit> <veria:measure namespace="http://www.xbrl.org/2003/iso4217" name="EUR"/> </veria:unit><veria:explicitDimension href="../dts2.xsd#Country"> </veria:toAspects><veria:member href="../dts1.xsd#HonahLee"/> </veria:explicitDimension> |
A land called Honah Lee is being admitted to the European Union, and facts which were
previously identified by measure iso4217:HLE are in items of the to DTS
represented by a country dimension and unit EUR.
|
The syntax for the
<veria:location>
element
is defined by the normative schema supplied with this specification.
The value for
<veria:location>
MAY be provided by an XPath expression
that represents an XPath predicate (an effective boolean value) identifying related instance facts
and fact attributes as needed to identify tuple
affinity, membership, or ancestry.
The XPath context item of a
<veria:location>
XPath expression is the fact (XBRL instance node)
being identified with this location aspect.
The XPath expression MUST NOT be an ordinal index expression.
| Aspect | Reference |
|---|---|
|
<veria:aspectModelChange>
<!-- TBD --> </veria:aspectModelChange> |
A tuple T contains facts of concept A, B and C in instances of the from DTS. In the to DTS the facts of concepts A are no longer contained in tuples, and with the to DTS these fact items have two dimensions, dim-B, and dim-C, where the member values of dim-B and dim-C respectively represent the values that had been in fact A's tuple sibling items B and C . |
|
<veria:aspectModelChange>
<!-- TBD --> </veria:aspectModelChange> |
A tuple T contains facts of concept A and a child tuple U with facts of concepts B and C in instances of the from DTS. In instances of the to DTS the tuple T has facts of concepts A, B, and C all as siblings of each other (nesting of U's items are raised to T's level). |
|
<veria:aspectModelChange>
<!-- TBD --> </veria:aspectModelChange> |
From DTS instance JournalEntry tuples contain items of concepts Amount, FromAccountCode, ToAccountCode, FromAccountDescription, and ToAccountDescription. In instances of the to DTS there is a new set of tuples called ChartOfAccounts/Account, which contain AccountCode and AccountDescription, so the FromAccountDescription and ToAccountDescription items are removed from the JournalEntry tuples to the ChartOfAccount/Account tuples. |
The aspects identified by the aspect model of
<veria:fromAspects>
and
<veria:toAspects>
elements
are declared by the aspect elements (
Section
3.1) of type
[Cannot resolve XML ID
xml-element.aspect-model.type
]
(corresponding to aspects of
Table
2).
These aspects are combined by "anding" to the others specified withinin the same element.
Whereas the examples in the previous section ( Section 3.1) addressed single aspect changes, without applying to either fact identification of the aspect model, this section provides examples where multiple aspects are combined.
| Aspect | Example |
|---|---|
|
<veria:aspectModelChange>
<veria:fromAspects> <veria:concept href="../dts1.xsd#MachinesGross"/> </veria:fromAspects><veria:toAspects> </veria:aspectModelChange><veria:concept href="../dts2.xsd#PPEGross"/> <veria:explicitDimension href="../dts1.xsd#PPEAxis"> </veria:toAspects><veria:member href="../dts1.xsd#MachinesMember"/> </veria:explicitDimension> |
Use case HP-2, aspect model. In the from non-dimensional DTS, there is a hierarchy of concepts to represent breakdown of information. The from DTS in this example has PPEGross->MachinesGross, PPEGross is a parent and MachineGross a child concept (in the presentation and summation hierarchies). With the dimensional to DTS fact items of the prior MachinesGross breakdown become fact items of the prior parent PPEGross concept with PPEAxis dimension MachinesMember. The purpose of the aspect model is to record fact identification mappings, e.g., that the items of MachinesGross become items of PPEGross with PPEAxis dimension MachinesMember |
It is possible to specify that a concept aspect or an explicitDimension aspect
<veria:member>
applies to
a hierarchy of concepts specified by relationships.
If no
@axis attribute is provided, then the
@href attribute is the
specified concept value for a concept aspect or member for
an explicitDimension aspect.
If an
@axis is provided, then the concepts or members identified by the
@axis attribute, as related to the
@href specified concept or member,
are values of this aspect model.
The concept of axis as used in this specification is based on XPath's notion of axes (and has no relationship to multi-dimensional accounting notions of hypercubes or XBRL taxonomies that use the word axis to mean an XBRL dimension).
The content of the
@axis attribute can be:
child-or-self, representing concepts or members that are the
conceptIdentifier or
memberIdentifier
or its child in the
@linkrole and
@arcrole specified.
child, representing concepts that are children of the
conceptIdentifier or
memberIdentifier in the
@linkrole and
@arcrole specified.
descendant, representing concepts that are descendants of the
conceptIdentifier or
memberIdentifier in the
@linkrole and
@arcrole specified.
descendant-or-self, representing concepts that are the
conceptIdentifier or
memberIdentifier or its descendant in the
@linkrole and
@arcrole specified.
DRS-child-or-self, representing concepts that are the
conceptIdentifier or
memberIdentifier
or its DRS child in the
@linkrole specified.
DRS-child, representing concepts that are DRS children of the
conceptIdentifier or
memberIdentifier in the
@linkrole specified.
DRS-descendant, representing concepts that are DRS descendants of the
conceptIdentifier or
memberIdentifier in the
@linkrole specified.
DRS-descendant-or-self, representing concepts that are the
conceptIdentifier or
memberIdentifier or its DRS descendant in the
@linkrole specified.
Both
@linkrole and
@arcrole MUST be specified for concept
aspects that have an
@axis attribute with a non-DRS value.
The appropriate errors are defined in Section 3.3.1
The non-DRS axes do not respect
@xbrldt:targetRole on dimensional relationship sets.
The DRS axes do respect the dimensional relationship set formed by
dimensional arcs respecting
@xbrldt:targetRole attributes. (Note that arcrole is required for
the concept aspect although it is not required for a similar member construct of the explicit dimension
aspect. This is necessary to allow a primary item hierarchy to be used, which would, if arcrole were not
required, include has-hypercube relationship descendants in addition to a desired primary
item hierarchy.)
When specifying
@linkrole and
@arcrole there are conditions for when it is also necessary
to specify the
@link and
@arc elements, to disambiguate base sets identified by the link- and arc roles.
The
@link and
@arc attributes are URIs of the schema definition of link and arc elements
which are respectively required only when:
<link:presentationLink>
or in other than a
<link:presentationArc>
), or
If a concept aspect is specified with an
@axis attribute, it
MAY identify multiple concept aspect member values (such as child or descendant axes).
Error code veriae:bad-link-element
MUST be thrown if
the
@link attribute identifies an element that is not a
link element.
Error code veriae:bad-arc-element
MUST be thrown if
the
@arc attribute identifies an element that is not an
arc element.
Error code veriae:missingAxisLinkroleAttribute
MUST be thrown if
a
<veria:concept>
or a
<veria:explicitDimension>
element contains an
@axis attribute and
is missing
@linkrole, or .
Error code veriae:missingAxisArcroleAttribute
MUST be thrown if
a
<veria:concept>
or a
<veria:explicitDimension>
element contains an
@axis attribute with a non-DRS axis value and
is missing
@arcrole.
Error code veriae:bad-uri
MUST be thrown if
a
@linkrole or
@arcrole attribute is NOT an absolute URI defined for
and used by the appropriate DTS.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).
This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).
This document could not have been written without the contributions of many people including the participants in the Versioning Working Group.
| Date | Author | Details |
|---|---|---|
| 20 December 2009 | Herm Fischer |
Genesis based on suggestion by Maciej Piechocki, working group discussions at CEBS November 2009, and VWG e-mails in December 2009. |
| 21 December 2009 | Herm Fischer |
Enhanced descriptions of aspects and examples. |
| 14 February 2010 | Herm Fischer |
Fixed element and attribute xml codes formatting. Added optional explicitDimension attributes link and arc required only when standard link or arc roles are used on non-customary elements, and for generic link and arc roles used on multiple elements. Fixed typo example 5, member 66, removed axis. Initial specification of veria:hypercube, for the reporting of events concerning hypercube semantics that are not expressable by simple dimension attributes. |
| 15 February 2010 | Herm Fischer |
Clarified and separated of aspect model events from hypercube model events. |
| 21 February 2010 | Herm Fischer |
For explicitDimension, to facilitate axes that are domain-relationship-sets (respecting targetRole in domain-member relationship sets, alternate @DRS-axis is defined. Improved text according to comments by Roland Hommes per e-mail 2010-02-16. |
| 28 February 2010 | Herm Fischer |
Improved text according to comments by Haiko Philipp per e-mail 2010-02-25. Reorganized section 3 from aspect model, individual aspects, hypercube model, to individual aspects first, then the two models (aspect and hypercube). Added example HP2. |
| 29 May 2010 | Herm Fischer |
Renamed and revised per Brussels F2F 2010-05-25, to reconsider aspects model as an instance aspects versioning module, and discontinue hypercube model. Added a relationship-sets module/model, of concept-to-concept relationships, which allows DTS authors to document changes to base sets and dimensional relationship sets, replacing use of the prior hypercube model for documenting extended link roles and their dimensional relationships. Added that location aspect can be used as an attribute predicate (instead of elements predicate as previously described) with example in dimensions overview document. Added relationship set option to concept aspect, so that it may apply to a hierarchy of concepts in a base set or dimensional relationship set of relationships. |
| 07 June 2010 | Roland Hommes |
Textual edits and comments placed. |
| 10 July 2010 | Herm Fischer |
Textual edits, and location aspect XPath context item clarified. |
| 19 July 2010 | Herm Fischer |
Editorial improvements per feedback by Suguru Washio, including adding comments on issues to be discussed. |
| 08 August 2010 | Herm Fischer |
Editorial improvements per feedback by Suguru Washio: Clarified example Example 8. |
| 29 August 2010 | Herm Fischer |
Merged |
This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Versioning Working Group up to and including 03 November 2010. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.
No errata have been incorporated into this document.