Consistency Assertions 1.0

Recommendation 22 June 2009

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

This version:
<http://www.xbrl.org/Specification/consistencyAssertions/REC-2009-06-22/consistencyAssertions-REC-2009-06-22.html>
Editors:
Victor Morilla, Banco de España <victor.morilla@bde.es>
Geoff Shuetrim, Galexy <geoff@galexy.net>
Contributors:
Paul Bull, Morgan Stanley <paul.bull@morganstanley.com>
Herm Fischer, UBMatrix / Mark V Systems <fischer@markv.com>
Masatomo Goto, Fujitsu <mg@jp.fujitsu.com>
Roland Hommes, Rhocon / Consultant to Netherlands Tax and Customs Administration <roland@rhocon.nl>
Takahide Muramoto, Fujitsu <taka.muramoto@jp.fujitsu.com>
Jim Richards, JDR & Associates <jdrassoc@iinet.net.au>
Michele Romanelli, Banca d'Italia <michele.romanelli@bancaditalia.it>

Status

Circulation of this Recommendation is unrestricted. This document is normative. 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 of the Validation specification [VALIDATION]. It specifies syntax for assertions that can be used to test the consistency of a fact produced by a formula with fact contained in an XBRL business report.

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 Consistency assertions
2.1.1 Consistency assertion relationships
2.1.1.1 Consistency-assertion-formula relationships
2.1.1.2 Consistency-assertion-parameter relationships
3 The processing model for consistency assertions

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 Consistency assertions
2 @strict attribute usage
3 Acceptance radius
4 Consistent values
5 Consistency assertions involving nil values

Definitions

acceptance radius
aspect-matched input fact
consistency assertion
consistency-assertion formula
consistency-assertion formulae
consistency-assertion parameter
consistency-assertion-formula relationship
consistency-assertion-parameter relationship
consistent
derived fact
rfc2119 terminology
strict

Error codes

xbrlcae:acceptanceRadiusConflict
xbrlcae:variablesNotAllowed


1 Introduction

The XBRL Formulae specification [FORMULA] defines a syntax that expresses rules for transforming information in XBRL business reports and their supporting discoverable taxonomy sets into new XBRL facts.

This specification extends the XBRL Validation specification [VALIDATION], defining an assertion that uses formulae to define tests on XBRL business reports. These assertions can test the consistency of the fact produced by a formula evaluation with aspect-matched input facts in the XBRL business report.

This design enables the one formula resource to be used to produce new facts and to check the consistency of existing facts with other facts in their containing XBRL business report. A regulator can use this kind of assertion to test the quality of data received and producers of business reports can use the common formula to derive the facts being reported in a manner that is consistent with the requirements of the regulator.

This kind of assertion facilitates the definition of business rules that perform checks like those set out in Example 1.

Example 1: Consistency assertions
  • The total income reported for a company is equal to the cumulated income reported for each market segment, taking into account the precision of reported total income and the precision of the cumulated income based on reporting of market segments.
  • The difference between net income reported and net income calculated as total income minus operating expenses, must be less than ten percent of calculated net income.
  • The difference between the reported ending balance and the ending balance computed from the flows during the intervening period and the starting balance, must be less than an amount defined by an external parameter.

Many of the syntax constraints imposed by this specification are set out in the normative schema Appendix A. To eliminate the potential for conflicts, this specification only enunciates syntax features that are not expressed in the normative schema.

1.1 Background

This specification is a member of a suite of similar specifications that define specific types of assertions tested against the information contained in XBRL business reports.

1.2 Relationship to other work

This specification builds on the foundation provided by the XBRL Validation Specification [VALIDATION] and the XBRL Formulae Specification [FORMULA].

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.

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

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
formula http://xbrl.org/2008/formula
validation http://xbrl.org/2008/validation
ca http://xbrl.org/2008/assertion/consistency
xbrlcae http://xbrl.org/2008/assertion/consistency/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 Consistency assertions

A consistency assertion is a statement of expectations in relation to the consistency of facts in an input XBRL instance with the values that can be derived for those facts from the same XBRL instance by processing formulae [FORMULA].

Consistency assertions are expressed by the <ca:consistencyAssertion> element in the normative schema supplied with this specification.

