Talk:European Data Point Methodology V2.0

From XBRLWiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 12:13, 11 October 2013 (edit)
Anna-Maria.Weber (Talk | contribs)
(Comment-15)
← Previous diff
Current revision (12:14, 11 October 2013) (edit)
Anna-Maria.Weber (Talk | contribs)
(Comment-17)
 
Line 55: Line 55:
=== Comment-12 === === 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 === === Comment-13 ===
Line 67: Line 63:
=== Comment-16 === === 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 === === 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 ===

Current revision

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

Comment-11

Comment-12

Comment-13

Comment-14

Comment-15

Comment-16

Comment-17

Comment-18

Comment-19

Comment-20

Comment-21

Comment-22

Comment-23

Personal tools