Inline XBRL is not a panacea or other "magic bullet" which will make all problems related to XBRL go away. Some people seem to believe that it is some universal solution for all that ails XBRL implementations.
This is the way I see the moving pieces related to using Inline XBRL. First off, it is really not a question of "Inline XBRL" (some people call it iXBRL) or not. There seem to be the following factions applying XBRL to financial reporting. You have your:
Are these seen as alternatives which are 100% interoperable? XBRL is a "global standard", why would these not be interoperable? Camp #4 means less than 100% interoperability. So, throwing out option 4, will there ever be one global approach to creating a digital financial report? Well, that really boils down to whether there will be a world with only IFRS or whether there will be a world with both IFRS and US GAAP. So say we are looking for one and only one approach. Which is best? Or, does it matter; are all three approaches interoperable/interchangeable?
So that begs two questions: (a) What does each approach offer? (b) What common issues do all three approaches share?
There is an issue which Inline XBRL, Data Point Model, and the Global Filer manual camps share. I will give you an example of that issue in a moment. But first, let me decouple that issue from another issue which many people confuse as the only issue.
The issue is obtaining a human readable rendering of information communicated by XBRL. Both Inline XBRL and the Data Point Model try and solve this rendering issue. It is my view that both the Data Point Model and Inline XBRL are both trying to solve something that I am not 100% sure is even a problem. But, it could be a problem.
The problem is commonly seen as "viewing the information." I am 100% certain that Inline XBRL solves that problem to the extent that HTML can solve that problem because (a) Inline XBRL uses HTML and (b) HTML does a pretty good job with getting very close to "pixel perfect rendering".
I am pretty sure that the Data Point Model, which uses the lesser understood table Linkbase, gets very close to what HTML can do if not 100% at the same as HTML and therefor does the same thing as Inline XBRL. I can believe that from this "viewing the information" perspective, Inline XBRL and the Data Point Model (with the table linkbase) are equivalent.
So from that perspective, let us just say that the two are equivalent. If they are not, then the specific differences should be quantifiable.
While the Global Filer Manual (of which SEC XBRL financial filings is a subset) are rather poorly rendered by the SEC Interactive Data Viewer and most other software in many cases (and therefore does not seem like an adequate solution); there are generally two reasons for most or at least many rendering problems: (1) poorly modeled information and (2) rendering engines which do not leverage known information semantics.
And so what I am saying is that it might be possible for an "adequate" rendering could be achieved by simply improving modelings and leveraging information, patterns, within those models.
If it is the case that a rendering engine understands information semantics, and if it is the case models are constructed correctly and consistently; then it is in the realm of possibility that a rending engine can create an understandable and useful rendering.
Now, that rendering will not be "pixel perfect" or exactly as every person would want to see it because there are so many DIFFERENT ways people might want to see this information. But, would be a usable rendering? I am about 98% sure that such a rendering is possible, but because I have not seen such a rendering for 100% of all use cases I cannot say for certain that I am 100% sure.
So, the REAL questions are: (a) what is the target rendering the market needs, "pixel perfect" or "usable" and (b) is it possible to hit that target leveraging what exists in the XBRL instance and XBRL taxonomy plus know and agreed upon semantics and patterns in those semantics of the information.
And so those two questions (what is the target and can that target be achieved) is different than the real thing which ails XBRL.
This issue will NEVER be solved by Inline XBRL nor by the Data Point Model as far as I can tell. This issue can likewise be broken down into two parts: (a) do domains express enough metadata so that interchangeable models can be created and (b) does XBRL have enough expressive power verification capabilities to verify that good models are being created?
In my view, this is the REAL issue. XBRL cannot capture enough of the semantics which are necessary in a global-standard way to build high-quality, interoperable financial information which can be effectively exchanged. Just to remind you again, neither Inline XBRL nor the Data Point Model address this issue. Also, just packing the XBRL definition linkbase with "stuff" will not solve the problem.
If you look at this visualization of an ontology for a financial report that I am creating you will start to understand what I mean:
http://xbrl.squarespace.com/journal/2013/1/18/financial-report-ontology-draft.html
Like I said, this problem has two moving pieces: First, many times the semantics are not defined by reporting standards and second, XBRL has no agreed upon way to express the semantics.
While pretty much anything can be expressed using the XBRL definition linkbase (such as how XBRL Dimensions uses the XBRL definition linkbase to express and then validate multidimensional information); the important point is "agreed upon way to express the information".
To understand what I am saying all you really need to do is look at the expressive power of something like UML (Unified Modeling Language) which is a modeling tool and how you can have different types of relations (associations, aggregations, etc.) and how UML can express those use cases. Or, if you look at RDF/RDFS/OWL and the expressiveness of those tools and then if you think of how you would express the same information using XBRL, you then begin to realize the limitations of XBRL for expressing needed information.
A specific example of XBRL's limitations is XBRL Dimension's expression of meaning of the relationships between the members of a domain. All you can do is basically express that there is a relation, which is unlike UML or RDF/OWL which lets you express the type of relation.
Another example of this is how one would express the relations between the components of a reporting entity. The 2013 US GAAP Guide, published by Wiley, provides an excellent example of both an inadequate expression of the semantics of the components of a reporting entity by US GAAP (this is NOT a problem of XBRL, it is a problem within the domain of financial reporting) and exactly the type of relations which need to be expressed.
US GAAP defines terms used to describe these sorts of entity components differently in different places within US GAAP. It also uses different names and does not even define some terms which relate to expressing the components of a reporting entity.
This includes such terms as parent holding company, consolidated entity, reporting unit, asset group, disposal group, subsidiary, business segment, geographic area, business unit, legal entity, operating segment. (I am NOT saying that some of these terms are not defined. Some are. What I am saying is that some of these terms are not defined, some are defined ambiguously in GAAP, some are defined in multiple ways but mean exactly the same thing.)
If you try and model information about the relations between the components of a reporting entity then you begin to understand what is necessary from XBRL to make information expressed using XBRL truly interchangeable between business users (i.e. no ambiguity). Further, you gain additional insight if you look at the current set of SEC XBRL financial filings. If you do so you get an even better understanding of the limitations of XBRL and the needs of any reporting scheme or system making use of XBRL appropriately to make the information usable.
Like I said, neither Inline XBRL nor the Data Point Model (with the table linkbase) solves this problem. And therefore, if one moves to Inline XBRL or the Data Point model, one will be disappointed that the move did not get you where you really wanted to be.
Another thing which is related to this is that I now understand the problem which some people had with XBRL Dimensions. Its expressiveness is missing certain key pieces.