Consistency assertions have relationships to formulae, defined by XLink arcs. See Section 2.1.1.1 for details.

A derived fact is any one of the facts that can be produced by evaluating a formula in the set of consistency assertion formulae, given the assertion input.

An aspect-matched input fact for a derived fact is a fact in the assertion input used to produce the derived fact that is aspect matched to the derived fact.

The relevant aspect model is identified by the @aspectModel attribute on the formula that produced the derived fact.

Consistency assertions are tested by comparing the values of derived facts with the values of aspect-matching facts in the assertion input for consistency.

The @strict attribute on a consistency assertion influences which derived facts can be used to test a consistency assertion.

A consistency assertion is strict if it has a @strict attribute that is equal to true. Otherwise it is not strict.

If a consistency assertion is not strict then it MUST NOT be evaluated for derived facts if they do not have aspect-matched input facts.

If the consistency assertion is strict then the consistency assertion MAY be evaluated for derived facts even if they do not have aspect-matched input facts. Such assertions can be used to test for both the presence of aspect matched facts as well as for consistency of their values.

Example 2: @strict attribute usage
@strict attribute Facts in input instance Assertion formula Can be evaluated?
false a, b, c a = b * c Yes
true a, b, c a = b * c Yes
false b, c a = b * c No
true b, c a = b * c Yes (but never satisfied)

The acceptance radius of a consistency assertion is a number that represents the maximum difference between the numerical value of two facts for them to be considered consistent.

The acceptance radius can be defined as an absolute value, in which case the consistency assertion contains an @absoluteAcceptanceRadius attribute.

Alternatively, the acceptance radius can be defined as a proportion of the derived fact value, in which case the consistency assertion contains a @proportionalAcceptanceRadius attribute.

If the acceptance radius is an absolute value, then it is the result of evaluating the XPath expression at the @absoluteAcceptanceRadius attribute.

If the acceptance radius is proportional, then it is the result of evaluating the XPath expression:

