Support Added for Calculation Arcs with Destination Labels Referencing Multiple Locators

I have just checked in a change to Gepsio that correctly validates calculation arcs that use destination labels that reference more than one locator.

Take a look at the following calculation link:

<calculationLink xlink:type="extended" xlink:role="http://www.xbrl.org/2003/role/link">

    <loc xlink:type="locator" xlink:href="397-ABC.xsd#A" xlink:label="summationItem" />

    <loc xlink:type="locator" xlink:href="397-ABC.xsd#B" xlink:label="contributingItem" />

    <loc xlink:type="locator" xlink:href="397-ABC.xsd#C" xlink:label="contributingItem" />

    <calculationArc
        xlink:type="arc"
        xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item"
        xlink:from="summationItem"
        xlink:to="contributingItem" weight="1"
    />

</calculationLink>

This example, taken from the 397.00 conformance test in the XBRL-CONF-CR3-2007-03-05 conformance suite, defines a calculation arc that arcs from “summationItem” to “contributingItem”. The issue here is that there are two locators that use the “contributingItem” label:

• 397-ABC.xsd#B


• 397-ABC.xsd#C

Both of these locators must participate in the calculation arc. In the current CTP of Gepsio, only the fact referenced by the first locator is used to validate the calculation arc. With the new code, both facts referenced by both locators are used to validate the calculation arc.

This improved functionality will be available in the next CTP to released (which I am currently targeting for release in the next week or so).

Calculation Validation Location Bug Fixed

I have checked in code that fixes a bug in the validation of calculation arc values in Gepsio.

In the current CTP, the value of a xlink:href attribute of a locator element for a calculation arc is used to find the appropriate contributing concept. This is in error; in fact, the xlink:label attribute must be used instead. This bug hasn’t been caught until now because many of the XBRL documents in XBRL-CONF-CR3-2007-03-05 conformance suite use the same value for the xlink:href and label attributes. The 305.07 test, for example, references a calculation linkbase document that includes markup as follows:

<loc
    xlink:type="locator"
    xlink:href="305_07_decimals_test.xsd#decimals_Land"
    xlink:label="decimals_Land"
/>

As you can see, the resource ID of the value of the xlink:href attribute (decimals_Land) matches the value of the xlink:label attribute (decimals_Land), so it didn’t matter which value Gepsio used to find the correct element.

The 395.01 test, however, uses different location markup:

<loc
    xlink:type="locator"
    xlink:href="SummationItem.xsd#CurrentAsset"
    xlink:label="labelCurrentAsset"
    xlink:title="CurrentAsset"
/>

In this markup, the resource ID of the value of the xlink:href attribute (CurrentAsset) does not match the value of the xlink:label attribute (labelCurrentAsset) and Gepsio’s use of the resource ID is in error. Gepsio must use the value of the xlink:label attribute to find the correct element.

This bug has been fixed and will be available in the next CTP of Gepsio (which I am currently planning on releasing on Nov 01 2011).

Essence Alias Support Complete

I have just checked in code that completes Gepsio’s support of the XBRL essence alias concept. All of the essence alias conformance tests found in the XBRL-CONF-CR3-2007-03-05 conformance test suite (numbered with the 392 prefix) now behave as expected when parsed by Gepsio.

The next CTP of Gepsio will include all of this work and will correctly validate essence aliases found in XBRL documents.

Dates Available For Instant Period Contexts

I have just checked in a change to the Context class that will appear in the next CTP. The Context class now includes a public property called InstantDate, which exposes a DateTime value. The value of the InstantDate property for a Context reflects the date given for an instant period. This value is valid only when the Context reflects an Instant period. You will be able to write code like the following:

if(CurrentContext.InstantPeriod == true)
{
    var ContextDate = CurrentContext.InstantDate;
}