Precise terminology can be important. Using terms incorrectly inhibits communication.
The XBRL technical syntax includes not only XBRL terms defined by the XBRL Specification; but also terminology defined by XBRL Dimensions and XBRL Formula. Not only that, but because XBRL builds upon other technical specifications such as XML, XML Schema, XLink; you have that that technical terminology to contend with. How do you keep this all straight?
Well, most of this terminology will be hidden from users by software applications. Eventually.
I have put together a reconciliation of this terminology. This reconciliation maps XBRL and other technical terminology on the far right to financial reporting terminology on the far left. In between I have provided an example, Business Reporting Logical Model (BRLM) terminology which I have used in the past, and US GAAP/SEC financial filing terminology.
If implemented correctly, generating XBRL output from a software application does not have to be complicated by terminology which business users do not need to understand.
If you hear people using terms such as "tag" or "element" or "dimensionally qualified", they are making things harder than they really need to be.
A commonly misused term is "concept". Concept is a good term, if used in the right way. The terms "tag" and "element" could mean any of the building blocks used in an SEC XBRL financial filing: network, table, axis, member, line items, or concept.
The XBRL specification (section 1.4, terminology) does define the term "concept". A concept, per that definition is:
Concepts are defined in two equivalent ways. In a syntactic sense, a concept is an XML Schema element definition, defining the element to be in the item element substitution group or in the tuple element substitution group. At a semantic level, a concept is a definition of a kind of fact that can be reported about the activities or nature of a business activity.
Pretty hairy. But this gets even better. Tuples are not relevant because the US GAAP Taxonomy does not allow them, so basically, per this definition an XBRL concept is an XML Schema element which has a substitutionGroup attribute value of "xbrli:item". But there is a problem here.
The XBRL Dimensions specification (section 1.3, terminology) defines the terms hypercube (called a [Table] in the US GAAP Taxonomy) and dimension (called an [Axis] in the US GAAP Taxonomy). A hypercube is defined as an XBRL concept which has the substitutionGroup xbrldt:hypercubeItem and a dimension is defined as an XBRL concept which has the substitutionGroup xbrldt:dimensionItem. So, hypercubes and dimensions (or [Table]s and [Axis] using US GAAP Taxonomy/SEC terminology) are XBRL concepts; per the definition above they are "...kind of fact that can be reported...". Right?
No. XBRL Dimensions redefines the XBRL concept to mean Primary Item. So in essence, with XBRL Dimensions you get the major primitive building blocks of:
So, when most people use the term "concept" they are referring to a "kind of fact that can be reported about the activities or nature of a business activity", not a hypercube, dimension, or domain member.
Three primary take aways here:
Personally, I have pushed for that global standard set of terms for quite some time. That logical model will be very useful to both business users and software vendors who are trying to create quality software.
Do you have a better terminology scheme? If you do I would like to hear about it both to improve mine and pass this information on to XBRL International. Let me know.