Talk:European XBRL Taxonomy Architecture
From XBRLWiki
| Revision as of 05:57, 12 October 2012 (edit) Hommes (Talk | contribs) ← Previous diff |
Current revision (08:34, 25 October 2012) (edit) Hommes (Talk | contribs) (→Comment-06) |
||
| Line 3: | Line 3: | ||
| === Comment-01 === | === Comment-01 === | ||
| RH: Is this terminology stable? I've seen 'report' as term for 'framework' and trying to grasp the essence of a framework I think that it represents a number of forms or tables. In essence its just a semantic name given to a number of forms and or tables, its not defining anything for itself, only by derivation of what it groups. A report (IMO) also represents a single form or table. Which is why I put framework as the proposed name. OTOH the framework seems to represent business rules too and that is not always correct since business rules can be applied on dictionary level, on framework level or on single table and even cell level. | RH: Is this terminology stable? I've seen 'report' as term for 'framework' and trying to grasp the essence of a framework I think that it represents a number of forms or tables. In essence its just a semantic name given to a number of forms and or tables, its not defining anything for itself, only by derivation of what it groups. A report (IMO) also represents a single form or table. Which is why I put framework as the proposed name. OTOH the framework seems to represent business rules too and that is not always correct since business rules can be applied on dictionary level, on framework level or on single table and even cell level. | ||
| + | |||
| + | KH: A framework consists of reporting regulations for a domain specific scope of information. The information requirements are structed in form of tables to ease the understanding for the institutions that are obliged to submit the reporting information to the supervisor. All business rules to be met by the reporting entities are defined in the reporting regulations. Some of these rules are also incorporated in the table design to show which detailed information are being part of a summation. Others are only reflected inside the regulations itself. | ||
| + | |||
| + | TD: If I see right, our work in CEN/XBRL could consist in proposing a "meta model" for building XBRL taxonomies, which should be following national frameworks. Framework can be seen as (stable) conceptual structure (which should contain the frames, rules, constraints, etc for modeling the national legislation). | ||
| + | I think we are in sync here (especially with Katrin). Our guidelines would then be about that, what people or insitutions need in order to model their regulation frameworks. So yes, the basic constituents ("concepts", "rules", "links", "labels", etc), could be considered as the dictionary, while the particular way of building a taxonomy corresponding to a particular legislation could be the "grammar". | ||
| === Comment-02 === | === Comment-02 === | ||
| RH: The occurences of the owner and his IP rights and supportive languages etc. appear to me to be facts, not meta data expressed in namespace, concepts etc. The owner name is already expressed through the namespace of each schema. | RH: The occurences of the owner and his IP rights and supportive languages etc. appear to me to be facts, not meta data expressed in namespace, concepts etc. The owner name is already expressed through the namespace of each schema. | ||
| + | |||
| + | KH: Maybe it is better to have a separate section dealing with extensions and to explain there the concepts of owner. The taxonomy architecture should IMHO not deal with IP rights. | ||
| + | |||
| + | TD: True. names of owner etc are additional features I think. Is what we find in the namespace always the owner, or can it be the legislation etc.? | ||
| + | |||
| + | <span style="background-color:#BCF5A9">The discussion is closed, the following action has been taken: RH: As per telecall 20121019 agreed, the owner and its details is something in the DPM, the owner aspects are not XML artefacts that need definition in a schema. Adjusted the definition accordingly and removed the pointer from the article. Extensions is a major subject being dealt with in another article.</span> | ||
| === Comment-03 === | === Comment-03 === | ||
| - | RH: Public elements are just XBRL concepts, why not use that term? Moreover, IMO the MUST contain labels and definitions. How else are you going to interpret them? I advise not to hard link all the different languages. Too much overhead if you want Spanish only. | + | RH: Public elements are just XBRL concepts, why not use that term? Moreover, IMO they MUST contain labels and definitions. How else are you going to interpret them? I advise not to hard link all the different languages. Too much overhead if you want Spanish only. |
| + | |||
| + | TD: I agree. I guess that some people in the XBRL community are in favor of the "MAY" include labels and definitions, since the resource naming convention sahould be making sense (in the camle notation). But in the medium term, I think htat this naming convention will disappear. So yes, a must for labels. | ||
| + | I think we need to enforce also some terminological principles for the text to be included in labels and definitions. | ||
| + | Also making an English label obligatory, besides the national language (supporting interoperable understanding of the labels). | ||
| + | Here we should re-use partly the SKOS approach to labels. | ||
| + | |||
| + | KH: As we are defining Best Practices and Recommendations I think that the term "SHOULD" for recommendation is sufficient. A "MUST" can not be inforced by CEN/NEN. | ||
| + | As there are public elements, dictionary elements, abstract items, base items, metrics, measure, primaries etc. the connection between those terms is needed. Maybe an UML showing the relations between those concepts or getting rid of double namings. | ||
| + | Are secondary concepts part of the dictionary? | ||
| + | |||
| + | TD: Katrin, just to precise: I was talking about "labels" and "definitions" (as Roland also did, I think). If those are building blocks of the taxonomies, then they have to be there and instantiated with understandable values. I just also had a look at BPMN (just because someone talked to me about Business Process Modeling and if this could be palying a role for Business Reporting), and there the Annotation is not mandatory, and people can use as marker either an icon or a word, or leave the marker empty. I am in favor of having "labels" as normative parts of XBRL taxonomies. | ||
| + | |||
| + | === Comment-04 === | ||
| + | KH: Proposal to rename public elements and/or dictionary elements: | ||
| + | |||
| + | public element --> history element or continuation element or continuabel element | ||
| + | |||
| + | dictionary element --> validity element | ||
| + | |||
| + | TD: I think I need to get more information about this. Will check. | ||
| + | |||
| + | === Comment-05 === | ||
| + | KH: Is metric the correct definition for primary elements? | ||
| + | Definitions I found on the web:<br/> | ||
| + | 1. Metrics are a set of measurements that quantity results.<br/> | ||
| + | 2. Standards of measurement by which efficiency, performance, progress or quality of a plan, process or product can be assessed.<br/> | ||
| + | 3. A metric is a number.<br/> | ||
| + | 4. A measured variable that is tracked and can be used to detect errors or variation and make improvements.<br/> | ||
| + | 5. Metrics (in business) a set of figures or statistics that measure results.<br/> | ||
| + | |||
| + | In most cases a metric is a data point which consists not only of one concept but of a bunch of dimensional information together with the primary item to express the full meaning. I would prefer to use the term primary item to distinguish in XBRL terms from dimension and its members. So it is also ok to have different data types (on primary items) deviate from numbers. | ||
| + | |||
| + | TD: I didn't see the definition of "primary element" in the text yet. But yes, I was getting confused about the meaning of "abstract" and "fact". Can something that "represents a fact" (definition of "item") be abstract? Looking at the definition of "Primary", it states that within xbrli:item we have also a non-abstract concept for carrying facts in an instance. I am a bit confused here (although I included the definition of an "item" :-( ) | ||
| + | |||
| + | === Comment-06 === | ||
| + | TD: "The objective of the EXTA is to create an XBRL taxonomy that is". I am not sure about this one. Is the objective to create a taxonomy or to propose guidelines for the creation of taxonomies? | ||
| + | |||
| + | <span style="background-color:#BCF5A9">The discussion is closed, the following action has been taken: RH: agreed, needed rewording, adjusted. Removed comment in article.</span> | ||
| + | |||
| + | === Comment-07 === | ||
| + | RH: It can be very confusing to have a definition of taxonomies that is not the same as the one from XII. | ||
Current revision
Contents |
Comments
Comment-01
RH: Is this terminology stable? I've seen 'report' as term for 'framework' and trying to grasp the essence of a framework I think that it represents a number of forms or tables. In essence its just a semantic name given to a number of forms and or tables, its not defining anything for itself, only by derivation of what it groups. A report (IMO) also represents a single form or table. Which is why I put framework as the proposed name. OTOH the framework seems to represent business rules too and that is not always correct since business rules can be applied on dictionary level, on framework level or on single table and even cell level.
KH: A framework consists of reporting regulations for a domain specific scope of information. The information requirements are structed in form of tables to ease the understanding for the institutions that are obliged to submit the reporting information to the supervisor. All business rules to be met by the reporting entities are defined in the reporting regulations. Some of these rules are also incorporated in the table design to show which detailed information are being part of a summation. Others are only reflected inside the regulations itself.
TD: If I see right, our work in CEN/XBRL could consist in proposing a "meta model" for building XBRL taxonomies, which should be following national frameworks. Framework can be seen as (stable) conceptual structure (which should contain the frames, rules, constraints, etc for modeling the national legislation). I think we are in sync here (especially with Katrin). Our guidelines would then be about that, what people or insitutions need in order to model their regulation frameworks. So yes, the basic constituents ("concepts", "rules", "links", "labels", etc), could be considered as the dictionary, while the particular way of building a taxonomy corresponding to a particular legislation could be the "grammar".
Comment-02
RH: The occurences of the owner and his IP rights and supportive languages etc. appear to me to be facts, not meta data expressed in namespace, concepts etc. The owner name is already expressed through the namespace of each schema.
KH: Maybe it is better to have a separate section dealing with extensions and to explain there the concepts of owner. The taxonomy architecture should IMHO not deal with IP rights.
TD: True. names of owner etc are additional features I think. Is what we find in the namespace always the owner, or can it be the legislation etc.?
The discussion is closed, the following action has been taken: RH: As per telecall 20121019 agreed, the owner and its details is something in the DPM, the owner aspects are not XML artefacts that need definition in a schema. Adjusted the definition accordingly and removed the pointer from the article. Extensions is a major subject being dealt with in another article.
Comment-03
RH: Public elements are just XBRL concepts, why not use that term? Moreover, IMO they MUST contain labels and definitions. How else are you going to interpret them? I advise not to hard link all the different languages. Too much overhead if you want Spanish only.
TD: I agree. I guess that some people in the XBRL community are in favor of the "MAY" include labels and definitions, since the resource naming convention sahould be making sense (in the camle notation). But in the medium term, I think htat this naming convention will disappear. So yes, a must for labels. I think we need to enforce also some terminological principles for the text to be included in labels and definitions. Also making an English label obligatory, besides the national language (supporting interoperable understanding of the labels). Here we should re-use partly the SKOS approach to labels.
KH: As we are defining Best Practices and Recommendations I think that the term "SHOULD" for recommendation is sufficient. A "MUST" can not be inforced by CEN/NEN. As there are public elements, dictionary elements, abstract items, base items, metrics, measure, primaries etc. the connection between those terms is needed. Maybe an UML showing the relations between those concepts or getting rid of double namings. Are secondary concepts part of the dictionary?
TD: Katrin, just to precise: I was talking about "labels" and "definitions" (as Roland also did, I think). If those are building blocks of the taxonomies, then they have to be there and instantiated with understandable values. I just also had a look at BPMN (just because someone talked to me about Business Process Modeling and if this could be palying a role for Business Reporting), and there the Annotation is not mandatory, and people can use as marker either an icon or a word, or leave the marker empty. I am in favor of having "labels" as normative parts of XBRL taxonomies.
Comment-04
KH: Proposal to rename public elements and/or dictionary elements:
public element --> history element or continuation element or continuabel element
dictionary element --> validity element
TD: I think I need to get more information about this. Will check.
Comment-05
KH: Is metric the correct definition for primary elements?
Definitions I found on the web:
1. Metrics are a set of measurements that quantity results.
2. Standards of measurement by which efficiency, performance, progress or quality of a plan, process or product can be assessed.
3. A metric is a number.
4. A measured variable that is tracked and can be used to detect errors or variation and make improvements.
5. Metrics (in business) a set of figures or statistics that measure results.
In most cases a metric is a data point which consists not only of one concept but of a bunch of dimensional information together with the primary item to express the full meaning. I would prefer to use the term primary item to distinguish in XBRL terms from dimension and its members. So it is also ok to have different data types (on primary items) deviate from numbers.
TD: I didn't see the definition of "primary element" in the text yet. But yes, I was getting confused about the meaning of "abstract" and "fact". Can something that "represents a fact" (definition of "item") be abstract? Looking at the definition of "Primary", it states that within xbrli:item we have also a non-abstract concept for carrying facts in an instance. I am a bit confused here (although I included the definition of an "item" :-( )
Comment-06
TD: "The objective of the EXTA is to create an XBRL taxonomy that is". I am not sure about this one. Is the objective to create a taxonomy or to propose guidelines for the creation of taxonomies?
The discussion is closed, the following action has been taken: RH: agreed, needed rewording, adjusted. Removed comment in article.
Comment-07
RH: It can be very confusing to have a definition of taxonomies that is not the same as the one from XII.
