Dimension Filters 1.1

Public Working Draft 20 July 2011

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

This version:
<http://www.xbrl.org/Specification/dimensionFilters/PWD-2011-07-20/dimensionFilters-PWD-2011-07-20.html>
Editors:
Phillip Engel, Morgan Stanley <phillip.engel@morganstanley.com>
Herm Fischer, Mark V Systems (formerly with UBmatrix) <fischer@markv.com>
Victor Morilla, Banco de España <victor.morilla@bde.es>
Jim Richards, JDR & Associates <jdrassoc@iinet.net.au>
Geoff Shuetrim, Galexy <geoff@galexy.net>
David vun Kannon, PricewaterhouseCoopers LLP <david.k.vunkannon@us.pwc.com>
Hugh Wallis, XBRL International <hughwallis@xbrl.org>
Contributors:
Cliff Binstock, Coyote Reporting <cliff.binstock@coyotereporting.com>
Paul Bull, Morgan Stanley <paul.bull@morganstanley.com>
Masatomo Goto, Fujitsu <mg@jp.fujitsu.com>
Walter Hamscher, Standard Advantage / Consultant to PricewaterhouseCoopers LLP <walter@hamscher.com>
Ignacio Hernández-Ros, Reporting Estandar S.L. <ignacio@hernandez-ros.com>
Roland Hommes, Rhocon <roland@rhocon.nl>
Andy Harris, UBMatrix <andy.harris@ubmatrix.com>
Takahide Muramoto, Fujitsu <taka.muramoto@jp.fujitsu.com>
Hitoshi Okumura, Fujitsu <okmr@jp.fujitsu.com>
Pablo Navarro Salvador, Atos Origin sae <pablo.navarro@atosorigin.com>
Michele Romanelli, Banca d'Italia <michele.romanelli@bancaditalia.it>
Nathan Summers, CompSci Resources <nathan.summers@compsciresources.com>
Masaru Uchida, Fujitsu <m-uchida@jp.fujitsu.com>

Status

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 formula-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This specification is an extension to the XBRL Variables Specification [VARIABLES]. It defines XML syntax for filters that condition on dimension information, as defined in the XBRL Dimensions Specification [DIMENSIONS], when selecting facts from input XBRL instances.

The filters defined in this specification facilitate selection of facts based on dimension information in both the input XBRL instance and in its supporting DTS. Both typed and explicit dimensions can be used to filter facts in the input XBRL instance.

Table of Contents

1 Introduction
1.1 Background
1.2 Relationship to other work
1.3 Language independence
1.4 Terminology
1.5 Document conventions (non-normative)
1.6 Namespaces and namespace prefixes
1.7 XPath usage
2 Syntax
2.1 Explicit dimension filter
2.1.1 Dimension Relationship Set Axes
2.2 Typed dimension filter

Appendices

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

Table

1 Namespaces and namespace prefixes

Examples

1 Explicit dimension filters
2 Typed dimension filters

Definitions

dimension filter
explicit dimension domain
explicit dimension filter
filter dimension
filter member
filter-member arcrole
filter-member axis
filter-member linkrole
filter-member network
filter-member set
filter-member value
typed dimension filter

Error codes

xbrldfe:DRSaxisFilterSpecifiesArcrole
xbrldfe:DRSaxisMissingFactVariableReference


1 Introduction

This specification is an extension to the XBRL Variables Specification [VARIABLES]. It defines XML syntax [XML] for filters that condition on dimensions [DIMENSIONS] when selecting facts from input XBRL instances.

All of the filters defined in this specification are referred to collectively as filter dimensions.

The filter dimension is the dimension being filtered by a dimension filter. This dimension is identified by the <df:dimension> child element of the dimension filter.

All dimension filters have a <df:dimension> element. That element specifies the filter dimension.

All of the filters defined in this specification can cover the dimension aspect for their filter dimension.

1.1 Background

This specification is a member of a suite of similar specifications that define specific types of criteria that can be used to select facts from input XBRL instances. It enhances the fact selection capabilities of the XBRL Variables Specification [VARIABLES].

1.2 Relationship to other work

This specification depends upon the XBRL Specification [XBRL 2.1], the XBRL Variables Specification [VARIABLES], and the XBRL Dimensions Specification [DIMENSIONS]. In the event of any conflicts between this specification and the specifications upon which it depends, this specification does not prevail.

