Talk:Main Page

From XBRLWiki

(Difference between revisions)

Revision as of 09:56, 26 October 2012

1 Use XML Schema for Header information
2 Use XBRL tuples for legal identifier
3 Allow multiple periods in a single instance
4 Allow multiple (reporting) entities in a single instance
5 Allow multiple currencies in a single instance

Use XML Schema for Header information

As a flexible and extensible alternative, which brings new possibilities, XBRL instances can be packed or wrapped in an XML envelope.

The header section in the envelope contains the header information, which can be used for routing purposes in receiving applications:

1. open XML document

2. interpret the routing information

3. decide on next step:

- refuse the document because of XML validation errors or wrong routing parameters

- accept the document and route the XBRL child node(s) to XBRL validation application

This method provides significant advantages:

- header information is retrieved immediately and communication with the declarer can start immediately.

- XBRL validation starts after knowing the declarer and routing parameters: if XBRL validation fails, the application disposes of the header information to communicate with the declarer. This is not the case when only working with an XBRL instance: if validation fails, you may not have the header fact values because they are somewhere in the instance which failed.

- this method enables the processing of multiple XBRL instances in one run. This is particularly useful when receiving instances from different periods or sub-reports. Smaller instances get validated faster.

Such an XML envelope looks like this (simplified):

<envelope>
<header>
<company>BankId01</company>
<contactPerson>
  <name>Greta</name>
  <email>greta@bank01.eu</email>
</contactPerson>
<routingInfo>
 <report>
  <reportCode>COREP</reportCode> 
  <version>testing</version>  
 </report>
</header>
<xbrl>
.. instance 1 ..
</xbrl>
<xbrl>
.. instance 2 ..
</xbrl>
</envelope>

Use XBRL tuples for legal identifier

RH 2012-10-18 I was the one advising this usage. Some background information:

Tuples are 'basic' XBRL technology, they have been around longer than dimensions;
Tuples have two goals: 1) to group information that can only correctly be interpreted 'as a whole' (e.g. street and house number); 2) if no logical key on the group of children is present AND there is a need for repetition of these children in the instance;
There are some technical solutions (like xs:choice) that can only be handled by tuples, but the validation this offers can also be handled by a formula;
Tuples do not have context information in an instance, so tuples never mix with dimensions themselves, only their children can;
Mixing tuple children with dimensions should be treated very carefully. The original reason for the tuple is grouping. With assigning different dimensional context information to its children the group may fall apart, nillifying its intended use. (although a formula disallowing this behaviour can be made);
The general idea that a tuple can be replaced by a typed dimension is falsified. This solution only works because of an artificial key (e.g. a sequence typed dimension element) is being added to the (not) requested information, or one of the children is handled as the key but in essence it's not. This is NOT a claim to abolish typed dimensions (there is use for them too);
Typed dimension processing takes more CPU cycles than tuples (except when deeply nested);
Using XLink to express relationships is much more complex than a simple tree of nodes in a schema.

From the information requirement, the 'identifier' of a company will be made out of different elements: country, key, organization forming the key, key type. This is a group of elements that can only be correctly interpreted together.
From a business perspective, if there is no agreed upon identifier between sender and receiver there are two options. 1) All details of the company are transmitted or 2) the reporter gives all known (to him) identifiers, increasing the chance the receiver will be able to identify the company. This is repetitive information without a specific order and without an intended unique key in it.

From the above I deduce that this information should be in a tuple.

There is no fighting arguments like:
EBA information is dimensional; (that's because it's handled with DPM)
There is no tuple in DPM; (no, they forge uncalled typed dimensions)
The US-GAAP and IFRS do not have tuples; (no, UK-GAAP and all SBR projects do)

Please, look at the reason tuples exist, map the information you want to communicate and draw your own conclusions.

Allow multiple periods in a single instance

From the tele-meeting on 2012-10-18 it was derived that multiple periods in an instance MAY be a common practice with some countries, but the position of some was that only the information handled in the 'current' period is of importance to be reported. Information handling older periods than 'current' will already be communicated before.

Resending information on older periods will not force the receiver to overwrite or compare the existing information in its data warehouse. A disclaimer would be appropriate.
For presentation purposes older and current data may be of interest.
Does the situation exists when a future period is being called for? (e.g. budgeted or prognosis values)
Is there a problem sending information from older or future periods?
Is there a restriction to increase the 'reported' period by the reporter by stating it covers two periods, forcing them in the instance anyway?