Talk:Main Page
From XBRLWiki
| Revision as of 10:02, 18 October 2012 (edit) Hommes (Talk | contribs) (→Use XBRL tuples for legal identifier) ← Previous diff |
Current revision (09:17, 29 October 2012) (edit) Javi.mora (Talk | contribs) |
||
| Line 1: | Line 1: | ||
| + | == Status and Open Issues == | ||
| + | |||
| + | [http://www.eurofiling.info/cen/CWA2_status.ppt '''Download presentation'''] | ||
| + | |||
| == Use XML Schema for Header information == | == 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. | ||
| + | |||
| + | RH: A general advantage to having a separation between 'content' and envelope is that the content can be signed (encrypted) without bothering the transmission data. That is mostly the reason that with protocols like SOAP the whole of the instance is included in a single element (base64 encoded): transmission data is not affected that way. But prevent duplication; do not copy all the transmission data into the content too. That may lead to extra validations to ensure envelope and content are in sync. | ||
| + | |||
| + | 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> | ||
| + | |||
| + | |||
| + | '''XADES-EPES / ZIP proposition''' | ||
| + | |||
| + | This could be an alternative to the XML Schema approach | ||
| + | |||
| + | [[Image:XADES-EPES-ZIP-proposition.png]] | ||
| + | |||
| == Use XBRL tuples for legal identifier == | == Use XBRL tuples for legal identifier == | ||
| '''RH 2012-10-18''' I was the one advising this usage. Some background information:<br/> | '''RH 2012-10-18''' I was the one advising this usage. Some background information:<br/> | ||
| Line 7: | Line 67: | ||
| *Tuples do not have context information in an instance, so tuples never mix with dimensions themselves, only their children can; | *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); | *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; | + | *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); | *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.<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/> | ||
| Line 23: | Line 84: | ||
| == 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 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? | ||
| + | |||
| == 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 == | ||
Current revision
Contents |
Status and Open Issues
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.
RH: A general advantage to having a separation between 'content' and envelope is that the content can be signed (encrypted) without bothering the transmission data. That is mostly the reason that with protocols like SOAP the whole of the instance is included in a single element (base64 encoded): transmission data is not affected that way. But prevent duplication; do not copy all the transmission data into the content too. That may lead to extra validations to ensure envelope and content are in sync.
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>
XADES-EPES / ZIP proposition
This could be an alternative to the XML Schema approach
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?
