The author is a fellow member of the Institute of Chartered Accountants of India.
One response to “Dimensions in XBRL : A Primer”
Grinnan Bharat
Many errors and misunderstandings in this presentation.
Slide 3: Dimensions are NOT tied to presentation tables. Dimensions can be equally relevant to numbers (or text!) in columns or text, if it can be better modelled multi-dimensionally.
Slide 4: Claim that dimensions simplifies tagging ignores ease of tagging selection on a one-to-one basis. Much more difficult to choose from line items and multiple concurrent data points.
Capability was NOT added by Dimensions 1.0 (not Dimension 1.0); it was formalized by Dimensions. Segment and scenario are part of the basic Spec. and permitted this in the company’s own namespace.
Slide 8: The hypercube definition is oversimplified; it is not a dimensional representation, but a collection of axes; without the primary item, which may reference multiple hypercubes, it is only abstract. Don’t confuse the presentation and definition linkbases.
The primary item is not so simple; generally it is not the primary item concept being represented; it is other items in a domain-member relationship with the primary item that are represented. Again, don’t confuse the presentation and definition linkbases.
Slide 11 and following: The dimension versus tuple discussion shows a strong bias against tuples not based on experience and lack of understanding of how tuples work – and can work with dimensions. They are not mutually exclusive.
Slide 12: Tuples are not limited to 2-dimensional. And dimensions are horrible at highly nested data, at which tuples excel. Tuples are not less functional; they are differently functional.
Slide 13: Tuples do not necessarily mean a higher number of elements in the taxonomy. The issue is that tuples potentially cause metadata to not be captured, moving them to data. Dimensions (explicit) pushes what should be data into metadata.
Dimensions don’t just cause a higher number of contexts (an incredibly higher number especially for highly hierarchical data); they also cause extremely bigger file sizes.
CA Nirmal Ghorawat's Blog 
One response to “Dimensions in XBRL : A Primer”
Many errors and misunderstandings in this presentation.
Slide 3: Dimensions are NOT tied to presentation tables. Dimensions can be equally relevant to numbers (or text!) in columns or text, if it can be better modelled multi-dimensionally.
Slide 4: Claim that dimensions simplifies tagging ignores ease of tagging selection on a one-to-one basis. Much more difficult to choose from line items and multiple concurrent data points.
Capability was NOT added by Dimensions 1.0 (not Dimension 1.0); it was formalized by Dimensions. Segment and scenario are part of the basic Spec. and permitted this in the company’s own namespace.
Slide 8: The hypercube definition is oversimplified; it is not a dimensional representation, but a collection of axes; without the primary item, which may reference multiple hypercubes, it is only abstract. Don’t confuse the presentation and definition linkbases.
The primary item is not so simple; generally it is not the primary item concept being represented; it is other items in a domain-member relationship with the primary item that are represented. Again, don’t confuse the presentation and definition linkbases.
Slide 11 and following: The dimension versus tuple discussion shows a strong bias against tuples not based on experience and lack of understanding of how tuples work – and can work with dimensions. They are not mutually exclusive.
Slide 12: Tuples are not limited to 2-dimensional. And dimensions are horrible at highly nested data, at which tuples excel. Tuples are not less functional; they are differently functional.
Slide 13: Tuples do not necessarily mean a higher number of elements in the taxonomy. The issue is that tuples potentially cause metadata to not be captured, moving them to data. Dimensions (explicit) pushes what should be data into metadata.
Dimensions don’t just cause a higher number of contexts (an incredibly higher number especially for highly hierarchical data); they also cause extremely bigger file sizes.