0

While going through the definition link base of a taxonomy, i found that a few domain members were present in two separate dimensions. Eg. Dim A contains domain Dom1 with members m1, m2,m3,m4. And Dim B contains domain dom2 with members m2,m3,m4. The issue is that it may lead to conflicting context names (even though the segment part of the contexts will be different).

The format of the context name is 'periodInformation_domainMember'. I need to use different dimensions for different sections of my report. So my basic question is how do i form context names?

I hope i have conveyed myself properly. Appreciate any help... :)

schan
  • 51
  • 6

2 Answers2

0

use "Period Information + Dimension + member name" for making context names unique.....

You have to check the uniqueness based on the child nodes of <period> tag and child nodes of the <segment> tag... here in segment; if segment is present then each xbrldi:explicitMember has dimension in its attribute and member in its value...

...more: http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-04-25.htm#_4.7

namit
  • 6,780
  • 4
  • 35
  • 41
  • thank you for your reply. I went through the xbrl specification. Is the practice of using "Period Information + Dimension + member name " a best practice; or is it recommended anywhere that context names should be formed by using this combination? Or can I continue to use "period information+domain member name",i.e. is it purely the programmer's decision? In an example, I came across a context(named as period+domain member) where a random number was appended to the context name just to make the name unique! It doesn't seem like a good thing to do... – schan Nov 27 '14 at 04:18
  • consider what is required by the specification... they only ask.. that.. whatever information(group of information) in the context ....should be unique... in that xbrl instance document... so using context information(period..dimension...member/members.....in some meaningful order...so that it can be comparable with other ids..) as context id..is sufficient to resolve our requirement... – namit Nov 27 '14 at 05:40
0

What if there were multiple dimensions? Playing devil's advocate, what if you have dimensions with the same local name but in different namespaces? The only way to guarantee a unique name is to use the whole content of the context - which is ridiculous.

I've seen recommendations by regulators requiring filings in XBRL that 'Semantics SHOULD NOT be expressed...' in a context id and it is '..recommended to keep it as short as possible...'

The simplest solution is to pick unique names that that have nothing to do with the contents - for example c-1, c-2 etc.

The syntax of the XBRL is unimportant, it's just an implementation detail.

Charles Mager
  • 25,735
  • 2
  • 35
  • 45
  • using short and unique names is recommended(see RRD's filings; though their length is not that much short; but yes.. they are not expressing context content in its ids); but...but... its wrong that they have nothing to do with the contents... two different contexts with same content will create validation error... anyway.. i can see this pattern(using "whole(some part) content of context" as context id) in most of the top vendors's (webfilings, ez-xbrl, Merrill, Rivet, CompSci, GoFiler, DataTracks...)latest filing; and i don't think they have any issue/conflict with that!!! – namit Dec 02 '14 at 06:22