. * ( #proportionalAcceptanceRadius )

where #proportionalAcceptanceRadius is the XPath expression in the @proportionalAcceptanceRadius attribute.

The context when evaluating these two XPath expressions MUST:

  • have as the context item an atomic value equal to the numeric value of the derived fact; and
  • include consistency-assertion parameters and the variables in the variable set defined by the formula being evaluated among the in-scope variables.

Error code xbrlcae:acceptanceRadiusConflict MUST be thrown if a consistency assertion contains both an @absoluteAcceptanceRadius attribute and a @proportionalAcceptanceRadius attribute.

Example 3: Acceptance radius
Attribute / value Derived fact value Acceptance radius
No attribute defined Any Not defined
@absoluteAcceptanceRadius = 100 Any 100
@absoluteAcceptanceRadius = $margin Any Value of the parameter margin
@proportionalAcceptanceRadius = 0.5 500 250
@proportionalAcceptanceRadius = 0.5, @absoluteAcceptanceRadius = 500 Any Error: acceptance radius definition conflict

Consistency assertions have a variety of relationships to other XLink resources, expressed by XLink arcs. These relationships are explained in the following section.

2.1.1 Consistency assertion relationships

2.1.1.1 Consistency-assertion-formula relationships

A consistency-assertion-formula relationship is a relationship between a consistency-assertion and a formula expressed by an XLink arc.

To declare a consistency-assertion-formula relationship an XLink arc MUST:

The arcrole value, http://xbrl.org/arcrole/2008/consistency-assertion-formula, is declared in the normative schema for consistency assertions.

Consistency-assertion-formula relationships MUST be expressed by generic arcs as indicated by the restrictions imposed by the arcrole declaration in the normative schema. Violations of this requirement will be detected by validation against the XBRL Specification [XBRL 2.1].

The set of formulae related to a consistency assertion by consistency-assertion-formula relationships are known as the consistency-assertion formulae.

A consistency-assertion-formula is any formula in a set of consistency-assertion formulae.

A consistency assertion checks the consistency of reported facts with the facts produced by each of its consistency-assertion formulae on a stand-alone basis. Thus, the tests possible for one consistency assertion associated with two formulae, are identical to the tests implied by two consistency assertions, one related to one formula and the other related to the other formula.

2.1.1.2 Consistency-assertion-parameter relationships

A consistency-assertion-parameter relationship is a relationship between a consistency assertion and a parameter expressed by an XLink arc.

To declare a consistency-assertion-parameter relationship an XLink arc MUST:

The arcrole value, http://xbrl.org/arcrole/2008/consistency-assertion-parameter, is declared in the normative schema for consistency assertions.

Consistency-assertion-parameter relationships MUST be expressed by variable arcs as indicated by the restrictions imposed by the arcrole declaration in the normative schema. Violations of this requirement will be detected by validation against the XBRL Specification [XBRL 2.1].

Just as for variable-set relationships the value of the @name attribute on a variable arc is the QName of the parameter in the consistency-assertion-parameter relationship expressed by the arc. When computing the acceptance radius for a consistency assertion, XPath variable references with this QName are references to the parameter. Note that this parameter name MAY differ from the name given in the parameter declaration.

All consistency-assertion parameters MUST be evaluated before the acceptance radius of the consistency assertion is evaluated.

A consistency assertion MAY be related to parameters by consistency-assertion-parameter relationships.

Error code xbrlcae:variablesNotAllowed   MUST be thrown if a consistency assertion has a consistency-assertion-parameter relationship to a fact variable or to a general variable.

A consistency-assertion parameter is any parameter that has a consistency-assertion-parameter relationship to it from a consistency assertion. These parameters are part of the in-scope variables of the evaluation of acceptance radius expressions, but MUST NOT be considered part of the variable-set of the consistency assertion formulae.

3 The processing model for consistency assertions

Aside from the exceptions described below, each different evaluation of a consistency assertion formula defines a different assertion data set that the consistency assertion can be tested with. The assertion data set of a consistency assertion is the derived fact produced by an evaluation of a consistency assertion formula plus all of the aspect-matched input facts in the input XBRL instance that do not have nil values. Note that there may be no aspect-matched input facts in the input XBRL instance that meet the conditions necessary to be included in the data set defined by a derived fact.

One exception to this rule is that a derived fact does not define an assertion data set if:

The second exception to the rule is that a derived fact does not define an assertion data set if:

If a derived fact is not valid, based on the XBRL Specification [XBRL 2.1], then the assertion is deemed to be not satisfied, regardless of the aspect-matched input facts in the assertion data set.

If an assertion data set contains aspect-matched input facts, then the derived fact MUST be consistent with all of them for the consistency assertion to be satisfied for that assertion data set. Otherwise the consistency assertion is not satisfied for that assertion data set.

Two facts are consistent if they have consistent values. Whether two facts have consistent values depends upon their data types.

If the two facts have data types that are not numeric then they are only consistent if their values are s-equal2.

If the two facts have data types that are numeric, and their data types are not xbrli:fractionItemType or derived from the xbrli:fractionItemType, and the acceptance radius is not defined, then they are only consistent if the numeric values A and B are x-equal where A is obtained by rounding the value of the first fact to N significant figures and B is obtained by rounding the value of the second fact to N significant figures noting that N is the lower of the specified or inferred precision for the first fact and the specified or inferred precision for the second fact.

If the two facts have data types that are numeric, and their data types are not xbrli:fractionItemType or derived from the xbrli:fractionItemType, and the acceptance radius is defined, then they are only consistent if the following XPath expression evaluates to an effective Boolean value of true:

fn:abs(#A - #B) le fn:abs(#acceptance)

where #A is the numerical value of the first fact, #B is the numerical value of the second fact and #acceptance is the value of the acceptance radius.

Formulae, as defined in the XBRL Formula Specification [FORMULA] cannot produce facts that have data types that are or are derived from the xbrli:fractionItemType. For this reason, consistency assertions cannot be used to test such facts for consistency and so value consistency is not defined in this specification for such facts.

If none of these conditions for consistency are satisfied then the derived fact and the aspect-matched input fact that it is being compared to are not consistent.

Example 4: Consistent values
Derived fact Aspect-matched input fact Acceptance radius Assertion evaluation
Inferred precision Value Inferred precision Value
- foo - foo Any Satisfied
- foo - bar Any Not satisfied
INF 315.5 INF 315.5 Not defined Satisfied
INF 315.5 INF 315.50001 Not defined Not satisfied
0 315.5 INF 1000000 Not defined Not evaluated
2 10 2 10.4 Not defined Satisfied
2 10 3 10.4 Not defined Satisfied
2 10 3 10.5 Not defined Not satisfied
Any 10.0000001 Any 10.0000001 0 Satisfied
Any 10 Any 10.0000001 0 Not satisfied
Any 25 Any 30 5 Satisfied
Any 25 Any 30.000001 5 Not satisfied

If an assertion data set does not contain any aspect-matched input facts, then the derived fact MUST have a nil value if the consistency assertion is to be satisfied for that assertion data set. Otherwise the consistency assertion is not satisfied for that assertion data set.

Example 5: Consistency assertions involving nil values
@strict attribute Derived fact Aspect-matched input facts Assertion evaluation
false Nil None Not evaluated
false Not nil None Not evaluated
false Nil Not nil only Not satisfied
true Nil None Satisfied
true Not nil None Not satisfied
true Nil Not nil only Not satisfied

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/consistency-assertion.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:ca="http://xbrl.org/2008/assertion/consistency" xmlns:validation="http://xbrl.org/2008/validation" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:variable="http://xbrl.org/2008/variable" xmlns:gen="http://xbrl.org/2008/generic" xmlns:link="http://www.xbrl.org/2003/linkbase" targetNamespace="http://xbrl.org/2008/assertion/consistency" 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"/>
<import namespace="http://xbrl.org/2008/validation" schemaLocation="validation.xsd"/>
<annotation>
<appinfo>
<link:arcroleType id="consistency-assertion-formula" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/arcrole/2008/consistency-assertion-formula">
<link:definition>
assertion based on formula
</link:definition>
<link:usedOn>
gen:arc
</link:usedOn>
</link:arcroleType>
<link:arcroleType id="consistency-assertion-parameter" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/arcrole/2008/consistency-assertion-parameter">
<link:definition>
acceptance radius depends on parameter
</link:definition>
<link:usedOn>
variable:variableArc
</link:usedOn>
</link:arcroleType>
</appinfo>
</annotation>
<element id="xml-consistency-assertion" name="consistencyAssertion" substitutionGroup="validation:assertion">
<complexType mixed="true">
<complexContent mixed="true">
<extension base="validation:assertion.type">
<attribute name="strict" type="boolean" use="required"/>
<attribute name="absoluteAcceptanceRadius" type="variable:expression" use="optional"/>
<attribute name="proportionalAcceptanceRadius" 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)
FORMULA
XBRL International Inc.. "XBRL Formulae 1.0"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See ../../formula/CR-2008-12-31/formula-CR-2008-12-31.html)
GENERIC LINKS
XBRL International Inc.. "XBRL Generic Links 1.0"
Mark Goodhand, Ignacio Hernández-Ros, and Geoff Shuetrim.
(See ../../gnl/REC-2009-06-22/gnl-REC-2009-06-22.html)
IETF RFC 2119
IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.
(See http://www.ietf.org/rfc/rfc2119.txt)
VALIDATION
XBRL International Inc.. "XBRL Validation 1.0"
Victor Morilla, and Geoff Shuetrim.
(See ../../validation/REC-2009-06-22/validation-REC-2009-06-22.html)
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 ../../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)
XLINK
W3C (World Wide Web Consortium). "XML Linking Language (XLink) Version 1.0"
Steve DeRose, Eve Maler, and David Orchard.
(See http://www.w3.org/TR/xlink/)
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/)
XPATH 2.0
W3C (World Wide Web Consortium). "XML Path Language (XPath) 2.0"
Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon.
(See http://www.w3.org/TR/xpath20/)

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
30 June 2007Geoff Shuetrim

Initial draft created.

22 July 2007Geoff Shuetrim

Converted to XML format.

15 October 2007Geoff Shuetrim

Adapted to XBRLspec syntax.

25 November 2007Victor Morilla

Split from validation report specification

Adapted and included variable, group filter and precondition augmentation

26 November 2007Geoff Shuetrim

Modified the definition of a consistency assertion.

Changed the consistency-assertion element name to camel case to conform with the naming convention used by other XBRL specifications.

Eliminated the default value for the strict attribute on consistency assertions to conform to the broader approach of always being explicit at the syntax level.

03 December 2007Victor Morilla

Simplified and adapted to new variables specification

Included an acceptance radius as suggest by G.S

Included possibility of parameters to determine the acceptance radius as suggested by Herm Fischer.

04 December 2007Victor Morilla

Moved assertion-formula relationship to this specification as suggested by Geoff Shuetrim.

Removed obsolete comments.

06 December 2007Victor Morilla

Included examples.

Removed obsolete comments.

Description of @strict rewritten.

References to the definition of the assertion data set.

09 December 2007Victor Morilla

Consistency-assertion-formula relationships now used on <gen:arc> element.

@aspectModel attribute obtained from formulae producing fact instead of the assertion resource.

10 December 2007Victor Morilla

Adapted to be in the substitution group for assertions (not in the substitution group for variables).

General variables associated with assertions removed.

16 December 2007Victor Morilla

Changed namespace of consistency assertions from http://xbrl.org/2008/consistency-assertion to http://xbrl.org/2008/assertion/consistency

31 January 2008Geoff Shuetrim

Standardised the format of the hyperlinks to the normative schema.

Standardised the boilerplate text for errata.

01 February 2008Geoff Shuetrim

Changed the acceptance radius from not defined to 100 for the example where the absolute acceptance ratio was set to 100, as suggested by Masatomo Goto.

Changed the example stating incorrectly that a consistency assertion is satisfied if the derived fact is nil but the corresponding facts are not.

02 February 2008Victor Morilla

Clarified behaviour of zero precision facts consistency checks when acceptance radius is not defined as suggested by Masatomo Goto. In these cases, consistency cannot be verified, and so the assertion is not evaluated.

06 February 2008Geoff Shuetrim

Changed the name of the consistency assertion element in the specification text to match the normative schema.

Removed obsolete comments.

Changed the term "corresponding fact" to the more expressive term "aspect-matching fact".

Simplified the explanation of the @strict attribute usage.

Combined the errors relating to variable-set relationships and consistency assertions.

Deleted the tables setting out the aspect tests to use for the aspects defined in the two aspect models set out in the variable specification because that is already done in the variable specification.

Moved the definition of an aspect-matching fact to an earlier part of the specification to better clarify the many references to aspect-matching facts.

Refined the definition of the assertion data set to simplify the determination of the conditions for consistency. The assertion data set no longer includes nil valued aspect-matching facts. This more closely integrates the @strict attribute into the assertion data set definition.

07 February 2008Victor Morilla

Removed wrong introductory paragraph from value assertions.

Corrected reference to assertion input.

Included clarification of the scope of consistency-assertion parameters.

09 April 2008Geoff Shuetrim

Corrected the typo in the explanation of the XPath expression for proportional acceptance radii. This typo was identified by Takahide Muramoto.

04 June 2008Geoff Shuetrim

Removed the redundant word "considering" in the first part of the first example.

Renamed the factVariablesNotAllowed error code to variablesNotAllowed to reflect the fact that both fact and general variables are not allowed to be the targets of relationships from consistency assertions.

Defined a new relationship and syntax for expressing the relationship from consistency assertions to their parameters. This is required to eliminate erroneous references to consistency assertions as variable sets. It does not alter the capabilities of the specification. This problem was identified by Victor Morilla.

05 June 2008Geoff Shuetrim

Removed the unnecessary word "Fact" from the section heading for the various relationships defined in this specification.

Made hyphenation of the term "consistency-assertion parameter" consistent throughout the text of the specification.

26 June 2008Geoff Shuetrim

Added the variables in the variable-set of the formula being tested to the context used for evaluation of acceptance radii. This enhancement was suggested by Victor Morilla.

13 August 2008Geoff Shuetrim

Removed un-necessary schema limitations on undirected cycles in relationship networks.

26 September 2008Geoff Shuetrim

Modified "aspect-matching fact" term to "aspect-matched input fact to leverage a new definition in [VARIABLES].

Made explicit the outcome of assertion testing when the derived fact is not a valid XBRL fact. In such cases, the assertion is deemed to be not satisfied.

26 September 2008Geoff Shuetrim

Fixed the id on the definition of consistency-assertion-parameter relationships to ensure internal links within the specification work.

15 December 2008Geoff Shuetrim

Updated references to the latest errata-corrected version of the XBRL 2.1 specification.

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.

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 22 June 2009. 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.