From: Ignacio Hernandez-Ros [mailto:ihr@xbrl.org]
Sent: Thursday, June 08, 2006 11:21 AM
To: 'Chou, Kuo-hua'; 'hughwallis@xbrl.org'
Subject: RE: Comments on XBRL Dimensions 1.0, 2006-04-26 version.

Ignacio Hernandez-Ros

XBRL International Inc. - Technology Development

ihr@xbrl.org

Cell: +34 609027754

 

Dear IHR and Hugh Wallis,

 

I am Kuo-hua Chou from Taiwan.

After reviewing the 2006-4-26 version of Dim 1.0, I have the following comments:

 

1. In Section 1.1, the paragraph says “….. Because the multidimensional information is represented by arcs and XBRL concepts and there is no way in XBRL to specify the role of a taxonomy it is possible for one taxonomy to play two or all of these roles simultaneously.”

My comment:

Since FRTA rule 4.2.1 prohibits a schema containing both taxonomy concepts and content for context segment and scenario elements, it seems to me that it is not possible for one taxonomy to play all of the three roles, if it is to be approved.

 

2. In Section 2.2.2, the third paragraph says “The hypercube-dimension relationship role MUST NOT have any directed cycles.”

My comment:

Since the value of the cyclesAllowed is “none”, I prefer the following wording: “The hypercube-dimension relationship role MUST NOT have any directed or undirected cycles.”

[IHR] The proposed change has been incorporated. But I believe undirected cycles are not possible because the elements MUST be in specific substitution groups (“hypercubeItem” and “dimensionItem”). Undirected cycles require at least three elements in the same extended link and hypercube modeling should be done in different extended links connected with the targetRole attribute to avoid conflicts.

 

3. In Example 5, the attached note says “…. Note that hc_Team_x_Drink has segment in its xbrldt:contextElement attribute and hc_Empty has scenario in its xbrldt:contextElement attribute.”

My comment:

I prefer the following wording: “…. Note that the all arc to hc_Team_x_Drink has segment in its xbrldt:contextElement attribute and the all arc to hc_Empty has scenario in its xbrldt:contextElement attribute.”

[IHR] Done, Thanks.

 

4. In Example 10, the hcRegion_x_Product in the attached note should be corrected as hc_Region_x_Product.

[IHR] Good catch. Done. Thanks.

 

5. I am still confused by the last row in the attached table of Example 12. In my opinion, the possible values for p_ImportedGoods should be (1, 2, 3) x (C).

The reason:

Since the inheritance is transitive, p_ImportedGoods will inherit the all arc from p_GrossProfit and the notAll arc from p_CostOfGoods. Combined with its own all arc, the evaluation result should be (1, 2, 3) x (C).

Besides, you have misused some words in the note of the last row. The phrase “…C product with all members in the department domain.” should be replaced with “…C region with all members in the product domain.”

[IHR] It looks like I changed the products dimension with the regions dimension in the wording. I’m changing the wording for clarity. The result “no combination is possible” is the right result as per rules indicated in section 3. Here is a more detailed explanation.

 

All the primary items are source of hypercubes in the http://www.xbrl.org/role/link arc role. So, in order to create a dimensionally valid instance of a primary item all the hypercubes linked with the “all” operator MUST be valid and all hypercubes linked with the “notAll” operator MUST be invalid.

The combination (1) x (C) raises the following validation sequence:

          - Cube 1 is valid. Operator is “all” so the result is “Valid”

          - Cube 2 is invalid. Operator is “notAll” so the result is “Valid”

          - Cube 3 is invalid. Operator is “All” so the result is “Invalid”

Not all cubes are valid so the primary item p_ImportedGoods is dimensionally invalid.

The are no any possible combination that satisfy all hypercubes.

 

6. In Section 3, the immediate NON NORMATIVE NOTE says “…A dimension is valid if in the context there is a member of its domain.”

My comment:

Maybe you should say “…A dimension is valid if in the context there is a member of its domain, or it has a default member.”

[IHR] I’ve incorporated “or if the dimension contains a default member” instead. Thanks.

 

7. In Section 3.1.4, the second paragraph says “The dimension container is the content of the element xbrldi:typedMember…..”

My comment:

I think you should say “The dimension value is the content of the element xbrldi:typedMember…”

Besides, in the last part of the same paragraph, it says “…or the QName of the default member of the dimension….”   I think this is a mistake. Because the software will automatically detect the default value, you can’t have the QName of the default member appearing in the instance.

[IHR] The new section 3.1.4 says:

1.1.1     Validity of dimensions

[Def, 13] The dimension value is defined as the content of the dimension container [Def, 14] for one specific dimension in one of the two possible context containers: segment or scenario. Default values are also possible dimension values but are not enclosed in dimension containers [Def, 14]

[Def, 14] The dimension container is the element xbrldi:typedMember for typed dimensions or the element xbrldi:explicitMember for explicit dimensions.

A dimension value must be valid according to its domain [Def, 6]. Validation of typed dimensions and explicit dimensions is defined in sections 3.1.4.4 below and 3.1.4.5 below respectively.

I’ve also added a few more definitions to clarify this part of the document.

 

8. In Example 19, the r:Barbados in the attaching note should be replaced with m:Barbados.

[IHR] Another good catch. :) Thanks.

 

9. In Section 3.1.4.4.1, the “xbrldi:TypedElement” in the second paragraph should be replaced with “xbrldi:typedMember”.

 

[IHR]

[IHR] This was changed a few weeks ago. Thank you for your time doing the review.

 

 

Kuo-hua Chou

Accounting Ph. D. candidate, National Cheng-chi University, Taiwan.

Lecturer, National Pingtung Institute of Commerce, Taiwan.

Email: ckhmike@ms4.hinet.net

Website: http://www.ais.npic.edu.tw/xbrl/