There is this feature of XBRL which I refer to as "hypercube jumping". You can experience hypercube jumping, at least an initial instantiation of it, by using a software application which supports this feature such as the Firefox XBRL viewer add on, a properly created XBRL instance, and a properly modeled XBRL taxonomy. If you want to actually walk through this, this blog post will help you do that.
What I am starting to recognize that the term hypercube jumping is likely not the right term. Hypercubes are only a piece of the puzzle and in fact, you really don't even need explicit hypercubes at all but this works with the implied structures within XBRL as long as you model your meta data correctly.
Are you lost already? Well, I probably won't help you grasp all this; the fact is I am trying to figure it all out myself. A lot of people refer to the things I am talking about as "drill down" or "aggregation" of information. But it seem to me that it goes way, way beyond that.
To help you visualize, consider the graphic below. This is a tesseract. Look at this graphic and think about Excel pivot tables.
Paper has only two dimensions, rows and columns. Add a third dimension to that and you get a cube. You can only view a three dimensional cube on a two dimensional surface by holding one of the dimensions static like what a slicer does in say an Excel pivot table or by repeating sets of rows and columns multiple times within a paper report. Now a computer screen is not limited to two dimensions so it can display three dimensions with no problem.
What does all this have to do with hypercube jumping or drilling down into data? Well, I am not totally sure but what I seem to see is this. If you look at the graphic above, you will note that the object fits together, you don't have stray lines ending nowhere in space and things like that. What I am seeing more and more is that it is all about the data model. If you get the data model correct, you can do all sorts of interesting things.
Imagine having a financial report which "looks" like the graphic above. (Work with me here and use your imagination.) Imagine being able to pivot, slice, dice, drill down, drill across, drill side-to-side from one place in a financial report to another place in a report. Imagine that your "report" is actually a set of financial reports for an entire industry sector and you can cross the bounds of the report or the entity because you are not limited by the physical bounds of paper or the limit of two dimensions which limits what paper can express.
Syntax is really not that important, as long as you can easily convert and move form one syntax to another. There have been never ending debates about things like the pros and cons of things like tuples and dimensions. During those debates a minority of people say that those things don't matter. I am starting to grasp what they were talking about.
Any accountant or financial analyst can tell you that there is a rich set of relations contained within and between the many pieces which make up a financial report. Leveraging these relations will change the way we interact with this information. The first step is articulating the many relations in a way that a computer can easily and properly grasp. XBRL is one syntax for doing this. Proper data models is what enables things like hypercube jumping.
All this will be easier to grasp when more software exists to see these ideas in action.