Shipping containers have been used as an example of the benefits of standards, helping people to understand why the XBRL standard is a good thing. There is another analogy relating to shipping containers which can be brought to bear in explaining why application profiles are a very good thing.
Let's look at the shipping container from a different perspective. First of all, there really is not just one standard shipping container. There are, in fact, a number of different size and shapes of standard shipping containers. I live in Tacoma, Washington and I see the container ships go into and out of the port which was home to Sealand, an early user of shipping containers. I figure that perhaps there are between 20 and maybe 50 different sizes and shapes of shipping containers). The exact number is hard to determine, but the primary thing to realize is that it is not one standard size; and that it is also the case that each different shipping container is not a unique size and shape (i.e. there are not infinite sizes and shapes).
Now, take a look at XBRL. Today, the way XBRL taxonomies are being created, each XBRL taxonomy is created using a somewhat different architecture. IFRS, US GAAP, EDINET, COREP, FINREP, FDIC, The Netherlands Taxonomy project, the Australian SBR project, (I could go on) all have different architectures! This would be like every shipping container being constructed to be constructed of a different size and shape. How could that possible be a good thing??? In fact, now the IFRS, US GAAP, and EDINET are trying to undo or converge their different architectures.
Why are the architectures for each of these XBRL taxonomies different? XBRL is a general purpose specification. XBRL can be used for lots of different things, XBRL was built to be flexible, to be a general purpose tool. People have referred to XBRL as a "Swiss Army knife". As such, no one would ever use every feature of XBRL within one system. You pick and choose your approach, you pick different pieces of XBRL, don't use other pieces, and you create an what amounts to an architecture approach to creating your XBRL taxonomy.
Each different XBRL taxonomy implementation picks different pieces, parts, and approaches of XBRL to use in expressing their XBRL taxonomy. All of the different approaches (US GAAP, IFRS, COREP, and so forth…) are 100 percent XBRL compliant, but each is different. This causes two things. First, interoperability between each XBRL taxonomy is harder to achieve. This is not to say that each XBRL taxonomy really needs to be interoperable, they don't; but if you do need to make them interoperate, just being XBRL is not enough to achieve the interoperability. For example, now the FDIC and SEC have two different XBRL taxonomies which financial institutions which have to report to both must use.
The second thing which occurs is that each implementer of XBRL has to figure out pretty much the same things for their specific implementation, repeating the same effort over, and over, and over. Or another way of saying this, why would it be a bad thing to simply copy someone else's XBRL taxonomy if the architecture is both good and meets your needs?
Application profiles are a common approach to of solving this sort of problem and it has a side benefit to boot: it makes XBRL easier to use. XBRL is complex to use because you cannot make the general specification simple. You can make parts, or subsets, simpler to use. Remember that XML is basically an application profile of SGML (Standard General Markup Language). It is vastly easier to build an XML parser than it is to build a fully compliant SGML parser. XML is taking off, SGML has a niche but never received broad adoption.
I believe that a number of application profiles will be created and that will be the implementation patterns for XBRL. No one will use just general XBRL. Everyone will use a subset of the more general XBRL specification. Each XBRL taxonomy today uses different pieces and parts within their XBRL taxonomy architecture. In effect, each XBRL taxonomy is, today, its own unique application profile.
There are already groups working together to create application profiles for XBRL implementations. XBRL Global Ledger is basically an application profile. The US GAAP Taxonomy is an application profile (see the architecture document, page 4, section 1.4); it even calls itself such within its architecture documentation. XBRLS is an application profile. There are a number of governments around the world starting to talk about Standardized Business Reporting (SBR) as an application profile or approach for governments to implement XBRL in a consistent manner.
However, most of these application profiles are not documented formally enough to be as useful as they can. None of them work "out of the box". There are no software applications leveraging the application profiles to make a business user's life in making use of XBRL easier. But I believe that soon, there will be. Once business users realize the practical nature of using application profiles to make their life easier they will gladly give up a small amount of flexibility in order to gain significant reductions in implementation complexity, implementation cost, and ease of use.