Talk:Syntax Rules

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

Comments

Comment-01

RH: Is it also mandatory to have dates and/or dateTimes in them? Is the first modification date equal to the creation date?
KH: I'd propose to ask Victor. In my opinion there should be only a date and their should be a mandatory creation date. For me it is not clear when the modification date must be set. There could be changes on labels, references or attributes on the concept.
RH: The addition of attributes like this should only be considered if they add value to the reporter. I have not seen any functionality connected to these attributes so I assume they are a remainder of the DPM and the maintenance requirements of the DTS owner. I would not burden the reporter with it and remove them from the taxonomy.

Comment-02

RH: THis is a new construct: a concept being a resource? I think something else is meant.
KH: This question should be answered by Victor.

Comment-03

RH: At one time there was discussion of having cube/table dependent labels on items (don't know just primaries or also members). This was done through assigning label relationships into the same ELR as the cube was made in. This idea has been left?
KH: Table related labels are going to be defined because the DPM labels can differ. As far as I know they are defined by generic labels.
RH: If labels (i.e. meaning / definition) of concepts or members can be changed according to the table they are used in, there is a huge risk for conflicts. In essence you would only need about 15 primaries and 40 members to construct ANY table you'd like because the labels and defintion change for each of those primaries and members per table. In the instance there is however NO reference to labels. It would therefor be completely unclear what the intended defintion of the primary / member was when the fact value was placed. This would be a very bad thing.

Comment-04

RH: verboseLabel is NOT the place to put the definition of a concept. The documentationLabel was intended for that. See 2.1 spec. documentation. This would set a bad precedent.
KH: Why not use the reference linkbase? Extensions will be possible on COREP. I think verbose labels are used to store the labels according to the table/template.

Comment-05

RH: documentationLabels and (legal) references are two completely different animals. Legal references cannot be in plain English as suggested in the source document. A reference is always something of a pointer, possibly a set of pointers (law, article, paragraph etc.). If the structured approach of these references using link:part is too complex for the users, another (single) reference (maybe even custom) may be in order, but DO NOT try to put structured information concatenated into a label resource.
KH: I would recommend to use the reference linkbasea for dealing with references to law even when only English is currently available.

Comment-06

RH: Making these attributes optional introduces 'default' behaviour for non presence. I would vote to make them mandatory (explicit) and work with the 'xbrli:Forever' name for the content of the model:toDate if appropriate.

Comment-07

RH: Including these attributes not for the reporting process but for managing the taxonomy is a bad idea. Information that is not intended for the reporters should not be included. It is very easy to create a proprietary linkbase holding these attributes (as part of a resource for instance) and keep this linkbase for internal use only.
KH: I think this information is relevant for the reporters because it shows them that a fact can not be longer reported because the validity ended to a specific date.
RH: A detail problem may be that they can only SEE that date. The software that does the mapping is not aware and XBRL presentation of tables and hierarchies ignores this attribute. Users would be forced to look at the syntax to see this date.

Comment-08

RH: This rule of @balance on the dimension 'base item' needs to be explained and changed, and the name needs to be confirmed. It is XBRL invalid to have @xbrli:balance on non monetaryItemType concepts. It is XDT invalid to have @xbrli:balance on xbrldt:dimensionItem concepts. Maybe a proprietary '@model:balance' was meant?
This 'trick' looks like it serves the purpose of circumventing the members to be entered as primaries but in the presentation need to be treated as primaries nevertheless. IMO it is a sign of something wrong in the model.

Comment-09

RH: It looks like families are NO type but a complete new construct making them @substitionGroup content. (A type predicts the base type and since its abstract, there is no base type, ergo: this is a substitutionGroup just like dimensionItem and hypercubeItem, even the name says so).

Comment-10

RH: Are other explicit members to be equipped with @model:isDefaultMember='false'?
RH: Is there a mandate to check if a default member is also discovered with a dimension-default relationship?

Comment-11

RH: It looks like frameworks are NO type but a complete new construct making them @substitionGroup content. (A type predicts the base type and since its abstract, there is no base type, ergo: this is a substitutionGroup just like dimensionItem and hypercubeItem, even the name says so).

Comment-12

RH: It looks like taxonomies are NO type but a complete new construct making them @substitionGroup content. (A type predicts the base type and since its abstract, there is no base type, ergo: this is a substitutionGroup just like dimensionItem and hypercubeItem, even the name says so).

Comment-13

RH: It looks like tableGroups are NO type but a complete new construct making them @substitionGroup content. (A type predicts the base type and since its abstract, there is no base type, ergo: this is a substitutionGroup just like dimensionItem and hypercubeItem, even the name says so).

Comment-14

RH: By nesting metrics in domain-member relationships, a hierarchical relationship that is not meant MAY be suggested. To prevent this either the use of a proper domain (there could be just one for the whole of the DTS) or linking the metrics directly to the cube through the 'all' arc.