Talk:European Data Point Methodology

From XBRLWiki

Contents 1 Comments 1.1 Comment-01 1.2 Comment-02 1.3 Comment-03 1.4 Comment-04 1.5 Comment-05 1.6 Comment-06 1.7 Comment-07 1.8 Comment-08 1.9 Comment-09 1.10 Comment-10 1.11 Comment-11 1.12 Comment-12 1.13 Comment-13 1.14 Comment-14 1.15 Comment-15 1.16 Comment-16 1.17 Comment-17 1.18 Comment-18 1.19 Comment-19 1.20 Comment-20 1.21 Comment-21 1.22 Comment-22 1.23 Comment-23

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).
The discussion is closed, the following action has been taken: Text has been corrected. Changed by KH

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.
KH: Hyperlinks could be used to prevent repetitions.

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.
KH: Constraints should be added that describe the link between validTo and validFrom of Dictionary Elements to the currency period of a Taxonomy.
RH: And the creationDate of the Public element class that is inherited.

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. The discussion is closed, the following action has been taken: Definition have been moved to the corresponding perspective. Changed by KH

Comment-08

RH: Which does not show in the UML since the classes of framework and taxonomy are side by side.
KH: The versioning perspective has been switched so taxonomy and framework are explained togegher.
The discussion is closed, the following action has been taken: Perspective and explanations have been moved. Changed by KH

Comment-09

RH: How does this interact with the attributes validFrom and validTo in the dictionary? Is one overruling the other?
KH: see Comment 06
The discussion is closed, the following action has been taken: Explanation added to comment 06. Changed by KH

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?
KH: see Comment 06
The discussion is closed, the following action has been taken: Explanation added to comment 06. Changed by KH

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.
KH: The comment has been moved to Enumerable Domain. The XBRL equivalent for Domain has been removed.
The discussion is closed, the following action has been taken: Information concerning XBRL mapping has been moved to page 'European XBRL Taxonomy Architecture'. Changed by KH

Comment-12

RH: This is referring to xbrldi, which is the INSTANCE and not the DTS side. Is this a good idea?
The discussion is closed, the following action has been taken: Information concerning XBRL mapping has been moved to page 'European XBRL Taxonomy Architecture'. Changed by KH

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?
KH: Explanation by Victor Morilla:
Think of the following example:

A: family of important dimensions
B: other dimensions

For FINREP guys, dimensions X,Y,Z are important. But for COREP guys dimensions D,E and F are the important ones. The “FINREP” and “COREP” views are two different perspectives, but the families A and B are the same. This way, FINREP guys can work the way they want and COREP guys the way they want too (each one sees under family A the dimensions that are sensible to them).

Comment-14

RH: Do we actually need a domain? If you look at the definition of what a domain is, it resembles awfully close the definition of a dimension. Maybe its an option to view upon a domain as on a Family: a grouping kind of thing that can have a label but doesn't actually do anything, other than give some extra semantic meaning to 'a group of members' (not being a dimension). This would 'solve' the problem of the 1:1 between dim-dom from the EBA point of view, and would still allow for the 1:N dim-dom seen from a more general semantic point of view.
The discussion is closed, the following action has been taken: Domain is being referenced by Dimension. Dimensions are now of type enumerable or non-enumerable. Changed by KH

Comment-15

RH: A member is also a dictionary element, relationship member-dictionary element is missing.
The discussion is closed, the following action has been taken: Incorrect super class has been removed. Changed by KH

Comment-16

RH: This leaves out that taxonomies may overlap during some time (for business or technical reasons) and it leaves out the technique of extensions where the 'base' taxonomy may eventually have a different currency period than the extension.
The discussion is closed, the following action has been taken: No reference to XBRL anymore. This should be dealed in the mappping section DPM to XBRL. Changed by KH

Comment-17

RH: The mentioned 'table' is not the public element 'Table' I hope? Maybe use a different term to avoid confusion.
The discussion is closed, the following action has been taken: table has been changed to 'Table'. Changed by KH

Comment-18

RH: The definition and other text on frameworks do not explain what it has to do with the Versioning view in which the relationships are being expressed.
The discussion is closed, the following action has been taken: Text has been moved to the Structural Perspective. Changed by KH

Comment-19

RH: TableGroups are mentioned but not a class anywhere, maybe Module is meant? The text suggests that tables are only for presentation purposes. If so, what is the dimensional space being called that often represented as a table?
The discussion is closed, the following action has been taken: Business Template has been replaced by TableGroup. Business Template is no longer a class but explained in the text. Changed by KH

Comment-20

RH: UML is not representing the text (or v.v.). A Data Point MUST have at least one Dimension. No non-dimensioned Dimensioned Elements are allowed in DPM, correct? A Dimension can have 1-N Members (not 0). It looks like the Data Point itself is an abstract class, or it can host the reported value.
The discussion is closed. Included text that dimensions are optional but that no dimensional validation could take place in such a case. By RH.

Comment-21

RH: I don't see any reason why a hierarchy MUST be present in DPM. Both for members and dimensioned elements. The whole sentence about domains needs careful consideration. Is it a DPM requirement that a hierarchy amongst members can only be hosted by a domain? This is cumbersome if members are nested in multiple levels. Maybe only the root of a member hierarchy must be a domain. If so, why? Also if the root of a hierarchy is so important that it needs its own term, what is the root for Dimensioned Elements called?
Another point is that calculation hierarchies CANNOT be placed upon members because that would enforce that these members can only be used in conjunction with Dimensioned Elements of type 'decimal', which would be a strange restriction. Maybe an EBA special, but hardly 'normal' for the whole of the model.
Strikken from the article is: "For DPM all DefinedMembers and DimensionedElements MUST be represented in at least one Hierarchy". Because it is thought that this an EBA or XBRL design rule, not a DPM rule.
KH: The hierarchy is an essential information in a DPM because it show the relations between members and this informationen eases the understanding for the DPM and also the maintenance of the model. Hierarchies should be one of the first decision after adding one member to a domain. DPM experts advise to add each member of the DPM to an hierarchy. From a DPM point of view an hierarchy could be related to a domain or a dimension. It is essential that the dimension refers to a hierarchy so that is clear who the members are structured when being analyised under a specific business meaning given by a dimensaion.
It should be taken care of the relations between hierarchies. For example a hierarchy will break when different dimensioned elements (metrics) are accociated.

Comment-22

RH: Hierarchy does not have a relation with Enumerable domain, the HierarchyRelationship the the expression of the relation between members (in a domain or not) and those run through the Dictionary Element. Same for dimension. So I think the Hierarchy must link to the Dictionary Elements and not to domain or dimension. Plus dimension is in there twice. The Hierarchy-Dictionay Element must have two relationships (for parent and child) and maybe in the text some detailing what kind of Dictionary elements can be used to form Hierarchies. It's not intended to connect all to all I think?

Comment-23

KH: Comment by Ignacio Santoz: Between Dimension and Family is 0..* (in dimension), and 1 (Family). A dimension only has only a family.