Talk:European XBRL Taxonomy Architecture
From XBRLWiki
(diff) ←Older revision | Current revision | Newer revision→ (diff)
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.
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.
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?
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
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.
