Talk:European Data Point Methodology
From XBRLWiki
| Revision as of 09:07, 27 February 2013 (edit) Katrin (Talk | contribs) ← Previous diff |
Revision as of 09:07, 27 February 2013 (edit) Katrin (Talk | contribs) (→Comment 06) Next diff → |
||
| Line 27: | Line 27: | ||
| === Comment 06 === | === Comment 06 === | ||
| RH: Why would the attributes validFrom and validTo not apply to all public elements? Taxonomy already has them added, but I think the tables and hierarchies etc. are also only valid for a certain period in time. Or is this validFrom and validTo meant as a restriction within a certain version of the complete taxonomy? (maybe also indicating that if these attributes are not present, the dictionary element is valid for the whole version of the taxonomy?)<br/> | RH: Why would the attributes validFrom and validTo not apply to all public elements? Taxonomy already has them added, but I think the tables and hierarchies etc. are also only valid for a certain period in time. Or is this validFrom and validTo meant as a restriction within a certain version of the complete taxonomy? (maybe also indicating that if these attributes are not present, the dictionary element is valid for the whole version of the taxonomy?)<br/> | ||
| - | KH: Explanation by Victor Morilla<br/> | + | KH: Explanation by Victor Morilla:<br/> |
| The validity dates in the dictionary were meant to make easier the management of the dictionary. Having a unique dictionary means it eventually will grow and become harder to maintain. Using the validTo makes possible a situation where a concept is still used for reporting in a certain taxonomy, but at the same time we remove it from the list of “current” concepts, and so, we avoid it being used in a new taxonomy. | The validity dates in the dictionary were meant to make easier the management of the dictionary. Having a unique dictionary means it eventually will grow and become harder to maintain. Using the validTo makes possible a situation where a concept is still used for reporting in a certain taxonomy, but at the same time we remove it from the list of “current” concepts, and so, we avoid it being used in a new taxonomy. | ||
| A taxonomy is defining a set of data requirements. As those requirements change in time, new versions of the taxonomy should be released, and ideally, no overlap in time should happen. When defining a taxonomy, I expect users to make use only of current concepts. Someone might decide that this concept should become obsolete in a few months (this meaning that they don’t want it to be used in future taxonomies), but as long as “data” requirements are not changed, I don’t expect any changes in the taxonomy, and thus, that concept will be in use in the reporting process. | A taxonomy is defining a set of data requirements. As those requirements change in time, new versions of the taxonomy should be released, and ideally, no overlap in time should happen. When defining a taxonomy, I expect users to make use only of current concepts. Someone might decide that this concept should become obsolete in a few months (this meaning that they don’t want it to be used in future taxonomies), but as long as “data” requirements are not changed, I don’t expect any changes in the taxonomy, and thus, that concept will be in use in the reporting process. | ||
| - | |||
| - | |||
| - | |||
| - | |||
| === Comment 07 === | === Comment 07 === | ||
Revision as of 09:07, 27 February 2013
Contents |
Comments
Comment-01
RH: this does not take anything away for authors not providing a clear definition of each of the aspects that forms a single data point (or cell in a table).
Comment-02
RH: The explanation is mixing elements with members. For DPM member hierarchies have more meaning than 'normal' element hierarchies may have.
KH: The name elements has been replaced by members.
RH: But the UML does not show a relationship between the classes member and hierarchies. Is the UML mixing how components are defined in XML and how they should be used in modelling?
The discussion is closed, the following action has been taken: Definition have been moved to the corresponding perspective. Changed by KH
Comment-03
TD: Editorial Comment: I would write : "data structures *that can be* represented in supervisory tables" //// (similar to the following clause)
KH: Changed accordingly.
The discussion is closed, the following action has been taken: Text has been corrected. Changed by KH
Comment-04
TD: Editorial Comment: I think we should include in this section later all the terms and definitions the document is making use of , even if the terms and definitions are not imported from other documents.
KH: The description of the meta model consists of the introduction of terms and definitions. It is not yet agreed if the terms should be repeated in this chapter.
Comment-05
TD: I think the the sentence: "the model components for the creation of a formal models on sets of data points for European supervisory reporting frameworks" could be rewritten like: "the components for the construction of a formal model that describes sets of data points relevant to European supervisory reporting frameworks" (or similar).
KH: Changed accordingly.
The discussion is closed, the following action has been taken: Text has been corrected. Changed by KH
Comment 06
RH: Why would the attributes validFrom and validTo not apply to all public elements? Taxonomy already has them added, but I think the tables and hierarchies etc. are also only valid for a certain period in time. Or is this validFrom and validTo meant as a restriction within a certain version of the complete taxonomy? (maybe also indicating that if these attributes are not present, the dictionary element is valid for the whole version of the taxonomy?)
KH: Explanation by Victor Morilla:
The validity dates in the dictionary were meant to make easier the management of the dictionary. Having a unique dictionary means it eventually will grow and become harder to maintain. Using the validTo makes possible a situation where a concept is still used for reporting in a certain taxonomy, but at the same time we remove it from the list of “current” concepts, and so, we avoid it being used in a new taxonomy.
A taxonomy is defining a set of data requirements. As those requirements change in time, new versions of the taxonomy should be released, and ideally, no overlap in time should happen. When defining a taxonomy, I expect users to make use only of current concepts. Someone might decide that this concept should become obsolete in a few months (this meaning that they don’t want it to be used in future taxonomies), but as long as “data” requirements are not changed, I don’t expect any changes in the taxonomy, and thus, that concept will be in use in the reporting process.
Comment 07
RH: How does this notion of information on which components belong to which framework, actually looks in the model? Is it through some kind of relationship? That is not shown in the UML. Since framework and the other public elements are on the same level, no relationships between their content is being made.
Comment 08
RH: Which does not show in the UML since the classes of framework and taxonomy are side by side.
Comment 09
RH: How does this interact with the attributes validFrom and validTo in the dictionary? Is one overruling the other?
Comment 10
RH: How does this look in practice? There are a bunch of elements that can be reused in every taxonomy because (eg.) they have no @validTo value, and others may also be used but only for a limited time? Does this in practice mean that a table could stop supporting certain dictionary elements during the year without releasing a new taxonomy? Do people even realize this and is software presenting dictionary elements considers if these elements are valid? Is the validity meant technical or semantical? I.e. can you still report an element with a validTo date in the past because your facts are about the past or does something (formula, software) keep you from filing this element?
Comment 11
RH: The XBRL description doesn't point to an element (concept) but to a 'set of members'. Could something more specific been put in that describes how a domain looks in XBRL? If not a concept, than something like 'is the parent in domain-member relationships which carry the same parent in the same linkrole' or so.
Comment 12
RH: This is referring to xbrldi, which is the INSTANCE and not the DTS side. Is this a good idea?
Comment 13
RH: I can't follow the 'therefor' bit. I can see what Perspectives can be, but the relationship between dimensions and families makes it obscure. Maybe a family is for presentation purposes and perspectives for more semantic groupings of dimensions?