1.3 Language independence

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

1.4 Terminology

This specification is consistent with the definitions of any of the terms defined in specifications that it depends on.

1.5 Document conventions (non-normative)

Documentation conventions follow those set out in the XBRL Variables Specification [VARIABLES].

1.6 Namespaces and namespace prefixes

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.

Table 1: Namespaces and namespace prefixes
Prefix Namespace URI
df http://xbrl.org/2008/filter/dimension
xbrldfe http://xbrl.org/2008/filter/dimension/error
eg http://example.com/
fn http://www.w3.org/2005/xpath-functions
link http://www.xbrl.org/2003/linkbase
xbrli http://www.xbrl.org/2003/instance
xfi http://www.xbrl.org/2008/function/instance
xbrldi http://xbrl.org/2006/xbrldi
xbrldt http://xbrl.org/2005/xbrldt
xl http://www.xbrl.org/2003/XLink
xlink http://www.w3.org/1999/xlink
xs http://www.w3.org/2001/XMLSchema
xsi http://www.w3.org/2001/XMLSchema-instance
gen http://xbrl.org/2008/generic
variable http://xbrl.org/2008/variable
iso4217 http://www.xbrl.org/2003/iso4217

1.7 XPath usage

XPath usage is identical to that in the XBRL Variables Specification [VARIABLES].

2 Syntax

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.

2.1 Explicit dimension filter

An explicit dimension filter is declared by a <df:explicitDimension> element.

The syntax for the <df:explicitDimension> element is defined by the normative schema supplied with this specification.

An explicit dimension domain is defined in the context of a given DTS as the set of all domain members in the union of all domains of valid members of the filter dimension.

The explicit dimension filter can be used to match facts with any one of the domain members in an explicit dimension domain as the value for that explicit dimension.

The XPath expression implied by a explicit dimension filter is determined by its <df:dimension> element and its <df:member> elements.

A filter member is a <df:member> child element of an explicit dimension filter.

A filter-member value is the domain member, in the explicit dimension domain, with a QName that is specified by a filter member.

In the implied XPath expressions below, a value needs to be determined for #dimension. If the <df:dimension> element has a <df:qnameExpression> child element, then #dimension is the QName returned by evaluating the XPath expression contained by the <df:qnameExpression> element. If the <df:dimension> element has a child <df:qname> element, then that <df:qname> element contains a QName. #dimension is then fn:QName(#namespace,#name)) where #namespace is the namespace of that QName value and #name is the local name of that QName value.

In the implied XPath expressions below, a #member value needs to be determined for each <df:member> child element of the explicit dimension filter. If the <df:member> element has a <df:qnameExpression> child element, then #member is the QName returned by evaluating the XPath expression contained by the <df:qnameExpression> element. If the <df:member> element has a child <df:qname> element, then that <df:qname> element contains a QName. #member is then fn:QName(#namespace,#name)) where #namespace is the namespace of that QName value and #name is the local name of that QName value. Otherwise, the <df:member> element has a child <df:variable> element and #member is the QName of the member that is the value of the filter dimension for fact bound to the variable named by the QName value of the <df:variable> element.

If the explicit dimension filter has no filter members then all domain members in the explicit dimension domain meet the filter criteria. The implied XPath expression is then:

