Talk:Main Page
From XBRLWiki
| Revision as of 10:21, 18 October 2012 (edit) Hommes (Talk | contribs) (→Use XBRL tuples for legal identifier) ← Previous diff |
Revision as of 10:32, 18 October 2012 (edit) Hommes (Talk | contribs) (→Allow multiple periods in a single instance) Next diff → |
||
| Line 24: | Line 24: | ||
| == Allow multiple periods in a single instance == | == 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 of 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 form older 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? | ||
| + | |||
| == Allow multiple (reporting) entities in a single instance == | == Allow multiple (reporting) entities in a single instance == | ||
| == Allow multiple currencies in a single instance == | == Allow multiple currencies in a single instance == | ||
Revision as of 10:32, 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 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 of 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 form older 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?
