View source for Comments about the Call for review the proposed edit recommendation made on 2011/05/27

== The email from the Technical Director of the XBRL International Consortium ==

On May 27th 2011,

The Base Specification and Maintenance Working Group has published a Proposed Edited version of the XBRL 2.1 Specification to address issues related to decimals and precision.

Since the changes proposed are of type 3 as defined in section 7.7.2 of the processes document and, if implemented, would necessitate software vendors to make changes to their products, it is essential that there be full public review and opportunity for commentary before any decision is taken whether or not to modify the specification as proposed.

The materials, including a version of the conformance suite that reflects the proposed changes, are available in https://www.xbrl.org

Please provide feedback to spec@xbrl.org

Further reminders and announcements will be made and a deadline date for comments announced in due course

Thanks

Hugh

== The experience of Reporting Standard on this topic ==

The topic was first commented to the XBRL-DEV list around July 2007. Here is one of the emails where we explained the issue.

Hello,
 
Attached is a very simple test case:
 
The taxonomy has three elements and a very simple rule defined.
A = B + C
 
The instance contains:
 
A = 0 with decimals 0
C = 4 with decimals 0
 
I would like to discuss with you if there is any mistake in the XBRL 2.1 spec because.
 
1)      NOT AL SOFTWARE VENDORS HAVE IMPLEMENTED THIS RULE CONSISTENLY IN THEIR PRODUCTS (some raise calculation inconsistencies some not)
2)      THE CONDITION THAT IS BEING TESTED HERE IS NOT IN THE CURRENT CUT OF THE XBRL 2.1 CONFORMANCE SUITE
 
Explanation:
 
A = 0 with decimals 0. This is represented as A = 0d(0) 
 
According to the XBRL 2.1 spec, an XBRL processor must infer the value of the precision for this number. 
http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_4.6.6
 
If I’m correct, This turns the number into A = 0p(0) (A with value 0 and precision=0) (I’ve also highlighted the reason in bold blue)
“Given the value of the decimals attribute, the precision of a numeric item is equal to n, where n is equal to the maximum of 0 and the result of the following calculation:
if there are non-zero digits to the left of the decimal point or implied decimal point if absent then the number of digits excluding any leading zeros to the left of the decimal point (or implied decimal point if absent) in the lexical representation of the numerical fact
otherwise if there are non-zero digits to the right of the decimal point, the negative of the number of zeros between the decimal point and the first non-zero digit in the lexical representation of the numerical fact
otherwise zero
plus 

the value of the exponent in the lexical representation of the numerical fact (if present) 
plus 

the number of decimal places to which the numeric fact is known to be correct.
”
 
Now, the processor must follow the rules in section 5.2.5.2 of the XBRL spec in regard to the calculation of the total.
 
http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_5.2.5.2
 
“The total of a binding calculation is defined to be the sum of the rounded values of the contributing numeric items in the binding, each multiplied by the value of the weight attribute on the item's associated calculationArc. This multiplication takes place after any necessary rounding is performed. The rounded value of a numeric item is the result of rounding the value of the numeric item to its precision or inferred precision (see Section 4.6.6 and ). A binding calculation is defined to be consistent if the rounded value of the summation item is equal to the total rounded to the precision or inferred precision of the summation item.”
 
So C = 4d(0) is first converted into C = 4p(1) (4 with precision = 1 following the same rules indicated in section 4.6.6). Then, the total is 4 (just a number without indication about precision)
 
Following the rule, “rounded to the precision or inferred precision of the summation item.” 4 must be rounded to p(0) so this is 4p(0).
 
The rounded value of 4p(0) is 0… so 
 
A = B + C
0d(0) = + 4d(0)
0p(0) = 4
0p(0) = 4p(0)
 
And this is TRUE because 4p(0) is 0
 
Can other software vendors confirm this or different interpretations?
 
Regards,
Ignacio

== The proposed solution ==

The Specification working group has published a new specification (rather than a simple errata correction).

== How you can test the consequences of the proposed solution ==

Our processor implements the capacity to set configuration options. 

Starting with release 2.7.1, the configuration options are available directily in the user interface.

If you have a license of Reporting Standard S.L. XBRL Personal Validation, you can activate validation under the new proposed wording by doing:

# Open "XBRL Personal Validation"
# Click on browse and select the file(s) to validate. (all files selected will compose a single DTS)
# Click on the Options button
# Make sure you have the XBRL_EXPERIMENTAL_BUG_368 option selected
# Click the RUN button

[[File:Options-Processor-version.png]]

The same processor can operate differently depending on the configuration options the user decides to set.

== Our conclusion ==

* We think the text on the proposed edited recommendation exceeds the limits of the real problem as it is documented on this test case, in consequence:
** The error detected in the specification (comparison with a number with precision 0) does not justify a change to infer decimals from precision.
** The error detected could be easily fixed adding a new warning to the XBRL 2.1 specification in section 5.2.5.2 and section 4.6.6 keep current calculations based on precision as they are. More information in the next section of this document.
* In fact, inferring decimals from precision or precision form decimals is unrelated with the problem detected.
** There is no business requirement for a change of this nature.
** during a period of time (maybe forever) there would be implementations according with the old wording and implementations according with the new wording.
** There is a high risk of creating inconsistent implementations of XBRL, "after the inferring precision from decimals era" and "before the inferring precision from decimals era". This change would create inconsistent processors during a large period of time. It is also possible that some projects require old specification versions and some project require new specification versions. (even if the XBRL consortium don't want to call this a new "version", due to the reason the old conformance suite is no longer valid with the new wording, this is, in fact, a new version)

== Our proposal ==

* We propose a simple errata correction in order to add a new warning in case a number is compared with another number using precision=0 or inferred precision=0
* We DO NOT endorse a specification change and a conformance suite change at this stage.
* CONCRETE PROPOSAL: if the conversion of 0 decimals 0 into 0 with precision 0 is a problem because a number with precision zero is equal to whatever other number. The XBRL 2.1 specification should add the following two rules:
** 0 decimals 0 shall be converted into 0 with precision 1 (on section 4.6.6)
** if the rounded value of the summation item is 0 with inferred or stated precision 0, then a warning should be raised by an XBRL processor. (on section 5.2.5.2)