Talk:Main Page

From XBRLWiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 10:02, 18 October 2012 (edit)
Hommes (Talk | contribs)
(Use XBRL tuples for legal identifier)
← Previous diff
Revision as of 10:02, 18 October 2012 (edit)
Hommes (Talk | contribs)
(Use XBRL tuples for legal identifier)
Next diff →
Line 10: Line 10:
*Typed dimension processing takes more CPU cycles than tuples (except when deeply nested); *Typed dimension processing takes more CPU cycles than tuples (except when deeply nested);
-From the information requirement, they '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.<br/>+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.<br/>
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 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.

Revision as of 10:02, 18 October 2012

Contents

Use XML Schema for Header information

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 dimnension is falsified. This solution only works because of an artificial key (e.g. a sequence typed dimension element) being added to the information;
  • Typed dimension processing takes more CPU cycles than tuples (except when deeply nested);

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

Allow multiple (reporting) entities in a single instance

Allow multiple currencies in a single instance

Personal tools