As many readers know, Walter Hamscher is an XBRL pioneer and one of the smartest people in the field. He recently gave us a wide-ranging interview in which he discussed a host of XBRL topics, including the SEC’s proposed mandate, the pace of XBRL adoption in the US and abroad, assurance issues, and Inline XBRL. The fourth part of the interview, which begins with question (9), appears below. The first, second, and third parts were published over the past few weeks; the final installment will appear next week.
(9) At the recent XBRL International Conference in Eindhoven, you gave a presentation on how Inline XBRL can simplify some of the problems that arise for regulators seeking to encourage preparers to submit full financial statements and other formatted documents. Could you give us some idea of what Inline XBRL is, along with some examples of what it can accomplish?
Most people have been using Internet browsers now for years. They are familiar with the notion that you can be looking at a page, rolling your mouse over parts of it, and it may pop-up things or may change colors -- things can happen in my browser as a consequence of that.
People are also very familiar with the notion that when you send an email and, say, you attach a file to it, they don't know anything about how it actually might work inside, but they know conceptually the notion of attachment and those related functions.
Inline XBRL is really a way of saying: “Here’s an HTML page on a website and it contains financial information you can extract and use immediately.” Inline XBRL is a way of putting the XBRL right into that web page, so that if you have a browser or other application that understands that it is there, you are going to get a new, additional, and better behavior. You will be able to extract the data from it at the consumption end.
From the production end it solves an important process issue that we've had really for quite a while. If I am a preparer today, and I’m in the voluntary filing program, I have to produce my 10-Q or my 10-K, and then I have to do this bolt-on process where I have to take that document, make a new XBRL document, and then manually check each one of the hundreds of individual facts back against the original.
This is terrible; it would make a lot more sense to do it the way you would do it in Word or something like that. That is, initially put the data right on to the original file itself, put it into Word the way you already put bookmarks in the file, or put styles on characters; things you already know how to do well. That way, there's no checking to do; it can't be wrong, because you've actually put the tagging of a fact or number into the file right at the same place.
So in my mind, it solves two adoption hurdles for XBRL in the US. My only regret for Inline XBRL is that we didn't get it done six months earlier.
(10) Could you talk a little bit about the development of Inline XBRL?
Sure. It goes back to a very early conversation we had in 1999 when we were first designing XBRL. We were making the observation that it would be nice if you could take any news story -- because in 1999 it was kind of a new and novel idea that news stories were being posted on the web -- and actually stick XBRL right into the web page. That was an initial thought about how XBRL could work. Then we went off for six years and did other things.
Now in the course of building more XBRL taxonomies for other agencies around the world -- and in particular for the mutual fund industry’s Investment Company Institute -- it became clear to me that there was a comfort level that people will need with the XBRL document. They needed to be able to see it on their computer screen, and the appearance needed to be familiar -- it needed to be what they intended to put in there. And they were okay with the idea that “OK, I am going to put some tags in here.” But the idea that the tags were all scrambled up in a random order and that they then have to be re-assembled causes a lot of understandable discomfort in the minds of people who were working with it.
So what I did was to say, when we do the US GAAP taxonomy, we should take out from the taxonomy all the stuff that's oriented toward that presentation problem and put it over into a separate module, which at the time we called Mixed XBRL. This was kind of an early prototype that actually used XBRL itself in a strange way but the basic idea of using HTML syntax was central.
But then, the folks from DecisionSoft and CoreFiling, who are just tremendous XML experts in our community and have done tremendous work for us, refined that notion and said, “We can actually take this one step further, and make it even better by saying let's not try and reinvent presentation at all, let's just embed the XBRL directly into HTML.” They put a huge amount of voluntary work into the specification and into making that work; that specification is actually now in its last call for public comments and will soon in fact become a recommendation.
So what I would say is that if I had been working with DecisionSoft directly from the outset around this time last year we probably could have gotten to the whole thing faster. I still think Inline XBRL has a key role to play.
(11) You are one of the true pioneers of XBRL and have played a major role in its development almost since its inception. As you look back over the past several years, has the pace of XBRL reception been about what you had expected? Have there been any major surprises for you in the nature and pace of XBRL adoption, either positively or negatively?
It sounds strange to say but I actually think we're about where I expected to be and that is just because as a software engineer I understand that you make project plans… and then “stuff happens.” The stuff that happens hardly ever makes things go faster.
Mark Schnitzer, he is now with Microsoft, told us in 1999 that it was going to be about ten years before XBRL was mandatory for all filers in the US. That was a heluva good prediction. In some sense, I think that that's about the right pace.
I guess the thing that really has surprised me -- and once again I will admit it as a younger person in 1999 I really didn't understand it – was a political point, and that is, how differently other countries view their government. I didn't realize that there were other countries where people trusted their own government a lot more than we do. I think the Dutch, the Japanese, the French, the Spanish, I think they trust their government more than Americans, and so consequently they can move faster. I think in other countries it's going to go more slowly.
The other thing I was very surprised at was that the investor relations community, the people who are responsible for selling their company's story, have not been a lot more active. I am mystified by it and I think it just has to do with the fact that the software is still not quite there to make it easy for them.
I don't think they're the kind of people who are comfortable kind of hacking the code and looking at the angle brackets. But it is surprising to me that you don't find companies that specialize in building investor relations websites doing much more with XBRL. It surprises me, because I think there's a big value proposition for companies in participating in XBRL development and being on the leading edge.
I don't think there are many people who get into IR from the software side. They’re professional writers, financial people.
Agreed. You look at what that culture is, and it is about language and communication, it's not about the data. But if you look at Microsoft's Investor Central, I think that’s a great example of what can be done. My point is that I expected it to be done around 2003 not 2007. It's not a disappointment, I just didn't understand that part of the world at all. I do think that the investor relations groups need to go look at sites like Investor Central and think about what they could be doing with fundamental data and linking it to supporting detail, or portions of the analyst briefings, or other material that would be so much more effective.
Leave a comment