In This Chapter
Grasping the big picture of what makes up XBRL
Realizing that standards all boils down to agreement
Taking a look at new age business information exchange
Discovering the fundamentals of XBRL taxonomies and XBRL instances
You may have heard the phrase, "Spare me the details; just give me the 50,000 foot perspective." That's what this chapter is all about: XBRL's big picture. We also introduce you to XBRL's sometimes-baffling terminology.
In this chapter, we give you a grounding in the new age of business information exchange that XBRL is ushering in. We emphasize the key ingredient that makes XBRL work, which is probably a lot simpler than you think: agreement.
Say that you were riding on an elevator, and someone said, "Hey, I just found out I have to do my reporting in some funny-named format called XBRL to such-and-such regulatory agency. But I don't even know what the heck it is. Do you know anything about XBRL?" You have about two minutes to answer before the doors ding, and you have to exit the elevator. Here's about as simple an explanation of XBRL that you can give:
"XBRL is an acronym for the Extensible Business Reporting Language. XBRL is a freely available, market-driven, open, global standard markup language, backed by a formal technical specification. You can use XBRL to define and model the meaning of business information so that computer applications can effectively exchange that information without any human intervention. Humans can still get everything they have today, and they still maintain control of these exchange processes. One of the primary benefits XBRL gives business users is the ability to cheaply and efficiently automate all sorts of business-information-exchange processes. Another is more flexibility for consumers of business information. Think of XBRL as enabling the creation of a pipeline to distribute oil or gasoline, rather than using individual tanker trucks."
Suppose that you later saw that person again at the water cooler, and he now wants more information. The following list provides you with ammunition for that discussion:
Freely available, market-driven, open, global standard: XBRL is global, so it isn't the property of any one nation. Open means that it's freely licensed. You don't pay royalties or have to contend with restrictions to use the XBRL standard — standard in that it's not proprietary to any single software vendor, but rather a standard supported by many software vendors. Market-driven means that the business community is the group getting together to create the standard.
Note
Standards are basically a set of commonly agreed-upon technical rules and guidelines that those implementing XBRL have agreed to follow. Standards lead to interoperability between different software applications and business systems, as opposed to non-interoperable, proprietary solutions.
Markup language: By markup language, we mean a way to express information by using tags — in XBRL's case, the XML syntax. Basically, a markup language determines the structure of the tags in a file that contains business information.
Specification: The XBRL syntax (the technical rules) is articulated within a technical specification called the XBRL specification. The XBRL specification defines the XBRL markup language's syntax and describes what is and isn't acceptable. XBRL uses the XML syntax and therefore follows the rules specified by the W3C's XML specification. A specification is a set of documents plus additional infrastructure, such as a conformance suite, which allows software vendors to test their software. XBRL is really a set of specifications.
Information: Information is data plus context. (Chapter 2 goes into the distinction between data and information.) The biggest thing to understand is that XBRL is about information, not just data.
Meaning: When we say meaning, we're talking about expressing an idea. In computer science, semantics refers to encoding meaning of information so that humans, as well as computers, can understand the significance of the information. Some examples of semantics are the definition of a concept, such as Cash, and rules, such as Cash is a current asset and adds up to Total Current Assets, or that you must disclose the components of cash if Cash is presented.
Computer application: Basically, this term means software applications or business systems. Humans can do more than computers because humans are quite smart. Computers are dumb, really dumb. You have to give a computer explicit instructions to get it to do the right thing. The fact that computers are so dumb and need such explicit instructions is where the capability of defining clear rules becomes important.
Exchanged: What exchanged means is that information in one place is moved (transported) to another place effectively. For example, exchange can take place from one organization to another, or from one business system to another business system.
Humans: We humans still need to work with all this information. Information that is usable for humans isn't necessarily usable by computers. If a computer can use something, you can typically use that information for human presentation as well. If a human needs to get involved in an exchange process, it will take more time to execute, process costs will increase, and the potential for error increases.
Tip
If your boss asked you to do a presentation on why your organization might choose to use XBRL internally and you could use only one graphic, Figure 3-1 would be it. Think of each box in Figure 3-1 as a volume of resources expended. An effective exchange of business information requires a number of components, including
Analysis, interpretation, and decision-making
Distributing and transmitting reports
Verifying, reconciling, and correcting information
Rekeying and report generation
Discovery and gathering information
Note
What XBRL does is to decrease the time and money spent on nonvalue-added processes so that you can devote more attention and effort to work on the value-adding activities.
These XBRL parts make up the whole — the organization, the specification, the taxonomies, best practices, and the software that makes everything work. You can divide the world of XBRL into the following main areas:
Standards bearer: The standards bearer is the organization — in this case, XBRL International — that stands behind the XBRL standard. The standards bearer is a group of members that meets to collectively solve problems so that each member doesn't individually create his own solution to the same problem. In XBRL's case, the problem is the exchange of business information.
Specifications: One thing that XBRL International created was a specification, or really a family of specifications. XBRL is, among other things, a specification for how to articulate business information so that computer applications can exchange that information. (See the upcoming section "The XBRL family of specifications.")
Taxonomies: One of the things you can do with the XBRL specification is to create taxonomies that allow information to be exchanged in a way computers can understand. Taxonomies aren't exactly the same as dictionaries, but they're close enough for our purposes here. (Chapter 17 explains the differences.) XBRL is an open standard, so anyone can create XBRL taxonomies, but some XBRL taxonomies are so important that XBRL International members helped enable their creation. One example of a taxonomy created by XBRL International is the dictionary of terms that a company needs to report its financial information per International Financial Reporting Standards (IFRS). Another example is the taxonomy for financial reporting under US GAAP. Others now maintain these early XBRL taxonomies, but XBRL International started the process. (See the upcoming section "Key common taxonomies.")
Best practices: If you wanted to, you could just pick up XBRL, read the specification, and then exchange information to your heart's content. However, if you do, you'd learn some things the hard way by making mistakes — things that others have probably already learned about using XBRL in the real world — and that doesn't make sense. Best practices provide valuable guidelines gleaned from real-world experiences by using XBRL in real-world situations. These best practices also provide necessary discipline to the process of using XBRL. Best practices come both from XBRL International and production systems built by others who share information about their experiences. (See the section "Gleaning Guidance from Best Practices," later in this chapter.)
Software: XBRL truly comes to life when software makes everything work like a well-oiled machine. The complexities of the technical specifications and knowledge of best practices are built deep into software that is enabled to create or otherwise use XBRL. (See the upcoming section "Bringing XBRL to Life with Software.")
XBRL may be something that you have to use because some evil regulator sent you a letter nicely asking you to submit your information, using XBRL, but you may actually want to use XBRL. Why? Because it provides you with something useful and/or it saves you money.
Note
Agreement is an important element that acts as the invisible glue to make XBRL really work. Agreement among the people trying to exchange information by using XBRL isn't magic, but it certainly makes moving the technology forward easier. Other invisible dynamics that have a significant and often hard-to-see impact on XBRL include interoperability (agreeing to make software work together) and formalization (agreeing to slightly more formal processes to make the automation process possible in order to reduce costs for everyone).
Agreement does all sorts of powerful things. Many times, agreeing on complex issues is hard or even impossible. Although there are formal agreements, agreements don't necessarily need to be formal. For example, you probably know what LOL and :-) mean. We wish we could point you to the technical specification that indicates that if you want to tell someone that you're "laughing out loud" when you text them, that the global international standard is LOL, but we can't. Agreement solves all sorts of problems, and sometimes, it certainly causes some new problems. So what is the point? If people find XBRL useful, they'll use it. If they don't, they won't.
Tim Bray, one of the editors of the original XML specification, said it nicely:
"Any nontrivial language needs an automated validator if you're going to get software to interoperate."
One software vendor can easily create software products that interoperate with its own products. Getting two different software vendors to create products that interoperate is more challenging. Imagine the challenges of getting every software vendor to have interoperable software. You can do it, however. It's been done for other things; it can be done for XBRL.
Validation — making sure that everything works correctly — is key to achieving interoperability. The more that software can validate the information integrity and other such interoperability issues, the less humans have to toil to achieve effective information exchange. For example, if a computer can help ensure that things that should add up do actually add up, then automation is possible. However, if information doesn't tick and tie, automation is impossible because the information isn't reliable. Getting things to interoperate isn't magic, just a lot of hard work. Specifications, although a start, aren't enough because people create specifications, and people make mistakes.
When we say validation, we don't mean a human pops in on every process to ensure that the process is working effectively. We want humans to appear for some cases. But the benefits of XBRL are realized when we can remove humans from the equation where appropriate, and let computers do the job better and for less cost.
A typical goal of implementing XBRL within some business process is to facilitate reliable, automated business information exchange in a defined, consistent, and orderly fashion. Face it, computers aren't as smart as you. Unlike humans, computers have no capacity for judgment. Humans, using judgment, can overcome most problems. People do ingeniously figure out how they can make these dumb tools do useful things. The problem with humans, however, is that we make mistakes, we are expensive, and if we get involved, things take more time.
What we want XBRL to do is help automatically and reliably exchange business information. We're consciously using the term business information exchange and not business report because business reports are only a subset of all the different types of business information exchanges. (We won't bring you to tears of boredom with the details of business information exchange here; see Chapter 6 for that.)
An informal ad-hoc information exchange process and a formal, prescribed information exchange are different, however:
Informal (ad-hoc) exchange: Many processes today are informal ad-hoc exchanges of information, typically involving spreadsheets or word-processing documents. In this scenario, organizations with some business purpose for exchanging information rely on their human resources to define, compile, format, disperse, interpret, clarify, correct, understand, and finally agree upon the information exchanged.
Formal (prescribed) exchange: There are many formal processes for exchanging information. If you make a travel reservation, think of all the systems that need to exchange information to coordinate your airline travel, your rental car, your hotel, and all the associated payment information — quite a complex set of tasks to wire together. However, doing so vastly improves the user experience and saves fellow travelers boatloads of money. Well, computers can replace humans for thousands of less complex processes (but, of course, not every process).
An example of an informal exchange is the process of rekeying, which involves correctly putting information from a spreadsheet or other document into another spreadsheet or document. Guess who does this rekeying? That's right: humans. Using XBRL can reduce (but doesn't eliminate) the reliance on the human factor with its accompanying potential for error. The result is an information exchange that doesn't need the same level of interpretation, clarification, and correction that occurs in an informal ad-hoc exchange.
Computers need these formal prescribed processes to successfully meet your information exchange needs. Computers can't operate with informal processes. Just by adding discipline and formality, you can turn an informal process into a formal process, thus allowing computers to do more of the work. Some parts of the exchange may be harder, but if you look at all the aspects of the exchange together, the combined process will be significantly improved and easier. The result is an information exchange that doesn't need the same level of interpretation, clarification, and correction that takes place in an informal ad-hoc exchange. You can automate a reliable exchange process that offers a net benefit to you for expending this effort.
Note
You still have control over deciding which processes should be formal and which ones can remain more informal; XBRL doesn't make that decision. XBRL merely enables process formalization in a standard way should you choose to automate an information exchange process.
The standards bearer, XBRL International, is the champion and custodian of the XBRL standard. To ensure that the standard reflects business needs at a local level, the organization includes groups knows as jurisdictions, which focus on the progress of XBRL in their regions.
These local jurisdictions focus on the progress of XBRL in their regions and also contribute to XBRL International goals and objectives. Members of XBRL International join the consortium through their local jurisdictions, except in areas where no jurisdiction has been established.
Jurisdictions do things like
Promote XBRL in their area
Organize the creation of XBRL taxonomies needed for that jurisdiction
Provide education
Perform a marketing role, such as explaining the benefits of XBRL to governmental and private organizations in the area
Tip
You can find a list of XBRL International jurisdictions on the XBRL International Web site at www.xbrl.org/jurisdictions.aspx.
As well as being a community of practitioners and users, XBRL as a standard is literally a specification, or more correctly a family of specifications called modules. A specification is an explicit set of requirements that must be satisfied by any material or product that is to be of practical use (and thus of value) to the community that uses the standard in its own work. The family of XBRL specifications, well, specifies what the XBRL that business users exchange must look like. These technical specifications ensure that different software created by different people will work the same way in both software applications.
Note
XBRL isn't just one specification: It's one base specification and additional modules, each of which adds specific functionality to XBRL. You start your XBRL work with the base specification and add on modules as you need that functionality. You can simply ignore the specification modules you don't need. The additional specification modules came about because people using XBRL in the real world discovered that the functionality was necessary. And rather than have each user of XBRL create the additional required functionality, the members of the consortium worked together to create modules that all users could use as needed.
Keep in mind that the rock upon which XBRL is built is the XBRL 2.1 specification, and the modules don't work with older versions of XBRL (2.0, 2.0a, or 1.0). Chapter 16 goes into more detail. Here are the modules and a bit about what they do:
XBRL Dimensions Specification: The XBRL Dimensions Specification (XDT) allows XBRL taxonomy authors to define and restrict dimensional information that XBRL instance authors may then use.
XBRL Formula Specifications: This collection of specifications allows XBRL taxonomy creators to express business rules within a taxonomy. These specifications also allow XBRL instance creators and users to validate XBRL instance information against those business rules. XBRL Formula enables users to programmatically generate XBRL instances based on a set of business rules.
XBRL Rendering Specifications: These specifications provide standard mechanisms for rendering information contained within XBRL instances so that a human can use the information.
XBRL Versioning Specifications: These specs communicate changes made to XBRL taxonomies, as well as concepts, resources, and relations contained within an XBRL taxonomy.
Generic Linkbase Specification: The generic linkbase specification allows anyone to create new types of XBRL taxonomy resource or relations networks, which are stored in the form of a linkbase. XBRL International also uses the generic linkbase specification to define new XBRL modules.
Although the XBRL taxonomies created to express certain common vocabularies are really not directly part of XBRL, they're an important indirect part of XBRL, and they certainly show what XBRL is for. XBRL International and its jurisdictions are key players in making available some of these globally used vocabularies. One example is the taxonomy that is used to report under IFRS.
A couple of important things about these XBRL taxonomies help you see what XBRL makes possible. Before XBRL, there really was no standard way to express the semantics of a domain in a form that a computer could understand. No standard language existed, which is one reason XBRL was created. But now, because XBRL exists and because XBRL is a global standard, agreeing on what syntax to use to express these semantics is possible.
Another thing is that creating the XBRL specification itself was relatively easy compared to creating, or even agreeing to create, some of the XBRL taxonomies that express business information for a domain. Two cases in point are the IFRS taxonomy and the U.S. Generally Accepted Accounting Principles taxonomy (US GAAP). The investment in person-hours that it took to create either the IFRS or the US GAAP taxonomies dwarfed the total hours needed to create XBRL itself.
Imagine that you have a good dictionary, you can speak and write the English language, you have a computer and a word processor, and you know how to type. So you can write a good mystery novel, right? Of course not. What you have are only raw materials. You need guidance or a template to turn the raw materials into a good mystery novel.
This same idea applies to XBRL. The XBRL specification explains the legal syntax that dictates how you must use XBRL. But you need more. You need a tried-and-true recipe for achieving a given result. Or, you need to spend a fair amount of time figuring out precisely the right way to write that page-turning mystery novel. This is where best practices come into play.
Note
Best practices can provide you with a template for arriving at a desired result. Best practice guidance generally comes from people who use XBRL, figure out what does and doesn't work, and then share that insight. Using this guidance provides much-needed discipline to the process of using XBRL effectively, rather than just haphazardly coming up with a solution and hoping that it meets your needs.
Although not part of the XBRL specifications, these guidelines help bring the wisdom of experience by outlining known best practices for implementing XBRL. Some examples of these best practices that help with the creation of solid XBRL taxonomies and XBRL instances include
Formal best practices: XBRL International itself created some best practices, such as Financial Reporting Taxonomy Architecture (FRTA) at
www.xbrl.org/technical/guidance/FRTA-RECOMMENDATION-2005-04-25.htmand Financial Reporting Instance Standards (FRIS) atwww.xbrl.org/technical/guidance/FRIS-PWD-2004-11-14.htm. FRTA and FRIS are an accumulation of good information learned over years of building financial reporting XBRL taxonomies and XBRL instances. The main purpose of FRTA and FRIS is to place additional constraints on XBRL taxonomies and XBRL instances used for financial reporting. The constraints are intended to enhance the comparability of financial information captured in XBRL. Many of these constraints are also appropriate for other nonfinancial-reporting-type XBRL taxonomies and XBRL instances.Publically shared project information: Some projects share information. For example, the U.S. Securities and Exchange Commission shared the architecture document for the US GAAP Taxonomies (UGT) with the public at
http://xbrl.us/Documents/SECOFM-USGAAPT-Architecture-20080428.pdf. The SEC invested tens of thousands of dollars creating this architecture, which provides insight into what you need to consider when determining your XBRL architecture. Why reinvent the wheel?Grassroots efforts: Less formal, but just as useful, are grassroots efforts to determine the best ways to use XBRL. A grassroots effort by several individuals with significant XBRL expertise (Charlie was one) analyzed most of the existing high-quality, publicly available XBRL taxonomies and noticed many characteristics, both good and bad, of these XBRL taxonomies and the resulting XBRL instances. The analysis, published in a white paper, created an approach to creating XBRL taxonomies and XBRL instances that maintained all the good characteristics, but minimized the negative ones. The group even created an architecture called XBRL Simple Application Profile, which explains the approach and allows anyone to use it. At the very least, you can learn a lot about XBRL from this information, or you can use that architecture rather than inventing your own recipe. See
http://xbrl.squarespace.com/xbrlsfor a summary of the problem, a specification that solves the problem, business cases and examples that show you how to use the application profile, and other information to help you discover whether this application profile might help you.
Tip
To avoid having to type these long links, go to www.dummies.com/go/xbrl. This takes you to a landing page where you can click the link you need.
XBRL-enabled software solutions shield users from complexities of the XBRL specifications while delivering the rich functionality users need to complete their business tasks. All the complexity of business information exchange doesn't go away, but the software absorbs it, shielding the user from complexity.
Whether you realize it, you experience the same kind of shielding when you use a spreadsheet program, a Web browser, or even a word-processing program. Each program offers you an intuitive and simplified experience while you perform complex tasks. You never need to deal with the underlying technologies: The software does that for you, thanks to smart programmers.
XBRL truly comes to life within software. Actually, XBRL itself doesn't really come to life: It's more that your business information comes to life. As Christopher Cox, ex-chairman of the U.S. SEC, says, with XBRL, you get "interactive data." No longer is your information locked into a single format on a piece of paper, word-processing document, or spreadsheet.
But do a few applications that generate or consume XBRL, basically creating islands of XBRL, really have any value? Not really. To reach its full potential, XBRL must be supported by not only new applications, but also your existing business systems.
Two broad classifications of software can make use of XBRL:
Existing software applications: These are all the existing applications in the world that you may need to input or export XBRL to or from. For example, if you have an ERP system, you want to get information out of that system and into XBRL, so the software vendor likely needs to modify the system.
XBRL-specific software: These applications enable you to work with XBRL, including XBRL validators, XBRL taxonomy-creation tools, and XBRL instance-creation tools.
Note
Having a few software applications that can generate and consume XBRL doesn't get you or anyone else where you want to be. The more software that supports XBRL, the more useful XBRL is to you and others. Going to the software superstore and buying one XBRL software application and then trying to understand how XBRL benefits you will leave you unsatisfied.
In general, the types of features and functionality that XBRL-specific software performs or that are embedded with your business systems generally fall into these broad categories:
XBRL processors: The principle piece of XBRL software is the XBRL processor (or XBRL processing engine, as some people call it). Pretty much every other software tool that uses XBRL likely has an XBRL processor underneath it, serving that software application. XBRL processors do the heavy lifting, such as reading, validating, and, when needed, working with all that XBRL.
Viewing: You need a way to look at information expressed in XBRL, for example, to see whether that information is correct. You also want to look at XBRL taxonomies in order to understand them, even if you never create one. You use viewer-type software applications to view these taxonomies. XBRL instance viewers help you read those documents. Taxonomy viewers, well, they help you have a look at XBRL taxonomies. Keep in mind that if you're looking at an XBRL instance, you'll also likely to want to look at the underlying XBRL taxonomy.
Creation and editing: Although viewing is helpful, you also need to create XBRL instances and XBRL taxonomies, which is where instance- and taxonomy-creation and editing software comes in. Again, if you're creating or editing an XBRL instance, you need, at a minimum, to view the XBRL taxonomy. You also may need to edit the taxonomy if you're allowed to add concepts and relations and so on. Further, you may need additional functionality, such as the ability to create business rules that you want to put into your taxonomy.
Analysis: That "someone else" you give your information to may be analyzing it and will likely want to view that XBRL instance information. To do so, they need to view the XBRL taxonomy upon which the XBRL instance is based. To do comparisons across different periods or across different providers of information, they need combined XBRL instances. What you may not expect is that they may also want to create XBRL taxonomies so that they can change the view that they see of the information they receive, or they may want to add information, such as ratios, additional computed values, and so on, to an XBRL instance and therefore an XBRL taxonomy.
Other software: Some examples of other functionality you may need include the ability to perform different levels and types of validation, storage of all that XBRL within some sort of database, versioning XBRL taxonomies and XBRL instances, cache copies of XBRL taxonomies locally on your computer, and mapping XBRL to other information formats or other formats to XBRL or even one XBRL taxonomy to another. Clever XBRL search applications may even be in the future. And then there are all those utility applications for doing different odds-and-ends and one-off tasks.
Be sure to check out Chapter 14, where we drill into software in more detail.
The XBRL processor or XBRL processing engine is a key piece of software, and you need one to do anything serious with XBRL. If you look at XBRL outside the framework of an XBRL processor, it's tough to see why XBRL has any value. This perspective is the wrong one, and we mention it here because many have made that mistake, and we don't want you to fall into that category.
Note
XBRL was built anticipating that an XBRL processor, not just an XML parser, would be used. An XBRL processor understands the semantics of XBRL, not just the syntax of XML. XML parsers don't understand XBRL semantics. In fact, XML parsers understand only syntax. Although XBRL processors do understand syntax, they're all about the semantics of information, which is why XBRL processors are so valuable in working with XBRL.
XBRL processors do provide services such as validation to be sure that you're following the XBRL specification and best practices, that your XBRL taxonomy information model (basically how the taxonomy is constructed) is properly and consistently constructed, and other boring stuff like that, which helps ensure interoperability between the software applications that use XBRL. Business users take all these services for granted because they're all done behind the scenes, and they don't have to bother with it (nor should they be bothered). What business users care about are whether everything ticks and ties and foots and cross-casts and that the integrity of their information is accurate per their business rules. Accurate business information boils down to ensuring that information integrity is correct and that they're complying with the rules that they're accountable for.
Being sure that the business information is right is why XBRL was created, and XBRL processors, behind the scenes, specialize in helping users achieve that goal. XML parsers aren't even in the ball park of doing what an XBRL processor can do. Can you make it so that your software can do all these things? Sure, you can. But you'd basically end up re-creating an XBRL processor, and why would you do that if you can simply go buy one? Sometimes, though, you have reasons to build your own. Just realize that you have options, and you have to make this decision for yourself.
Middleware software vendors offer several commercial versions of XBRL processors, and numerous groups have created open-source XBRL processors. Chapter 14 discusses software and even tells you where you can get one of these XBRL processors.
The XBRL specification articulates physically what XBRL must look like. But many times, looking at XBRL logically instead of physically makes understanding what you're looking at easier. Take, for example, the logical model of a spreadsheet, which goes something like this:
An electronic spreadsheet is made up of workbooks.
A workbook contains many sheets.
A sheet contains rows and columns.
Rows and columns intersect, and that intersection is called a cell.
Maybe you never think about the logical model of a spreadsheet, and that's good: It means that the logical model is being communicated so well that it disappears into the background.
Keep in mind the following as we discuss XBRL from a logical perspective:
The creator of business information and the information consumer may speak different languages. But creators and consumers agree on one universal thing : They don't like "geeky" looking stuff.
Information is text or numeric. Numeric information can perhaps be associated with one of a number of different currencies.
Information is reported under different scenarios, such as budgeted or actual, audited or unaudited, and consolidated or unconsolidated.
Information is provided in a set, such as the set of information for the end of the year for 2009, or the set of information for Company A versus the set of information for Company B.
Information is aggregated in multiple ways. For example, trade accounts receivable may be aggregated by category, by current/noncurrent portions, or by its net/gross components. These three ways of looking at the details all add up to the exact same total.
Because situations like the preceding ones exist within business reporting, XBRL has to provide the capabilities to express information for such situations. XBRL needs to be able to handle many other types of situations; the preceding examples just provide a taste. When working with XBRL, it helps to fit such situations into a model that you understand.
Although XBRL doesn't have a formal logical model, a high-level model can be effectively implied. (Chapter 4 covers the gory details, and Chapter 1 provides an introduction to XBRL.) Figure 3-2 provides a graphical view of XBRL's logical model, kindly provided by Charlie, freely useable under a creative common license.
In the XBRL specification, XBRL is broken down into two broad components that establish the pinnacle of the logical model:
XBRL taxonomy: An XBRL taxonomy is something similar to a dictionary used by an XBRL instance.
XBRL instance: An XBRL instance is a business report built in a special way and published in a special format.
An XBRL taxonomy expresses meaning, a controlled vocabulary, used by an XBRL instance. This meaning is expressed in three forms:
Concepts: XBRL taxonomies express technical representations of business terms. The XBRL taxonomy can define business terms itself, or it can point to definitions of business terms that exist outside the XBRL taxonomy. For example, NetIncomeOrLoss is the name of a concept that a taxonomy might express.
Relations: XBRL taxonomies express relationships between concepts. For example, an XBRL taxonomy can express the relation between the concepts NetIncomeOrLoss and Sales and Expenses. XBRL provides three types of relations: presentation, calculation, and definition (see Chapter 4). You can also create your own types of relations, if you want.
Resources: XBRL taxonomies add information to a concept. For example, the easier-to-read English label Net Income (Loss) is a resource associated with the concept NetIncomeOrLoss expressed within an XBRL taxonomy. You add a resource to express another label in another language. XBRL provides three types of resources: labels, references, and formulas (see Chapter 4). You can also create your own types of resources, if you want.
These three different mechanisms, within an XBRL taxonomy, for expressing meaning work together and provide what is necessary to express the business meaning needed to effectively communicate and exchange business information.
An XBRL instance provides a means to publish and transport business information. An XBRL instance is a physical document, just like other documents you're familiar with: a word-processing document, a spreadsheet, or maybe a PDF file. XBRL instances contain the following:
Reference to XBRL taxonomies: XBRL instances always reference one or more XBRL taxonomies that establish the concepts, relations, and resources used by the XBRL instance.
Contextual information: XBRL instances express contextual information needed to properly understand a fact value. For example, the period a fact value relates to is an example of context. Numeric information has a need for additional context information — for example, units. (Do the numbers refer to grams, dollars, degrees, or some other unit of measure?)
Facts: XBRL instances report facts. A fact is information being reported. A fact is always associated with a concept from an XBRL taxonomy. A fact value is the value for a concept from the XBRL taxonomy within a specific context. Fact values can be text or numeric. For example, the value 1000 may be for the concept NetIncomeOrLoss and the period 2009 and expressed in EUROS.
Footnotes: XBRL instances can also contain miscellaneous comments. In XBRL, comments are known as footnotes (not to be confused with what an accountant calls a footnote in a financial report).
Note
An XBRL instance is always associated with one or more XBRL taxonomies. The XBRL taxonomies aren't physically within the XBRL instance, but are generally available via the Web or a private intranet or extranet. They always need to be available because the XBRL taxonomies are critical to understanding the fact values within an XBRL instance.
Relations and resources exist within networks. A network provides you with options, more than one way of expressing a relation or resource. If you have, say, two ways to express a relation, there will be two relation networks. Networks simply provide the logical separation between the sets of relations or resources. You can have categories (or roles) of relation or resource networks. This setup simply allows for grouping similar things together.
Looking at networks from the opposite perspective and providing an example can help you understand what a network does: Imagine that you had two ways to express the components of concept Trade Receivables, Net:
Trade Receivables, Net = Trade Receivables, Gross less Allowances for Doubtful Accounts
Trade Receivables, Net = Trade Receivables, Net, Current plus Trade Receivables, Net, Noncurrent
How would you separate these two relations within an XBRL taxonomy? That is what a network does, creating physically and logically separate sets of relations or resources so that you can express more than one set of relations in a way a computer can understand. Otherwise, a computer can't keep the relations or resources straight.
XBRL taxonomies associated with an XBRL instance should be looked at as a discoverable taxonomy set (DTS). The set of XBRL taxonomies can include only one XBRL taxonomy, or it can include multiple XBRL taxonomies that work together to provide the meaning needed by the XBRL instance.
Creators of an XBRL instance can, but aren't required to, change the DTS. The process of adding your own XBRL taxonomy to modify another XBRL taxonomy is known as extension. Extensions can add new concepts, resources, or relations. They can also indicate that specific resources or relations aren't to be used by adding new pieces to the DTS. Basically, XBRL taxonomies are flexible.