Talk:European Data Point Methodology V2.0

From XBRLWiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 07:18, 10 October 2013 (edit)
Anna-Maria.Weber (Talk | contribs)
(Comment-16)
← Previous diff
Revision as of 07:22, 10 October 2013 (edit)
Anna-Maria.Weber (Talk | contribs)
(Comment-17)
Next diff →
Line 97: Line 97:
=== Comment-17 === === Comment-17 ===
 +
 +Multiplicity: exactly one
 +
 +BdF:"One or more"
 +RH: Bring in line with previous comments. If Dimension can be open, than N is possible, if only closed than 'just one'.
=== Comment-18 === === Comment-18 ===

Revision as of 07:22, 10 October 2013

Contents

Comments

Comment-01

[TD] Or better "Introduction" for section title? (comment "b" in the file Comments about CEN/TC XBRL)

Comment accepted. TD to adapt

Comment-02

[TD] Ignacio suggests "In the page 7, figure: Figure 1 —Structural Perspective, the cardinality of 1 is not necessary. [TD: I can not change the graphics]

Comment rejected.

Comment-03

[TD] Ignacio suggests here to repleace the sentence above the comment with: "In the DataPointModel a Hierarchy forms are sets of concepts of a domain (DefinedMembers) of a dimension (EnumerableDimension) arranged in a hierarchical disposition." Myself I note a problem with the expression: "a Hierarchy forms are sets" (should it bee "a Hierarchy forms sets ..."?

Comment accepted: "are sets" -> "a set" TD to adapt.

Comment-04

[TD] Suggestion by I. replace "A Module is a group of DataCubes that carry relevant identical semantics and may serve the reporting process" with "A Module is a group of DataPoints with its appropriate Dimensions and concepts of the dimension (DataCubes) ...."

Comment to be further processed: make sure that ref links are present in the Word Document.

Comment-05

[TD] Suggestion by I.: “4.3.10 Dimension, …. A Dimension can refer to a Domain. ….”. I would exchange by in “4.3.10 Dimension, …. A Dimension must refer to a Domain. ….”.

Comment rejected.

Comment-06

[TD] Comment by I. :“4.6 Hierarchical Perspective …. 1) When using multiple DimensionedElements on a single Dimension that has a Hierarchy in its DefinedMembers, the required math may not be possible to perform.”. I don’t understand. Only, it is possible to define a data point with only a member domain by dimension. Is this that you want to say?

Comment accepted. Roland to edit the segment.

Comment-07

[TD] Comment by I. : h. In page 18, “4.6.2 RuleRelationship … The list of possible signs in a DataPointModel is not determined. Examples are: + (plus sign) or - (minus sign). ….”. Can have in a hierarchy “*” or “/”? I think: “4.6.2 RuleRelationship … The list of possible signs in a DataPointModel must be “+” or “-“. Examples are: + (plus sign) or - (minus sign). ….”.

[TD] But I think this comment refers to a previous version of the document.

Comment reject.

Comment-08

[TD] comment by I.: figure 5, the arrow to tablesheet is longer. [TD: I can not modify the graphics

Comment accepted. Katrin to modifiy.

Comment-09

it is a doubt. “Rule 1.9 — There MUST NOT be a doubling of DefinedMembers in the same Dimension. A DefinedMember MUST only be references once in a Dimension.”. I understand that a member domain can belong to several dimensions, cannot it?

Comment rejected.


Comment-10

“In general” should be added before parameters. The rest like Booleans or strings are exceptions. Multidimensional models are in general oriented to analysis.

Comment-11

Each DataPoint MUST be represented in one DataCube

Suggestion: Replace /one/ by /exactly one/ (not one or more)

KH: Same DataPoint could be used in COREP and FINREP.

Comment-12

BdF:"“A DataCube must be part of at least one Module” This rule forbids a modelled information that is not yet in production." RH:"Indeed, is that a requirement? Models should be able to contain information that is not (yet/anymore) used?" KH: "The currency period rules the begin of production."

Comment-13

Suggestion by BdF: "The business template is to be split in two or more tables to prevent that the same Dimension is associated to more than one axis"

RH: Hmmm. It's not about separating the dim from X and Y, but from X1 and X2.

Comment-14

BdF: "I think in DPM, a domain can reference several dimensions"

RH: In XBRL, yes. In (Victors) DPM, no. KH: The link in the graph is unidirectional. The domain does not know which dimension refer to it.

Comment-15

BdF:" A dictionaryElement can be owned by several taxonomy" RH: Not in the setup where all elements are created only once. Either re-use the schema or use versioning. KH: What about metrics that are defined for COREP and FINREP

Comment-16

Multiplicity: exactly one

BdF:"A dataCube can reference several modules, this is the case in Solvency II taxonomy " RH: Are you sure you don't mean a datapoint that is used in N modules? A DataCube is a collection of datapoints, why would you want to 're-use' them in several modules? KH: Datacube can be referenced in modules that are divided in solo and consolidate reporting. Solo and consolidated is marked by one primary that gives the information about the dimensional information. Really bad modelling!


Multiplicity: zero or one

BdF:"Zero or more" RH: Depends on outcome of the previous comment KH: Can a DataPoint be referenced by two or more DataCubes?

Comment-17

Multiplicity: exactly one

BdF:"One or more" RH: Bring in line with previous comments. If Dimension can be open, than N is possible, if only closed than 'just one'.

Comment-18

Comment-19

Comment-20

Comment-21

Comment-22

Comment-23

Personal tools