I have been trying to articulate the benefits of unique, explicit [Table]s in the US GAAP Taxonomy for quite sometime. In trying to figure something else out I stumbled across a paperwhich helps communicate why unique, explicitly [Table]s are superior to [Table]s which are not unique and [Table]s which are implicit.
First off, let me explain what I mean by unique [Table]s and by explicit [Table]s.
A good example of a non-unique [Table] is the "Statement [Table]" which appears in the US GAAP taxonomy. What does the "Statement [Table]" represent? Well, it represents many things and that is the underlying problem. It could represent a balance sheet, an income statement, a cash flow statement or actually anything because some vendors are using "Statement [Table]" to express every [Table]. So, what I mean by unique [Table]s is exactly the opposite and exactly as it sounds. Just like concepts or other things in the US GAAP Taxonomy each [Table] has ONE meaning, one name. Rather than using "Statement [Table]" to identify multiple things, each [Table] is specific: Balance Sheet [Table], Income Statement [Table], Cash Flow Statement [Table], and so forth.
By explicit [Table]s I mean that there are no implicit [Table]s. What I mean by that is that today, everything exists in a "[Table]" in the US GAAP taxonomy. And of course you will say, "No, that is clearly not correct, one can cleary see that is not the case." But, this is exactly my point. True, you can't "see" the [Table], but it is there. What I mean is that after you address all the explicit tables identified by the XBRL hypercubes marked with a "... [Table]" in the label and name, you have one more table which implicitly exits. Basically, it is the "everything else [Table]" which has no name. It has two [Axis], the "Reporting Entity [Axis]" which is instantiated using the XBRL syntax "entity identifier" portion of a context and the "Period [Axis]" which is articulated using the XBRL syntax "period" portion of a context.
Don't make the mistake of confusing syntax and semantics. Just because it is called part of the XBRL context does not mean that from a business perspective that it is not an [Axis]. First off, be aware that ALL [Axis], be they XBRL Dimensions defined or XBRL 2.1 defined, are expressed using part of an XBRL context element.
So, what I am saying here is rather than modeling things to show up under the "unnamed [Table]" implicitly, it is better to be explicit and define the [Table]. Further, having multiple "unamed [Table]"s violates the first notion of making every [Table] unique.
"Why?", you ask. Here is why. Navigation and use of the taxonomy and the SEC XBRL filings is superior if [Table]s are unique and explicitly defined because navigation within the pieces of the taxonomy and/or SEC XBRL filings because of the unique "handles" of the [Table]s.
If [Table]s are unique, you dont also have to use the network to uniquely identify WHICH of the non-unique [Table]s you mean should you be trying to tell a computer software application which of the non-unique [Table]s you desire to use. Further, there is no need to ask what defines the [Table], the hypercube which defines the table with the "... [Table]" label/name on the end or the set of [Line Items] which make up the [Table]. You will not have that question because every [Table] is unique and you will never run across that situation.
Computers need these unique handles to understand exactly what you desire. Unique, explicit [Table]s provide the handles needed to control navigation between pieces of a taxonomy or SEC XBRL financial filing. Without unique [Table]s, there is no way you can get around using network information to create unique handles.
If you need more details please read the paper. It is quite technical, but it lays all of this out quite nicely.