Copyright ©2008 XBRL International Inc., All Rights Reserved.
Circulation of this Candidate Recommendation 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.
This specification is an extension to the XBRL Variables 1.0 Specification [VARIABLES]. It defines syntax for filters that condition upon features of XBRL concept declarations, including the name, the period-type, the balance, the data type and the substitution group.
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 Concept name filter
2.2 Concept period-type filter
2.3 Concept balance filter
2.4 Concept custom-attribute filter
2.5 Concept data-type filter
2.6 Concept substitution-group filter
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
1 Concept name filters
2 Concept period-type filters
3 Concept balance filters
4 Concept custom-attribute filters
5 Concept data-type filters
6 Concept substitution-group filters
concept balance filter
concept custom attribute
concept custom-attribute filter
concept data-type filter
concept name filter
concept period-type filter
concept substitution-group filter
This specification is an extension to the XBRL Variables 1.0 Specification [VARIABLES]. It defines XML syntax [XML] for filters that condition upon features of XBRL concept declarations, including:
All of the filters defined in this specification can cover the concept aspect.
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 XBRL instances. It enhances the fact selection capabilities of the XBRL Variables Specification [VARIABLES].
This specification depends upon the XBRL Specification [XBRL 2.1], the XBRL Variables Specification [VARIABLES]. In the event of any conflicts between this specification and the specifications upon which it depends, this specification does not prevail.
The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.
This specification is consistent with the definitions of any of the terms defined in specifications that it depends on.
Documentation conventions follow those set out in the XBRL Variables Specification [VARIABLES].
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 |
|---|---|
cf
|
http://xbrl.org/2008/filter/concept
|
xbrlcfe
|
http://xbrl.org/2008/filter/concept/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
|
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.
A concept name filter is declared by a
<cf:conceptName>
element.
The syntax for the
<cf:conceptName>
element
is defined by the normative schema supplied with this specification.
The concept name filter matches facts based upon the names of their concepts.
The XPath expression implied by a concept name filter contains
one term for each of its child
<cf:concept>
elements,
where those terms are combined using the XPath or operator.
Each term in the implied XPath expression has one of two forms.
If the
<cf:concept>
element contains a
<cf:qnameExpression>
element, then the
term is:
(fn:node-name(.) eq #qnameExpression)
where #qnameExpression is the XPath expression contained by the
cf:qnameExpression element.
If the
<cf:concept>
element contains a
<cf:qname>
element,
then the term is:
(fn:node-name(.) eq fn:QName(#namespace,#name))
where #namespace is the namespace for the
QName specified as the content of the
<cf:qname>
element and #name is the local
name for the QName specified as the content of the
<cf:qname>
element.
| Filter1 | Selection criteria |
|---|---|
|
<cf:conceptName>
<cf:concept> </cf:conceptName><cf:qname> </cf:concept>eg:assets </cf:qname> |
The concept name must be eg:assets
|
|
<cf:conceptName>
<cf:concept> <cf:qname> </cf:concept>eg:assets </cf:qname><cf:concept> </cf:conceptName><cf:qnameExpression> </cf:concept>fn:QName('http://example.com/','eg:liabilities') </cf:qnameExpression> |
The concept name must be either eg:assets
or eg:liabilities
|
|
<cf:conceptName>
<cf:concept> </cf:conceptName><cf:qnameExpression> </cf:concept>fn:node-name($eg:a) </cf:qnameExpression> |
The concept name must be the same as the concept name
of the node accessed by the XPath variable reference
$a.
|
1. XLink attributes have been omitted.
A concept period-type filter is declared by a
<cf:conceptPeriodType>
element.
The syntax for the
<cf:conceptPeriodType>
element
is defined by the normative schema supplied with this specification.
The concept period-type filter can be used to match facts
based on whether they report values for duration-type or
instant-type concepts, as determined by the
@xbrli:periodType attribute.
The XPath expression implied by a concept period-type filter is:
xfi:concept-period-type(fn:node-name(.)) eq '#periodType'
where #periodType is the value of the
@periodType attribute
on the concept period-type filter.
A concept balance filter is declared by a
<cf:conceptBalance>
element.
The syntax for the
<cf:conceptBalance>
element is defined by the normative schema supplied with this specification.
The concept period-type filter can be used to match facts based on
whether they have an
@xbrli:balance attribute
and, if they have that attribute, whether it has a value of
debit or credit.
The XPath expression implied by a concept balance filter is:
if ('#balance' eq 'none')
then (xfi:concept-balance(fn:node-name(.)) eq '')
else (xfi:concept-balance(fn:node-name(.)) eq '#balance')
where #balance is the value of the
@balance attribute
on the concept balance filter.
| Filter1 | Selection criteria |
|---|---|
|
<cf:conceptBalance balance="credit"/>
|
The fact's concept must be classified as a credit balance concept |
|
<cf:conceptBalance balance="debit"/>
|
The fact's concept must be classified as a debit balance concept |
|
<cf:conceptBalance balance="none"/>
|
The fact's concept must not be classified as a credit or debit balance concept |
1. XLink attributes have been omitted.
A concept custom-attribute filter is declared by a
<cf:conceptCustomAttribute>
element.
The syntax for the
<cf:conceptCustomAttribute>
element is defined by the normative schema supplied with this specification.
The concept custom-attribute filter can be used to match facts based on the existence or value of a custom attribute in each concept's declaration. A concept custom attribute is an attribute on a concept declaration that is not in the XML Schema namespace [XML SCHEMA STRUCTURES] or in the XBRL namespace [XBRL 2.1].
If the
@value attribute is provided and
if the
<cf:attribute>
element contains a
<cf:qnameExpression>
element, then the implied XPath
expression is:
xfi:concept-custom-attribute(fn:node-name(.),#qnameExpression) eq #value
where #qnameExpression is the XPath expression contained by
the
<cf:qnameExpression>
element.
If the
@value attribute is provided and
if the
<cf:attribute>
element contains a
<cf:qname>
element, then the implied XPath expression is:
xfi:concept-custom-attribute(fn:node-name(.),fn:QName(#namespace,#name)) eq #value
where #namespace is the namespace for the QName specified as
the content of the
<cf:qname>
element and #name is the local
name for the QName specified as the content of the
<cf:qname>
element.
The required value for the custom attribute is supplied by the
XPath expression in the
@value attribute on the concept custom
attribute filter.
If the
@value attribute is not provided and
if the
<cf:attribute>
element contains a
<cf:qnameExpression>
element, then the implied XPath
expression is:
xfi:concept-custom-attribute(fn:node-name(.),#qnameExpression)
where #qnameExpression is the XPath expression contained by
the
<cf:qnameExpression>
element.
If the
@value attribute is not provided and
if the
<cf:attribute>
element contains a
<cf:qname>
element, then the implied XPath expression is:
xfi:concept-custom-attribute(fn:node-name(.),fn:QName(#namespace,#name))
where #namespace is the namespace for the QName specified as
the content of the
<cf:qname>
element and #name is the local
name for the QName specified as the content of the
<cf:qname>
element.
| Filter1 | Selection criteria |
|---|---|
|
<cf:conceptCustomAttribute>
<cf:attribute> </cf:conceptCustomAttribute><cf:qname> </cf:attribute>eg:custom </cf:qname> |
The fact's concept must have an
@eg:custom attribute on it. |
|
<cf:conceptCustomAttribute value="'confidential'">
<cf:attribute> </cf:conceptCustomAttribute><cf:qname> </cf:attribute>eg:custom </cf:qname> |
The fact's concept must have an
@eg:custom attribute on it
with string content: confidential. Note that it is necessary
to enclose the value in its own quotes to indicate that it is a string.
|
|
<cf:conceptCustomAttribute value="fn:false()">
<cf:attribute> </cf:conceptCustomAttribute><cf:qnameExpression> </cf:attribute>fn:QName('http://example.com/','custom') </cf:qnameExpression> |
The fact's concept must have an
@eg:custom attribute on it
with boolean content: false. |
1. XLink attributes have been omitted.
A concept data-type filter is declared by a
<cf:conceptDataType>
element.
The syntax for the
<cf:conceptDataType>
element is defined by the normative schema supplied with this specification.
The concept data-type filter can be used to match facts based upon its XML Schema data type (See [XML SCHEMA DATATYPES] and [XML SCHEMA STRUCTURES]).
If the
<cf:type>
element contains a
<cf:qnameExpression>
element and
the
@strict attribute on the
<cf:conceptDataType>
element
equals true, then the implied XPath expression is:
xfi:concept-data-type(fn:node-name(.)) eq #qnameExpression
where #qnameExpression is the XPath expression
contained by the
<cf:qnameExpression>
element.
If the
<cf:type>
element contains a
<cf:qnameExpression>
element and
the
@strict attribute on the
<cf:conceptDataType>
element
equals false, then the implied XPath expression is:
xfi:concept-data-type-derived-from(
fn:node-name(.),
#qnameExpression
)
where #qnameExpression is the XPath expression
contained by the
<cf:qnameExpression>
element.
If the
<cf:type>
element contains a
<cf:qname>
element and the
@strict attribute on the
<cf:conceptDataType>
element
equals true, then the implied XPath expression is:
xfi:concept-data-type(fn:node-name(.)) eq fn:QName(#namespace,#name))
where #namespace is the namespace for the QName specified as
the content of the
<cf:qname>
element and #name is the local
name for the QName specified as the content of the
<cf:qname>
element.
If the
<cf:type>
element contains a
<cf:qname>
element and the
@strict attribute on the
<cf:conceptDataType>
element
equals false, then the implied XPath expression is:
xfi:concept-data-type-derived-from(
fn:node-name(.),
fn:QName(#namespace,#name)
)
where #namespace is the namespace for the QName specified as
the content of the
<cf:qname>
element and #name is the local
name for the QName specified as the content of the
<cf:qname>
element.
| Filter1 | Selection criteria |
|---|---|
|
<cf:conceptDataType strict="true">
<cf:type> </cf:conceptDataType><cf:qname> </cf:type>xbrli:monetaryItemType </cf:qname> |
The data type of the fact's concept must be
@xbrli:monetaryItemType. |
|
<cf:conceptDataType strict="false">
<cf:type> </cf:conceptDataType><cf:qname> </cf:type>xbrli:pureItemType </cf:qname> |
The data type of the fact's concept must be a restriction of
@xbrli:pureItemType. |
|
<cf:conceptDataType strict="false">
<cf:type> </cf:conceptDataType><cf:qnameExpression> </cf:type>xfi:concept-data-type(fn:node-name($eg:otherVariable)) </cf:qnameExpression> |
Assuming that the custom function eg:concept-data-type returns the
QName of the XML Schema data type of the argument fact's concept then the
filter requires that a fact's concept has a data type that is a restriction of
the data type of the fact that the variable eg:otherVariable has
evaluated to.
|
1. XLink attributes have been omitted.
A concept substitution-group filter is declared by a
<cf:conceptSubstitutionGroup>
element.
The syntax for the
<cf:conceptSubstitutionGroup>
element is defined by the normative schema supplied with this specification.
The concept substitution-group filter can be used to match facts based on its XML Schema substitution group (See [XML SCHEMA STRUCTURES]).
If the
<cf:substitutionGroup>
element contains a
<cf:qnameExpression>
element and
the
@strict attribute on the
<cf:conceptSubstitutionGroup>
element
equals true, then the implied XPath expression is:
#qnameExpression eq (xfi:concept-substitutions(fn:node-name(.))[0])
where #qnameExpression is the XPath expression
contained by the
<cf:qnameExpression>
element.
If the
<cf:substitutionGroup>
element contains a
<cf:qnameExpression>
element and
the
@strict attribute on the
<cf:conceptSubstitutionGroup>
element
equals false, then the implied XPath expression is:
op:intersect((#qnameExpression),xfi:concept-substitutions(fn:node-name(.)))
where #qnameExpression is the XPath expression
contained by the
<cf:qnameExpression>
element.
If the
<cf:substitutionGroup>
element contains a
<cf:qname>
element and the
@strict attribute on the
<cf:conceptSubstitutionGroup>
element
equals true, then the implied XPath expression is:
fn:QName(#namespace,#name) eq (xfi:concept-substitutions(fn:node-name(.))[0])
where #namespace is the namespace for the QName specified as
the content of the
<cf:qname>
element and #name is the local
name for the QName specified as the content of the
<cf:qname>
element.
If the
<cf:substitutionGroup>
element contains a
<cf:qname>
element and the
@strict attribute on the
<cf:conceptSubstitutionGroup>
element
equals false, then the implied XPath expression is:
op:intersect((fn:QName(#namespace,#name)),xfi:concept-substitutions(fn:node-name(.)))
where #namespace is the namespace for the QName specified as
the content of the
<cf:qname>
element and #name is the local
name for the QName specified as the content of the
<cf:qname>
element.
| Filter1 | Selection criteria |
|---|---|
|
<cf:conceptSubstitutionGroup strict="true">
<cf:substitutionGroup> </cf:conceptSubstitutionGroup><cf:qname> </cf:substitutionGroup>xbrli:item </cf:qname> |
The fact's concept must specify the
<xbrli:item>
element in
its
@substitutionGroup attribute. It is not
sufficient for the fact's concept to specify some element that is,
itself, in the substitution group for the
<xbrli:item>
element.
|
|
<cf:conceptSubstitutionGroup strict="false">
<cf:substitutionGroup> </cf:conceptSubstitutionGroup><cf:qname> </cf:substitutionGroup>xbrli:item </cf:qname> |
The fact's concept must be an XBRL item. |
|
<cf:conceptSubstitutionGroup strict="false">
<cf:substitutionGroup> </cf:conceptSubstitutionGroup><cf:qname> </cf:substitutionGroup>xbrli:tuple </cf:qname> |
The fact must be an XBRL tuple. |
|
<cf:conceptSubstitutionGroup strict="true">
<cf:substitutionGroup> </cf:conceptSubstitutionGroup><cf:qnameExpression> </cf:substitutionGroup>fn:QName('http://example.com/','eg:customItem') </cf:qnameExpression> |
The fact's concept must identify the
<eg:customItem>
in
its
@substitutionGroup attribute.
|
1. XLink attributes have been omitted.
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:
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/concept-filter.xsd.
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/concept-filter.xsd.
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 Formula Working Group.
| Date | Author | Details |
|---|---|---|
| 18 December 2006 | Geoff Shuetrim |
First internal working draft created, drawing extensively on the previous formula specification drafts. |
| 23 April 2007 | Geoff Shuetrim |
Fixed up the rules for determination of the implied XPath expression to prevent the filter from resulting in true for all facts. |
| 24 April 2007 | Geoff Shuetrim |
Changed the concept filter to the concept name filter and modified it to use child elements instead of XLink relationships to concepts. Added a period type filter and a balance filter. |
| 25 April 2007 | Geoff Shuetrim |
Added a data-type filter, a substitution group filter and a filter to test the values of other custom attributes on concept declarations. These new concept filters are based on suggestions from Victor Morilla. |
| 08 May 2007 | Geoff Shuetrim |
Added clarification about the fact aspect covered by the filters defined in this specification. |
| 29 May 2007 | Geoff Shuetrim |
Changed the target namespace of the normative schema again. Modified the QName specification syntax to allow both static and dynamic QName specifications. Modified data type and substitution group filters to operate with and without analysis of XML Schema grammar models. Enabled concept name filter to exploit XML Schema substitution group relationships. |
| 11 June 2007 | Geoff Shuetrim |
Fixed up the wording in relation to the content of the concept-name filter and its child name elements. |
| 24 July 2007 | Hugh Wallis |
Edited for public working draft publication. |
| 05 November 2007 | Geoff Shuetrim |
Converted the specification to XML format. Added in the definitions and the hyperlinks to the relevant sections of the normative schema. Removed the strict attribute on the concept name filter because it was redundant now that we have the substitution group filter. Added the empty string value to the concept balance filter enumeration to cover selecting for concepts that are not classified as debits or credits. Modified the content model for the data type and substitution group filters to enable use of a common content model for all QName identification structures. |
| 14 November 2007 | Geoff Shuetrim |
Added a suggestion to allow concept name filters to exploit essence-alias and general-special relationships. The creation of boolean filters has enabled us to remove the possible multiplicity of child concept elements in a concept name filter without loss of filtering capabilities. Remaining references to substitution groups have been removed from the concept name filter because they are now covered by the substitution group filter. |
| 16 November 2007 | Geoff Shuetrim |
Reverted to allowing the concept name filter to name more than one concept, such that facts for any of the named concepts are deemed to meet the selection criteria expressed by the filter. This was done in response to request from Victor Morilla who felt that the ease of use of this syntax warranted is inclusion despite the ability to replicate the functionality with Boolean filters. |
| 21 November 2007 | Geoff Shuetrim |
Added examples for the concept name filter. Added quotes to the period-type and balance filters to ensure that the attribute values are treated as strings in the implied XPath expressions. Adapted the custom attribute filter to also support testing for the existence of a custom attribute rather than a specific value for a custom attribute. |
| 23 November 2007 | Jim Richards |
Corrected an error on an attribute formatting and made some minor grammatical changes. |
| 23 November 2007 | Geoff Shuetrim |
Added examples to the period-type, balance and custom-attribute filters. |
| 24 November 2007 | Geoff Shuetrim |
Added examples to the data-type and substitution-group filters. |
| 20 January 2008 | Geoff Shuetrim |
Made hyperlinks to the normative schema consistent throughout the document. |
| 24 January 2008 | Geoff Shuetrim |
Made the attributes on concept period-type and concept balance filters required in the normative schema. |
| 30 January 2008 | Geoff Shuetrim |
Clarified how the terms for the concept name filter are combined using the
|
| 31 January 2008 | Geoff Shuetrim |
Changed the enumeration for the
Changed |
| 01 February 2008 | Geoff Shuetrim |
Changed the data-type filter so that it can allow data types that are derived from a specified data type rather than only allowing data types that are a restriction of a specified data type as suggested by Cliff Binstock. This modification also eliminated the need for a custom function for these implied XPath expressions because an XPath 2.0 element test is suitable, as suggested by Mark Goodhand.
Changed the reference to the
Changed the reference to the |
| 04 February 2008 | Geoff Shuetrim |
Replaced the
Changed the first parameter of the Changed the equality tests in the custom attribute filter implied XPath expressions so that they are value comparisons rather than general comparisons. |
| 05 February 2008 | Geoff Shuetrim |
Modified the signature of the functions to access concept properties to take a QName rather than an item or tuple as a parameter. This makes the functions more broadly useful. Also adjusted the function name to ensure that their use for accessing concept properties was easily identified. Simplified the substitution group function that supports the substitution group filter. The two functions have been simplified to a single function that gets an ordered sequence of substitution group elements for a concept, starting with the element that is named by the substitution group attribute on the concept declaration and working back to the xbrli:item or xbrli:tuple element. This sequence is then used in the various implied XPath expressions for the substitution group filter. |
| 08 February 2008 | Geoff Shuetrim |
Adjusted the balance filter implied XPath expression to capture the difference between the balance attribute when testing for no balance and the value returned by the XBRL function when retrieving the balance for a concept with no balance attribute. This was suggested by Masatomo Goto. Fixed the incorrect filter element name for the first three substitution group filter examples. This error was identified by Masatomo Goto. |
| 12 February 2008 | Geoff Shuetrim |
Converted remaining general equality tests to value equality tests in the implied XPath expressions. |
| 19 February 2008 | Geoff Shuetrim |
Changed the |
| 20 February 2008 | Geoff Shuetrim |
Changed the implied XPath expressions for non-strict concept data-type filters
to replace the element test with a functionally equivalent XBRL function.
This was necessitated by the need to express the data type in the element test
as a Updated the implied XPath expressions for the strict concept data-type filters to bring them into line with the previously simplified design of the XBRL function that obtains the data type of XBRL concepts. |
| 26 February 2008 | Geoff Shuetrim |
Changed the function implied XPath expression for the concept data-type filter to conform to the signature for the XBRL function that checks whether the data type of a concept is derived from a specified data type. This enables the filter to be used for concepts with anonymous data types and was suggested by Hitoshi Okumura. |
| 14 November 2008 | Geoff Shuetrim |
Removed redundant reference entry as suggested by Takahide Muramoto. |
| 15 December 2008 | Geoff Shuetrim |
Updated references to the latest errata-corrected version of the XBRL 2.1 specification. |
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 31 December 2008. 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.