I learned something interesting that had never really occurred to be before as a result of fiddling around with trying to render XBRL.
This has to do with constraining fact values and is explained in more detail here in this document. An understanding of this helps you create better XBRL taxonomies because you are conscious of something which you may otherwise not realize.
In summary, XBRL has two mechanisms for filtering fact values you are working with and these mechanisms work differently:
This is not to say that one mechanism is better than another, but rather to point out that the mechanisms are different.
You seem to get less ambiguity, more precision and generally better control using XBRL Dimensions hypercubes as is explained in that document. This is because you explicitly articulate the dimensions and the possible dimension values which are allowed for a hypercube when you define the hypercube.
By contrast, an XBRL network (i.e. an extended link of a particular role) only constrains the primary item (to use an XBRL Dimensions term) or the concept which can appear within a network.
Neither of these mechanisms can constrain the entity identifier or period which you can use within an XBRL instance. This has some pros and it has some cons which you need to be aware of.
I could be wrong here, but the way I look at it is that if you use XBRL Dimensions, you always have two "typed members" (as XBRL Dimensions calls, sometimes referred to as implicit dimensions): entity identifier and period. I say this because neither the entity identifier nor the period have a domain like explicit dimensions, nor do they have a hierarchy and they can be "open lists" of possible values for those dimensions. Like I said, I could be wrong about this but they do seem to have many similarities to XBRL Dimensions typed members.