xfi:fact-has-explicit-dimension(.,#dimension)

Otherwise, when the explicit dimension filter does have one or more filter members, each filter member in the explicit dimension filter implies a set of domain members that are allowed as values of the filter dimension. For such explicit dimension filters, the implied XPath expression is constructed by combining, using the XPath or operator, a set of terms, one for filter member.

The filter-member set for a filter member is the set of domain members that are allowed, by that filter member, as values of the filter dimension.

A filter-member linkrole is the value of the <df:linkrole> child element of a filter member.

A filter-member arcrole is the value of the <df:arcrole> child element of a filter member.

A filter-member axis is the value of the <df:axis> child element of a filter member.

If a filter member does not contain a filter-member linkrole, arcrole and axis, then the only domain member in its filter-member set is the domain member identified by the filter-member value.

The term in the implied XPath expression for that filter member is then:

xfi:fact-has-explicit-dimension-value(.,#dimension,#member)

Otherwise, the domain members in its filter-member set are determined based upon the network of relationships specified by the filter-member linkrole and the filter-member arcrole.

The filter-member network is the network of relationships expressed by arcs with the filter-member arcrole in extended links with the filter-member linkrole.

If the @axis attribute on a filter member equals child, then the filter-member set includes those domain members in the explicit dimension domain that are targets of relationships in filter-member network that run from the domain member identified by the filter-member value.

If the @axis attribute on a filter member equals child-or-self, then the filter-member set includes the domain member identified by the filter-member value and those domain members in the explicit dimension domain that are targets of relationships in filter-member network that run from the domain member identified by the filter-member value.

If the @axis attribute on a filter member equals descendant, then the filter-member set includes those domain members in the explicit dimension domain that are descendants,in the filter-member network, of the domain member identified by the filter-member value.

If the @axis attribute on a filter member equals descendant-or-self, then the filter-member set includes includes the domain member identified by the filter-member value and those domain members in the explicit dimension domain that are descendants,in the filter-member network, of the domain member identified by the filter-member value.

The term in the implied XPath expression, for each such filter member is:

( if (xfi:fact-has-explicit-dimension(.,#dimension)) then ( some $member in xfi:filter-member-network-selection(#dimension,#member,#linkrole,#arcrole,#axis) satisfies (xfi:fact-explicit-dimension-value(.,#dimension) eq $member) ) else fn:false() )

where #axis is equal to the filter-member axis, #linkrole is equal to the filter-member linkrole, #arcrole is equal to the filter-member arcrole.

Example 1: Explicit dimension filters

Filter dimension Filter member @axis Selection criteria
eg:region None Facts must report a value for the eg:region dimension that are in the explicit dimension domain.
eg:region eg:australasia Facts must report a value for the eg:regiondimension that is the domain member eg:australasia.
eg:region eg:australasia child Facts must report a value for the eg:regiondimension that is one of the domain members with a relationship from the domain member eg:australasia that is in the network specified by the given filter-member linkrole and arcrole.
eg:region eg:australasia descendant Facts must report a value for the eg:regiondimension that is a descendant of the eg:australasia domain member in the network specified by the given filter-member linkrole and arcrole.
eg:region eg:australasia descendant-or-self Facts must report a value for the eg:regiondimension that is a descendant of the eg:australasia domain member in the network specified by the given filter-member linkrole and arcrole or that is eg:australasia.

2.1.1 Dimension Relationship Set Axes

Two additional values for the axis attribute are provided for filtering relationships of a Dimension Relationship Set (DRS) [DIMENSIONS Def,3]. For these axes, filter-member network is the set of relationships between valid members of the effective domain [DIMENSIONS Def,14] for the filter dimension in the DRS.

The relationship source is determined by the fact bound to the fact variable named by the QName value of the <df:member> element child <df:variable> . If that variable is not bound to a fact, (e.g., it has an atomic fallback value, then the filter-member network is empty. Error code xbrldfe:DRSaxisMissingFactVariableReference MUST be thrown if a <df:member> element with a DRS axis omits a child <df:variable> element, or if the value of the <df:variable> element is not a QName of a fact variable.

The primary item of the relationship source [DIMENSIONS Def,1] is the bound variable fact's concept.

The relationship target is determined by a candidate fact that is the context item of the filter. The primary item of the relationship target is the candidate fact's concept. The candidate fact's dimension member value is the relationship target member for the DRS-axis relationship.

Primary items (plural) refers to the relationship source bound fact variable's concept and context item of the filter candidate fact's concept.

If a <df:linkrole> element is present, then it specifies the base set in which the primary items are associated to the combination of hypercubes that is the 'head' of the DRS, e.g., the relationship source primary item concept is the DRS head primary item or inherits hypercubes from it, and the effective domain is consecutively related to that base set's hypercubes.

If the <df:linkrole> element is absent, then all DRS link roles that connect the primary items and specified dimension's domain contribute to the effective domain.

The <df:arcrole> element is not relevant for DRS relationship axes. The filter-member network is determined by the DRS network arcroles, for the relationships from the primary items, to the relationship source and target dimension member. If there are Error code xbrldfe:DRSaxisFilterSpecifiesArcrole MUST be thrown if a <df:member> element with a DRS axis has a child <df:arcrole> .

If the @axis attribute on a filter member equals DRS-child, then the filter-member set includes those domain members in the explicit dimension domain that are valid child consecutive-relationship targets.

If the @axis attribute on a filter member equals DRS-descendant, then the filter-member set includes those domain members in the explicit dimension domain that are valid descendant consecutive-relationship targets.

The filter member network includes all domain-member consecutive relationships (child or descendant) in the effective domain, from the relationship source's dimension member (valid for the relationship source primary item), to the relationship target's dimension member (valid for the context item fact's primary item).

The term in the implied XPath expression, for each such filter member may be (but is not suggested for implementation, as this is unlikely to be as efficient as an API-based implementation):

( if (xfi:fact-has-explicit-dimension(.,#dimension)) then ( some $member in xfi:filter-member-DRS-selection( #dimension, node-name(.), xfi:fact-explicit-dimension-value(#variable,#dimension), #linkrole, #axis) satisfies (xfi:fact-explicit-dimension-value(.,#dimension) eq $member) ) else fn:false() )

where #axis is equal to the filter-member axis, #variable is equal to the fact bound to the variable named by the QName value of the <df:variable> element, #linkrole is equal to the filter-member linkrole if a <df:linkrole> element is present, otherwise an empty sequence.

2.2 Typed dimension filter

A typed dimension filter is declared by a <df:typedDimension> element.

The syntax for the <df:typedDimension> element is defined by the normative schema supplied with this specification.

The typed dimension filter can be used to match facts based upon the value for a typed dimension.

If the typed dimension filter does not contain a @test attribute, then its implied XPath expression is then:

xfi:fact-has-typed-dimension(.,#dimension)

where #dimension is determined as specified for explicit dimension filters.

If the typed dimension filter does contain a @test attribute, then its implied XPath expression is then:

( xfi:fact-has-typed-dimension(., #dimension) and xfi:fact-typed-dimension-value(., #dimension)[#test] )

where #dimension is determined as specified for explicit dimension filters and #test is the value of the @test attribute on the typed dimension filter.

The implied XPath expression evaluates to true for a fact if and only if:

  • the fact's concept is associated with the typed dimension identified by the QName implied by the typed dimension filter's @df:dimension element, and
  • the fact has a context that contains a value for the specified typed dimension that meets the conditions specified by the @test attribute.

Example 2: Typed dimension filters

Dimension QName @test Selection criteria
eg:altitude xs:boolean('true') Facts must be reported with a value specified for dimension eg:altitude
eg:altitude eg:height > 0 Facts must be reported with a value specified for dimension eg:altitude that is the <eg:height> element with a value that is greater than zero.

Appendix A Normative schema

The following is the XML schema provided as part of this specification. This is normative. Non-normative versions (which should be identical to these except for appropriate comments indicating their non-normative status) are also provided as separate files for convenience of users of the specification.

NOTE: (non-normative) Following the schema maintenance policy of XBRL International, it is the intent (but is not guaranteed) that the location of non-normative versions of these schemas on the web will be as follows:

  1. While any schema is the most current RECOMMENDED version and until it is superseded by any additional errata corrections a non-normative version will reside on the web in the directory http://www.xbrl.org/2008/ - during the drafting process for this specification this directory should contain a copy of the most recent published version of the schema at http://www.xbrl.org/2008/dimension-filter.xsd.
  2. A non-normative version of each schema as corrected by any update to the RECOMMENDATION will be archived in perpetuity on the web in a directory that will contain a unique identification indicating the date of the update.
<schema
xmlns
="http://www.w3.org/2001/XMLSchema"

xmlns:df
="http://xbrl.org/2008/filter/dimension"

xmlns:variable
="http://xbrl.org/2008/variable"
targetNamespace="http://xbrl.org/2008/filter/dimension" elementFormDefault="qualified">
<import namespace="http://www.xbrl.org/2003/XLink" schemaLocation="http://www.xbrl.org/2003/xl-2003-12-31.xsd"/>
<import namespace="http://xbrl.org/2008/variable" schemaLocation="variable.xsd"/>
<complexType id="xml-dimension-model" name="dimension.model">
<choice>
<element name="qname" type="QName"/>
<element name="qnameExpression" type="variable:expression"/>
</choice>
</complexType>
<complexType name="member.model">
<sequence>
<choice>
<element name="variable" type="variable:QName"/>
<element name="qname" type="QName"/>
<element name="qnameExpression" type="variable:expression"/>
</choice>
<sequence minOccurs="0" maxOccurs="1">
<element name="linkrole" type="anyURI"/>
<element name="arcrole" type="anyURI"/>
<element name="axis">
<simpleType>
<restriction base="token">
<enumeration value="child-or-self"/>
<enumeration value="child"/>
<enumeration value="descendant"/>
<enumeration value="descendant-or-self"/>
</restriction>
</simpleType>
</element>
</sequence>
</sequence>
</complexType>
<element id="xml-explicit-dimension-filter" name="explicitDimension" substitutionGroup="variable:filter">
<complexType mixed="true">
<complexContent mixed="true">
<extension base="variable:resource.type">
<sequence>
<element name="dimension" type="df:dimension.model"/>
<element name="member" type="df:member.model" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
</element>
<element id="xml-typed-dimension-filter" name="typedDimension" substitutionGroup="variable:filter">
<complexType mixed="true">
<complexContent mixed="true">
<extension base="variable:resource.type">
<sequence>
<element name="dimension" type="df:dimension.model"/>
</sequence>
<attribute name="test" type="variable:expression" use="optional"/>
</extension>
</complexContent>
</complexType>
</element>
</schema>

Appendix B References

DIMENSIONS
XBRL International Inc.. "XBRL Dimensions 1.0"
Ignacio Hernández-Ros, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm)
VARIABLES
XBRL International Inc.. "XBRL Variables 1.0"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/variables/REC-2009-06-22/variables-REC-2009-06-22.html)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1"
Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm)
XML
W3C (World Wide Web Consortium). "Extensible Markup Language (XML) 1.0 (Fourth Edition)"
Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau.
(See http://www.w3.org/TR/REC-xml/)
XML NAMES
W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Second Edition)"
Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin.
(See http://www.w3.org/TR/REC-xml-names/)
XML SCHEMA STRUCTURES
W3C (World Wide Web Consortium). "XML Schema Part 1: Structures Second Edition"
Henry S. Thompson, David Beech, Murray Maloney, and Noah Mendelsohn.
(See http://www.w3.org/TR/xmlschema-1/)

Appendix C Intellectual property status (non-normative)

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

Appendix D Acknowledgements (non-normative)

This document could not have been written without the contributions of many people including the participants in the Formula Working Group.

Appendix E Document history (non-normative)

DateAuthorDetails
23 April 2007Geoff Shuetrim

First internal working draft created, drawing on the use cases provided by Victor Morilla.

03 May 2007Geoff Shuetrim

Incorporated feedback on the implied XPath expression designs from Victor Morilla.

08 May 2007Geoff Shuetrim

Added clarification about the fact aspect covered by the filters defined in this specification.

18 May 2007Geoff Shuetrim

Modified the dimension-member filter to include the inclusive Boolean attribute and to cover the case where the <member> element is omitted. The changes were based on feedback on limitations of the filter identified in Herm Fischer's preparations for the 2007 Munich conference.

29 May 2007Geoff Shuetrim

Changed the target namespace of the normative schema again. Made the QName specification capable of covering static and dynamic QNames.

04 June 2007Geoff Shuetrim

Simplified the implied XPath expression for filters on typed dimensions.

11 June 2007Geoff Shuetrim

Clarified the explanation of the functions required to support the implied XPath expression for the explicit-dimension filter.

25 June 2007Geoff Shuetrim

Modified the information about implicit filter implications of dimension filters to allow for implicit filtering at the individual dimension level.

24 July 2007Hugh Wallis

Edited for public working draft publication.

05 November 2007Geoff Shuetrim

Converted the specification to XML format.

Added in the definitions and the hyperlinks to the relevant sections of the normative schema.

Removed the erroneous reference to the @dimension attribute in the typed dimension filter XPath explanation.

Eliminated default values for attribute values on the dimension member filter.

Modified the schema to create a single content model for all QName identifiers.

06 November 2007Geoff Shuetrim

Added the arcrole declaration for the filter-member arcrole to the normative schema for dimension filters. This forces filter-member relationships to be expressed by generic arcs.

12 November 2007Geoff Shuetrim

Linked all of the external terminology references back to bibliographic citations.

27 November 2007Jim Richards

Updated the abstract to include a reference to the Varaibles Spec.

Made some minor grammatical changes.

30 November 2007Geoff Shuetrim

Added examples.

06 December 2007Geoff Shuetrim

Added a <df:linkrole> element to the dimension member filter to ensure that all members are being selected from among those with domain-member relationships to the dimension that have the the specified link role. This prevents the filter from mixing up different networks of domain members for the one dimension.

20 January 2008Geoff Shuetrim

Made hyperlinks to the normative schema consistent throughout the document.

23 January 2008Geoff Shuetrim

Corrected the reference to a domain member filter instead of a dimension member filter in the definition of a recognised member of a dimension.

Corrected the definition of the a recognised member of a dimension to include all domain members in a hierarchy of domain-member relationships rather than just those domain members with a direct domain-member relationship to the dimension.

Corrected the obsolete reference to a @dimension attribute in the introduction, replacing it with <df:dimension> element.

As requested by Herm Fischer, the term "associated with" has been eliminated from the introduction because it was too loose. In its place is an explanation of the connection between dimensions and the segments and scenarios used to report them, along with sentences capturing the implications of that connection for the type of dimension aspects that can be covered by the filters in this specification.

24 January 2008Geoff Shuetrim

Made the required @inclusive and @childrenOnly attributes explicitly required in the normative schemas as per the suggestion from Victor Morilla.

30 January 2008Geoff Shuetrim

Responded to feedback from Herm Fischer and Victor Morilla to simplify the handling of filters that condition on the values of explicit dimensions. Specifically:

Removed the existing explicit dimension filter and its reliance on XLink relationships to determine the members being selected by the dimension filtering.

Modified the dimensionMember filter to allow dimension member filters to nominate just the identified member rather than the some set of members with domain-member XLink relationships to the identified member. This does not limit the existing ability to nominate such sets of members, however.

Change the name of the existing dimension member filter to explicit dimension filter given that it is now the only explicit dimension filter.

Simplified the syntax required to identify a dimension member value based upon the value of a specified dimension for another fact variable.

Reduced the dependency on boolean and filters to achieve complex selections of members for a given dimension.

Clarified the function name for the function that returns the recognised member QNames for a specified dimension QName and linkrole QName.

Added an extra parameter to the function that returns the recognised member QNames for a specified dimension QName and linkrole QName so that it internalises the complexity of determining whether to include children domain members or descendant domain members in the filter member set for an filter member in an explicit filter. This significantly reduces the complexity of expressing the implied XPath expression for explicit dimension filters.

31 January 2008Geoff Shuetrim

Renamed the @select attribute to the @axis attribute on the explicit dimension filter and change the enumeration values to more closely align with the axis names for XPath expressions as suggested by Herm Fischer.

As suggested by Herm Fischer, corrected the erroneous association of the filter linkrole with the linkrole on the extended links that contain arcs that express domain-member relationships and instead associated the filter linkrole with the linkrole on the extended links that contain arcs that express all relationships between primary items and hypercubes. This ensures that the filter linkrole is identifying meaningful domains of permitted domain members for the filter dimension on explicit dimension filters.

Aligned the explanation of the <df:qname> element to that provided for the same kind of element in the concept filter specification.

Removed the paragraphs on segment and scenario dimension aspects from the introduction as agreed by the working group.

Changed xs:QName() to fn:QName() as suggested by Masatomo Goto.

01 February 2008Geoff Shuetrim

Fixed the typed dimension filter example as suggested by Masatomo Goto to use xs:boolean('true') rather than true.

03 February 2008Victor Morilla

Fixed @axis values in example 1.

Removed references not cited.

05 February 2008Geoff Shuetrim

Changed the function signature for the xfi:has-dimension function to conform to the other concept property accessor functions. It now takes the concept QName as an argument rather than an XBRL fact.

Further simplified the XBRL functions supporting the explicit dimension filter.

25 February 2008Geoff Shuetrim

Restored the sentence to the introduction of the specification defining which aspects can be covered by explicit and typed dimension filters. This drafting regression, introduced on 23 January 2008, was identified by Herm Fischer.

27 February 2008Geoff Shuetrim

Added a @contextElement attribute to the dimension filters to simplify the determination of whether a given filter can cover a segment dimension aspect or a scenario dimension aspect. The aspect covering properties of a filter no longer dependent upon the facts being filtered. This dependency could have caused problems when using the filter with variables that bind as sequences. This modification has also required changing the function calls in the implied XPath expressions for the various filters.

20 March 2008Geoff Shuetrim

Fixed broken hyperlinks.

13 June 2008Geoff Shuetrim

Redesigned the implied XPath expressions for the filters so that exceptions are not being thrown because some facts in the instance being filtered are not permitted to have the dimension being used for filtering. The modification ensures that such facts are rejected by the filter rather than causing variable set evaluation to halt.

25 August 2008Geoff Shuetrim

Eliminated the @contextElement attribute to reflect the simplification of the dimensional aspect model to only have dimensions rather than differentiating segment and scenario dimensions.

Changed explicit dimension filters to be more flexible with regard to the way that they can utilise networks of relationships between domain members. Instead of working with domains defined in terms of a single conjunction of hypercubes, an explicit dimension filter defines a single comprehensive domain for the filter dimension and then allows filtrations to be expressed based upon selections from that comprehensive domain, using networks of relationships to determine the relevant selections from that comprehensive domain. These changes were motivated by feedback from the COREP and FINREP taxonomies provided by Victor Morilla. They enable various networks of domain-member relationships to be used for some filtering purposes and when those are not sufficient or are not designed in a way that supports the intended filtering, they allow other kinds of more specialised networks to be exploited to determine filtering behaviour.

27 August 2008Geoff Shuetrim

Fixed the various implied XPath expressions to complete adjustments to the specification to reflect the collapsing of segment and scenario dimension aspects into a single dimension aspect. Also modified the implied XPath expressions to reflect the fact that facts can have dimension aspects independent of the hypercube associations of their concept. These corrections were all made on the basis of feedback from Victor Morilla.

02 September 2008Geoff Shuetrim

Split the xfi:fact-has-dimension function to have one function for typed dimensions and one for explicit dimensions. This way, if the wrong kind of dimension is used for a dimension filter, that will trigger a error code when testing for the dimension.

05 September 2008Geoff Shuetrim

Rearranged paragraphs to ensure that the the definitions are provided before they are used in the explicit dimension filter section.

09 September 2008Geoff Shuetrim

Modified the definition of the explicit dimension domain to be expressed in terms of domains of valid members of explicit dimensions, as defined in [DIMENSIONS].

14 November 2008Geoff Shuetrim

Corrected references to the XDT specification to use the correct ID.

17 November 2008Geoff Shuetrim

Made the @variable attribute have type variable:QName because it contains variable name QNames that do not resolve according to the rules used for QNames with data type xs:QName. This change was suggested by Herm Fischer.

19 March 2009Geoff Shuetrim

Changed the term "target XBRL instance" to "input XBRL instance". Ensured that all usages of the terms input XBRL instance and output XBRL instance reference the term definition.

23 March 2009Geoff Shuetrim

Clarified, in the introduction, that the dimension filters can cover dimension aspects.

12 December 2009Herm Fischer

Added test attribute to explicitDimension filter (a post-Rec change).

10 March 2011Herm Fischer

Removed test attribute from explicitDimension filter pending further requirements study (prior to publication).

08 July 2011Herm Fischer

Added DRS-aware axes of DRS-child and DRS-descendant and section Section 2.1.1, comprising the 1.1 version revision to the original recommendation. This is necessary in order that explicit dimension filters can support aggregation for SEC and IFRS filings. It is neither reasonable or possible for the author of formulas for such filings to be aware of extension taxonomy link roles, or to entirely avoid use of targetRole in comprising consecutive relationships (as is the case with the axes of the 1.0 specification). It is also not possible to emulate DRS-aware filters with the 1.0 specification dimension or concept-relations filters and current xfi functions.

The DRS axes require that the member have a <df:variable> specifying the variable that is bound to the parent or ancestor fact, because it is necessary for this filter to know both its primary item concept and dimension member. The DRS axes do not require link role. Arc role is not relevant for the DRS axes.

11 July 2011Herm Fischer

Incorporated improvements suggested by Roland Hommes, clarifying DRS filter-member-network description.

12 July 2011Herm Fischer

Incorporated improvements suggested by Victor Morilla, adding DRS error conditions and further clarifying description.

18 July 2011Herm Fischer

Added example of XPath implementation for DRS axes.

Appendix F Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Formula Working Group up to and including 10 March 2011. 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.

NumberDateSectionsDetails
1.10 March 2011 Section 2.1

Removed invalidDomainMember error because this prevents formula processing of extended links which may or not have dimensions present in the networks, not known in advance to the formula author, such as with SEC and IFRS filings. Removed ambiguousFilterMemberNetwork error because its original purpose is no longer relevant or appropriate.