Copyright © 2009, 2010, 2011, 2012, 2013 XBRL International Inc., All Rights Reserved.
Circulation of this Recommendation is unrestricted. This document is normative. Recipients are invited to submit comments to versioning-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
This specification is a modular extension to the Versioning Base Specification [XVS-Base]. It specifies how to map and address changes to the aspects of fact items for a set of concepts using dimensional aspects, to document that changes have occurred between different DTSs which may indicate a change in the primary items and dimensions and domain-members which may distinguish fact items.
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 DTS Validation
2.2 Aspect Identifiers
2.3 Aspect Model Events
2.3.1 Event usage
2.3.2 Fact identification mappings
3 Syntax
3.1 Aspects
3.1.1 Concept Aspect
3.1.2 Explicit Dimension Aspect
3.1.2.1 Explicit Dimension Members
3.1.3 Typed Dimension Aspect
3.2 Aspect model
3.3 Related Concepts
A 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 Concept aspect
2 Explicit Dimension aspect
3 Typed Dimension aspect
4 Typed Dimension Aspect Change
5 Aspect Model
aspect
aspect-equivalent facts
aspect-identifier
aspect-model
explicit-dimension-identifier
fact-identification mappings
member-identifier
typed-dimension-identifier
verdime:duplicateExplicitDimensionAspect
verdime:duplicateTypedDimensionAspect
verdime:invalidArcElement
verdime:invalidExplicitDimensionIdentifier
verdime:invalidLinkElement
verdime:invalidTypedDimensionIdentifier
verdime:invalidURI
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 communicate information about the detail of any arc relationships that compose these models in XBRL taxonomies. Taxonomy maintainers MAY require Versioning Reports that document relationships between concepts of a dimensional or non-dimensional nature. The reporting of such changes may be covered by a future specification, but is not within the scope of this specification.
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
of a versioning report would be referred to as <ver:report> .
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 non-normative example.
The following highlighting is used for non-normative examples of poor, discouraged or disallowed usage.
Text of the discouraged example.
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, member and default 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.
This specification includes changes in the concept, typed dimension and explicit dimension aspects. It is anticipated that changes involving other aspects, such as tuple location, entity, period, and unit may be included in futher specifications.
An aspect model, as specified by 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 DTSs. 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 DTSs which are the subject of a Versioning Report.
For example, an instance based on Version 1 of a DTS could contain facts with concept aspect A which are aspect equivalent to facts with concept X and Dimension D = d1 in Version 2 instances. Facts with concept aspect B in instances based on Version 1 of a DTS, are equivalent to facts with concept X and Dimension D = d2 in Version 2 instances, and so on.
A member identifier, as used in this specification, is a
concept identifier for a concept
in the xbrli:item substitution group that can be used in conjunction with a dimension as contextual aspects on a fact.
It is subject to the validation rules for a
concept identifier.
An explicit dimension identifier, as used in this specification, is a
concept identifier for a concept
in the xbrldt:dimensionItem substitutionGroup that does not have the @xbrldt:typedDomainRef attribute.
It is subject to the validation rules for a
concept identifier.
A typed dimension identifier, as used in this specification, is a
concept identifier for a concept
in the substitutionGroup xbrldt:dimensionItem and has the @xbrldt:typedDomainRef attribute.
It is subject to the validation rules for a
concept identifier.
An aspect identifier as used in this specification is the combination of one more of the specific aspect identifiers defined in this or subsequent specifications that can be used together to identify a set of aspect-equivalent facts.
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 |
|---|---|
verdim |
http://xbrl.org/2013/versioning-dimensions |
verdime |
http://xbrl.org/2013/versioning-dimensions/error |
xs |
http://www.w3.org/2001/XMLSchema |
link |
http://www.xbrl.org/2003/linkbase |
gen |
http://xbrl.org/2008/generic |
ver |
http://xbrl.org/2013/versioning-base |
vere |
http://xbrl.org/2013/versioning-base/error |
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.
The aspect model tracks changes of aspects and supports the mapping of instance information. The model can specify 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 XBRL concepts with dimensions [XBRL 2.1] is documented with the Concept Use Specification [XVS-Concept-Use] and Concept Details Specification [XVS-Concept-Details].
Because this specification addresses dimensional material, each DTS Identifier MUST identify a DTS that is dimensionally valid according to the rules described in the XBRL Dimensions Specification [DIMENSIONS]. Error code vere:invalidDTSIdentifier, as defined in [XVS-Base], is raised otherwise. Note that this is a tightening of the rules for DTS validation required by [XVS-Base].
| Name | Element | Identification |
|---|---|---|
| concept aspect | <verdim:concepts> |
concept identifier and optional related concept specifications (as per Section 3.3) |
| explicitDimension aspect (one aspect per dimension) |
<verdim:explicitDimension> ,
<verdim:member>
|
explicit dimension identifier and member identifier with optional related concept specifications (as per Section 3.3). |
| typedDimension aspect (one aspect per dimension) | <verdim:typedDimension> |
typed dimension identifier and XML fragment |
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.3.2.
| Code | Element | From Identifier | To Identifier |
|---|---|---|---|
| [AspectModelChange] | <verdim:aspectModelChange> |
AspectIdentifier | AspectIdentifier |
| [AspectModelAdd] | <verdim:aspectModelAdd> |
AspectIdentifier | |
| [AspectModelDelete] | <verdim:aspectModelDelete> |
AspectIdentifier |
The AspectModelChange event is intended to specify two combinations of aspects, one of which has superseded the other. The aspect identifiers on each side of the event can be used to select two sets of aspect-equivalent facts. Depending on the size of these sets and the aspects involved, this MAY allow software to work out an automated mapping from facts with the former aspect model to the current one.
The AspectModelAdd event is intended to convey the introduction of a newly allowed combination of aspects, without specifying that this be applied to any particular set of previously present facts.
The AspectModelDelete event is intended to convey that a combination of aspects is no longer to be reported, without specifying a new combination of aspects to be used instead.
Fact identification mappings establish means of identifying facts that have equivalence in different instances referenced by two versioned DTSs.
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.)
Aspect model mapping information, which MAY include dimensional representation of a set of concepts, is obtained from the Versioning Report as follows:
<verdim:fromAspects> element of a
AspectModelChange event
and the
<verdim: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 allowed and disallowed dimensional aspect combinations.
When there are multiple aspects reported for the same
<verdim:fromAspects> or <verdim:toAspects> element, these aspects are
all required to be present together to identify pertinent facts. In this way they behave as composite restricting filters.
This allows the precise identification of facts with certain values for their concept and a specific combination of dimensional values.
The individual aspects are introduced first, with examples pertaining to individual aspects alone, and then examples are given showing the use of multiple aspects and the change from one aspect model to another.
The syntax for the
<verdim:concepts> element
is defined by the normative schema supplied with this specification.
The value for this aspect is the union of all concepts identified by the
<verdim:concept> child elements
of the <verdim:concepts> element. Multiple such child elements
can be reported to indicate that facts that match any one of them are identified by this aspect.
Each <verdim:concept> element identifies a DTS concept by the
@name attribute.
For convenience and brevity of reporting it is possible to specify that the value for this aspect
is a set of concepts related in some network in the DTS. This is achieved by combining the concept @name attribute
with a nested <verdim:network> or <verdim:drsNetwork> , as described in Section 3.3.
If no nested network element is provided, then the @name attribute is the single
specified concept value identified by this <verdim:concept> element.
| Aspect | Reference |
|---|---|
|
<verdim:concepts>
<verdim:concept name="dts:ConceptA"/> <verdim:concept name="dts:ConceptB"/> </verdim:concepts> |
The concept aspect of this aspect model is ConceptA or ConceptB. |
|
<verdim:concepts>
<verdim:concept name="dts:ConceptA"> </verdim:concepts><verdim:network axis="descendant-or-self" arc="link:presentationArc" arcrole="http://www.xbrl.org/2003/arcrole/parent-child" link="link:presentationLink" linkrole="http://www.xbrl.org/2003/role/link"/> </verdim:concept> |
The concept aspect of this aspect model is ConceptA or any of its descendants in the presentation network in the standard link role. |
The syntax for the
<verdim:explicitDimension> element
is defined by the normative schema supplied with this specification.
The explicit dimension identifier for this aspect is identified by the @name attribute.
The @name attribute is a concept identifier and MUST resolve to a valid concept definition in the substitutionGroup xbrldt:dimensionItem which does not
have the @xbrldt:typedDomainRef attribute, and which is in:
Error code verdime:invalidExplicitDimensionIdentifier is raised otherwise.
Each explicit dimension is deemed a separate aspect of a fact. The specification for this aspect is contained within a single
<verdim:explicitDimension> element.
Accordingly there MUST be at most one <verdim:explicitDimension>
reported for each dimension concept within any given <verdim:toAspects> or <verdim:fromAspects> element.
Error code verdime:duplicateExplicitDimensionAspect is raised otherwise.
The <verdim:explicitDimension> element may have zero or more <verdim:member> elements.
<verdim: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).
<verdim:member> element is provided,
then that is the one dimension member that identifies the to/from fact
being identified.
<verdim:member> elements are provided, they represent alternatives of member
values for this dimension aspect.
A dimension aspect specified for <verdim: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 <verdim:member> element of the
explicitDimension aspect is identified by the @name attribute.
As with the concept aspect, it is possible to specify a set of related concepts
by means of a nested <verdim:network> or <verdim:drsNetwork> ,
as defined in Section 3.3.
If no related concepts are specified, then this member element is the
specified member value for this explicitDimension aspect.
If related concepts are specified, then the members thus identified
are all alternatives member values for this explicitDimension aspect, just as if multiple <verdim:member> elements had been provided.
The explicit dimension members are specified regardless of whether they are the default member or not, since this property has no bearing on the identification of aspect-equivalent facts.
| Aspect | Reference |
|---|---|
|
<verdim:explicitDimension name="dts:Dimension1">
<verdim:member name="dts:Member2"/> </verdim:explicitDimension> |
The explicit dimension aspect for the Dimension1 dimension element of this aspect model is the dimension member Member2. |
|
<verdim:explicitDimension name="dts:Dimension1"> <verdim:member name="dts:Total"> </verdim:explicitDimension><verdim:drsNetwork axis="descendant-or-self" linkrole="http://www.xbrl.org/2003/role/link"/> </verdim:member><verdim:explicitDimension name="dts:Dimension2">
<verdim:member name="dts:Member2"/> </verdim:explicitDimension> |
The aspect model identifies facts which have the concept Total or its descendants in the domain-member hierarchy as a member of Dimension 1, and also Member2 as a member of Dimension2. Facts which only report one of these dimensions are not identified by this aspect model. |
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:explicitDimension name="dts:Country"> </verdim:fromAspects><verdim:member name="dts:Czechoslovakia"/> </verdim:explicitDimension><verdim:toAspects> </verdim:aspectModelChange><verdim:explicitDimension name="dts:Country"> </verdim:toAspects><verdim:member name="dts:CzechRepublic"/> <verdim:member name="dts:Slovakia"/> </verdim:explicitDimension> |
The aspect model change event specifies that the Country dimension member Czechoslovakia has split into two members CzechRepublic and Slovakia. |
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:explicitDimension name="dts:Country"> </verdim:fromAspects><verdim:member name="dts:CzechRepublic"/> <verdim:member name="dts:Slovakia"/> </verdim:explicitDimension><verdim:toAspects> </verdim:aspectModelChange><verdim:explicitDimension name="dts:Country"> </verdim:toAspects><verdim:member name="dts:CzechSlovHyperUnion"/> </verdim:explicitDimension> |
The aspect model change event specifies that the Country dimension members CzechRepublic and Slovakia have merged to the imaginary future new member CzechSlovHyperUnion. |
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:concepts> <verdim:concept name="dts:PrimaryItemA"/> </verdim:concepts><verdim:explicitDimension name="dts:Dimension1"> </verdim:fromAspects><verdim:member name="dts:MemberA"/> </verdim:explicitDimension><verdim:toAspects> </verdim:aspectModelChange><verdim:concepts> <verdim:concept name="dts:PrimaryItemA"/> </verdim:concepts><verdim:explicitDimension name="dts:Dimension1"> </verdim:toAspects><verdim:member name="dts:MemberC"/> </verdim:explicitDimension> |
Assume a model in which a primary item PrimaryItemA can have MemberA or MemberB for Dimension1 in the fromDTS but in the toDTS MemberA is replaced by MemberC. The aspect model change event here shows only the aspect which is changed as this is sufficient for fact identification mapping change tracking. There is only one change event, from the combination of PrimaryItemA as the concept aspect, and MemberA in Dimension1 for the dimension aspect, to an aspect model of PrimaryItemA and MemberC in Dimension1. Note that for fact identification mapping purposes, no change event is documented for the combination of PrimaryItemA, MemberB in Dimension1, as this aspect model has not changed. |
|
<verdim:aspectModelDelete>
<verdim:fromAspects> </verdim:aspectModelDelete><verdim:concepts> <verdim:concept name="dts:PrimaryItemA"/> </verdim:concepts><verdim:explicitDimension name="dts:Dimension1"> </verdim:fromAspects><verdim:member name="dts:MemberA"/> </verdim:explicitDimension> |
Assume a model in which PrimaryItemA can have Dimension1 members MemberA and MemberB in the fromDTS, but in the toDTS MemberA is excluded. This event specifies the aspect model of PrimaryItemA, Dimension1 with MemberA, 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 PrimaryItemA with Dimension member MemberB as its fact identification aspects are unchanged. |
|
<verdim:aspectModelDelete>
<verdim:fromAspects> </verdim:aspectModelDelete><verdim:explicitDimension name="dts:D"> <verdim:member name="dts:DMem1"/> </verdim:explicitDimension><verdim:explicitDimension name="dts:E"> </verdim:fromAspects><verdim:member name="dts:EMem2"/> </verdim:explicitDimension> |
Assume an aspect model in which in the fromDTS dimension D with members DMem1 or DMem2, and dimension E with members EMem1 or EMem2 are allowed. The toDTS excludes only the combination of D with DMem1 and E with EMem1 together. This is documented by deleting the specific combination D, DMem1 and E, EMem1 in the toDTS aspect model. In the absence of other events it should be understood that there has been no change in the permissibility of DMem1 and EMem1 as dimension members when used outside this specific combination. |
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 Concept Use Specification [XVS-Concept-Use] and Concept Details Specification [XVS-Concept-Details]. Versioning Report information on arcs that represent syntactical construction of dimensions and membership MAY be supported by a future specification. Versioning Report information on semantic validation rules for hypercubes are reported using the aspect model of this specification.
The syntax for the
<verdim:typedDimension> element
is defined by the normative schema supplied with this specification.
The typed dimension identifier for this aspect is identified by the @name attribute.
The @name attribute is a concept identifier and MUST resolve to a valid concept definition in the substitutionGroup xbrldt:dimensionItem which has a
@xbrldt:typedDomainRef attribute, and which is in:
Error code verdime:invalidTypedDimensionIdentifier is raised otherwise.
As with explicit dimensions, each typed dimension is deemed a separate aspect of a fact. The specification for this aspect is contained within a single
<verdim:typedDimension> element.
Accordingly there MUST be at most one <verdim:typedDimension>
reported for each dimension concept within any given <verdim:toAspects> or <verdim:fromAspects> element.
Error code verdime:duplicateTypedDimensionAspect is raised otherwise.
The value of the typed dimension is provided
by the XML fragment contained by the
<verdim: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).
| Aspect | Reference |
|---|---|
|
<verdim:typedDimension
xmlns:honahLee="http://www.honahLee.com" name="dts:DragonDimension"> <honahLee:dragon name="Puff"/> </verdim:typedDimension> |
The typed dimension aspect for the DragonDimension dimension value
of this aspect model is the xml fragment <honahLee:dragon name="Puff"> . |
When there is a change in a typed dimension's typed domain (the schema type of the element
identified by the @xbrldt:typedDomainRef)
then this should be reported as an aspect change. However there are no explicit
events defined for reporting on individual
XML schema elements and attributes composing the definition of a typed dimension's domain. A
Versioning Report processor
MAY discover the content model of such elements by inspection of
the typed domain element when notified of an aspect change event which identifies only the dimension, without
specification of a dimension value or a concept aspect. The example below illustrates such an event.
| Aspect | Reference |
|---|---|
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:typedDimension name="dts:DragonDimension"/> </verdim:fromAspects><verdim:toAspects> </verdim:aspectModelChange><verdim:typedDimension name="dts2:DragonDimension"/> </verdim:toAspects> |
There has been a change in the typed dimension DragonDimension.
No primary items are specified, so the change applies to all items which report the dimension.
No typed value is specified, so there is no specific value for which a change in usage is being reported.
As such this indicates a general change in this dimension and is the preferred mechanism for reporting a change in
the typed domain of a typed dimension.
|
The aspects identified by the aspect model of
<verdim:fromAspects> and
<verdim:toAspects> elements
are declared by the aspect elements ( Section 3.1)
(corresponding to aspects of Table 2).
These aspects are combined by "anding" to the others specified within the same element.
Whereas most of the examples in the previous section ( Section 3.1) addressed single aspect changes, this section provides examples where multiple aspects are combined.
| Aspect | Example |
|---|---|
|
<verdim:aspectModelChange>
<verdim:fromAspects> <verdim:concepts> </verdim:fromAspects><verdim:concept name="dts:MachinesGross"/> </verdim:concepts><verdim:toAspects> </verdim:aspectModelChange><verdim:concepts> <verdim:concept name="dts:PPEGross"/> </verdim:concepts><verdim:explicitDimension name="dts:PPEAxis"> </verdim:toAspects><verdim:member name="dts:MachinesMember"/> </verdim:explicitDimension> |
Assume that in the non-dimensional fromDTS, there is a hierarchy of concepts to represent breakdown of information: PPEGross->MachinesGross, where PPEGross is a parent and MachineGross a child concept (in the presentation and summation hierarchies). With the dimensional toDTS, fact items of the prior MachinesGross breakdown become fact items of the prior parent PPEGross concept with the member MachinesMember of the PPEAxis dimension. 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 the <verdim:concept> of a concept aspect or the <verdim:member> of an explicitDimension aspect
applies to a hierarchy of concepts by means of either a <verdim:network> or <verdim:drsNetwork> child element.
If no such child element is provided, then the @name attribute is the
specified concept value for a concept aspect or member for
an explicitDimension aspect.
Note that this mechanism is purely a means of identifying concepts for use in an aspect model. It does not convey any versioning information about any of the networks of relationships referenced.
If a <verdim:network> or <verdim:drsNetwork> is provided, then the concepts or members identified by the
@axis attribute on that element, as related to the
@name 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
concept identifier or
member identifier
or its child in the network specified.
child, representing concepts that are children of the
concept identifier or
member identifier in the
network specified.
descendant-or-self, representing concepts that are the
concept identifier or
member identifier or its descendants in the
network specified.
descendant, representing concepts that are descendants of the
concept identifier or
member identifier in the
network specified.
The <verdim:drsNetwork> is used to define dimensional relationship sets in a domain-member hierarchy. The <verdim:network> is used
to define any network, and accordingly requires more information to be specified.
As well as @axis the @linkrole attribute must be specified on both elements. This is the URI of the extended link role in which related concepts are
identified. The differences between <verdim:drsNetwork> and <verdim:network> are as follows:
@xbrldt:targetRole switches on dimensional relationship sets when used on an <verdim:drsNetwork> . @arcrole attribute is required on a <verdim:network> . <verdim:drsNetwork> the link is fixed as <link:definitionLink> , the arc as <link:definitionArc> and the arcrole as
http://xbrl.org/int/dim/arcrole/domain-member.
When supplied, the value of a @linkrole or @arcrole attribute MUST be an absolute URI defined for
and used by the appropriate DTS.
Error code verdime:invalidURI is raised otherwise.
For the <verdim:network> there are conditions when it is necessary
to specify @link and @arc to disambiguate base sets identified by the link- and arc roles.
The @link and @arc attributes are QNames of link and arc elements respectively which are only required only when:
<link:presentationLink> or in other than a
<link:presentationArc> ), or
The @link attribute MUST be the QName of a link element.
Error code verdime:invalidLinkElement is raised otherwise.
The @arc attribute MUST be the QName of an arc element.
Error code verdime:invalidArcElement is raised otherwise.
The normative version of this schema can be found at
http://www.xbrl.org/2013/versioning-dimensions.xsd. For
convenience, a copy of the schema is included below.
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.
| 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 on aspect entity identifer. |
| 29 August 2010 | Herm Fischer |
Merged |
| 23 January 2011 | Herm Fischer |
Updated schema for QName concept identifier, dimension, member, link, arc, and unit. |
| 14 October 2011 | Hugh Wallis |
Corrected error codes Fixed references to other specs Minor editorial changes |
| 15 October 2011 | Hugh Wallis |
Added wording to make clear that the scenario and segment content is not made explicit per Roland Hommes. |
| 16 April 2012 | Richard Ashby |
Separated out the former Instance Aspects Spec into three more focussed specs: Dimensions, Tuples and other Instance Aspects. This, the Versioning Dimensions specification, has become the foundation specification for the versioning of fact aspects. Still contains the definitions of aspects and aspect change events, but the only aspect identifiers defined are those of concept, explicit dimensions, member and typed dimension. Created new namespace and namespace prefix of verdim for this spec and added a schema that matches the scope of the specification. |
| 27 April 2012 | Richard Ashby |
Added a container element verdim:concepts which can appear zero or once in an aspect event, and which contains as many concept elements as required to identify a range of concepts. It is now consistent that the immediate children of an aspect model add/change/delete event are to be ANDed together to restrict the range of identified facts. |
| 28 June 2012 | Richard Ashby |
Added |
| 09 July 2012 | Richard Ashby |
Clarified that the |
| 13 July 2012 | Stuart Barker |
Added validation that explicit an dimension identifier must point to a valid explicit dimension declaration in the relevant DTS. Changes discussed on call on 2012-05-01. |
| 16 July 2012 | Richard Ashby |
Renamed the various verdim:bad* error codes to verdim:invalid*, to make them consistent with the error codes in the other versioning specs. |
| 17 July 2012 | Richard Ashby |
Add requirement that the From-DTS and To-DTS must be dimensionally valid, and not just XBRL valid. Reuse existing error code vere:invalidDTSIdentifier from base spec so no new code defined. Added validation for invalid typed dimension identifiers as equivalent to the recently introduced validation for explicit dimensions. Added error code verdime:invalidTypedDimensionIdentifier. |
| 21 December 2012 | Richard Ashby |
Removed the incorrect suggestion of reporting changes in @typedDomainRef using custom attribute events, as such events are not permitted for attributes in the xbrldt namespace. Supplied description and example for alternative means of reporting such a change, using an aspect model change for the typed dimension, unqualified by concept or dimension value. |
| 08 January 2013 | Richard Ashby |
Updated schema namespace to http://xbrl.org/2013/versioning-dimensions and error namespace to http://xbrl.org/2013/versioning-dimensions/error. |
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 27 February 2013. 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.