In This Chapter
Understanding the key problem XBRL is trying to solve
Gaining knowledge from the essential objectives driving XBRL
Balancing the tradeoffs
Facing the future business-information-exchange environment's realities
This chapter is about why XBRL is what it is, how XBRL actually does what it does, and how you can make XBRL work for you. If you're the type who doesn't really care how your car works and you're just happy that it gets you to your destination, then you can probably skip this chapter. But for the rest of you, this chapter contains a lot of good information that helps you understand the best ways to implement XBRL.
Note
We apologize that his chapter does get a little technical. However, if you're technically inclined or you're a businessperson who works with technical people, you'll find the information useful. We do stay at the big-picture level, however, which makes the technical stuff as painless as possible.
Sharing information between business systems today, even in the age of the Web's connectivity, is difficult. Sir Tim Berners-Lee, the guy who created the World Wide Web, laments,
"Most of the Web's content today is designed for humans to read, not for computer programs to manipulate meaningfully. Computers can adeptly parse Web pages for layout and routine processing — here a header, there a link to another page — but in general, computers have no reliable way to process the semantics."
With the volume of information humans have to deal with increasing at an estimated 30 percent per year, something has got to give. Fortunately, XBRL helps solve that problem. Recall that Sir Tim Berners-Lee said, "Computers have no reliable way to process the semantics." The first part of processing the semantics is to express those semantics, which XBRL does. XBRL steps up to meet the challenges of sharing information so that it's truly portable.
Many technical people have questions about the relationship between XBRL and XML. They look at XBRL from the perspective of other traditional applications for XML and immediately are confused by XBRL, thinking it's overly complex.
Note
This section gets a little technical. It's intended for technical people who understand XML and want to know what XBRL brings to the table. If you don't know what XML is, you may want to skip this section.
Tip
Comparing and contrasting XBRL to other applications that use XML is a good way to understand it. Many people who are familiar with XML make two fundamental mistakes when they run across XBRL:
They think that XBRL is an XML language that's just like other XML languages. That's not the case. XBRL is an XML language, but it goes way further than most XML languages in meeting the needs of its user domain.
They don't spend enough time digging into what XBRL is or why XBRL is what it is. XBRL has a lot to it, and this information can be hard to find and rather voluminous. (Of course, one reason why we're writing this book is to make the information easier to find and more concise!)
XBRL is both an approach to making use of XML and a layer on top of XML that an XML Schema (which describes information structures, much like a data dictionary) alone doesn't provide. XML provides the syntax XBRL uses, so XBRL can use the entire family of W3C (World Wide Web Consortium) XML specifications, which you can see at see www.w3.org.
XBRL uses a specific approach to using XML. For example, XBRL consciously makes it easy for its users to avoid using the XML content model. XBRL also builds upon XML, providing things necessary to effectively automate the process of exchanging business information. For example, think of the times when even the smallest math error can create devastating problems when exchanging information. XBRL had to solve these types of data integrity problems in order to be useful within its environment. Every software application didn't need to solve this problem separately with its own proprietary solution, potentially causing inconsistent results.
The following list compares XBRL and XML. (Thank you to UBmatrix who originally published a white paper on this topic and others who have contributed to this work, making the information available under a creative commons license that provides the basis for this useful comparison.)
XBRL is XML; XBRL uses the XML syntax. XBRL also uses XML Schema, XLink, Namespaces in XML, and other global standards from the XML family of specifications.
XBRL expresses meaning; XML articulates only syntax. XML Schema constrains syntax, but doesn't express semantics. XBRL's fundamental goal is to express business meaning, called semantics. To do so, XBRL had to use the XML syntax to and family of specifications to build additional features. To do what XBRL does with XML, you'd basically have to reinvent what XBRL has already created. Every software vendor reinventing what many business users of XBRL need makes little sense.
XBRL allows content validation against the expressed meaning. Traditional XML languages, validated by XML Schemas alone, don't express enough meaning. If that meaning doesn't exist (or isn't expressed), you can't validate information sets against that meaning. XBRL does express meaning and therefore does enable you to validate by using that expressed meaning. In addition, XBRL enables the exchange of that meaning to those consuming your information because it's expressed in a standard way separate from business applications. With traditional XML approaches, validation isn't as rich, so the necessary rules are embedded within the applications that read or write the XML. These rules are written application by application and in different, proprietary ways that are impossible to exchange across business systems because no one standard approach exists to enable such an exchange. With XBRL, you can exchange both the information itself and the business rules that support creating accurate information, allowing you to effectively communicate business information.
XBRL separates concept definitions from the content model. Typically with XML, the concept definitions and the content model are mixed together. Further, XML provides you with only one implicit set of relations (because it has only one content model) and the definition of those relations is mixed with the definition of elements and attributes. XBRL, on the other hand, uses an atomic approach (flat XML content model) in defining concepts and moves the expression of relations away from the XML schema. This separation of concept and relation definition leads to the next benefit of XBRL.
XBRL can express multiple hierarchies of explicit relations. Because XBRL separates concept and relation definitions, you can define more than one hierarchy of such relations. Further, the hierarchies of relations defined can be explicit, unlike XML's implicit content model.
XBRL provides organized, prescriptive extensibility (the ability for users to make adjustments). XML's greatest strength is also its greatest weakness: XML is extensible everywhere, in every direction. XBRL is extensible in a specific, prescriptive, and therefore predictable manner. As such, the extensibility is usable without modifying software for the extension. You can think of this difference as XBRL always having the same shape.
XBRL provides a multidimensional model. Online analytical processing systems (OLAP)-type systems can use XBRL's multidimensional model to provide flexible information presentation and the ability to "slice and dice" information. Business intelligence systems in particular are big users of the multidimensional model. Although you can make XML fit into a multidimensional model, it can be a struggle in many cases. XBRL fits quite nicely into the existing applications that make use of the multidimensional models. Alternatively, you can use an existing architecture and application profile that's intended to fit into an application that uses the multidimensional model. Getting information into applications that use the multidimensional model is important because more and more applications, such as business intelligence applications, are leveraging the characteristics of the multidimensional model.
XBRL enables intelligent, metadata-driven connections to information. With XBRL, business users can connect information by adjusting metadata rather than by requiring technical people to write code. As such, rather than building multiple point solutions, XBRL enables the creation of effective and efficient solutions that allow extensibility and that don't require programming modifications to connect to new information or new information models. These metadata-driven connections are possible because of the prescriptive manner of XBRL's extensibility; the "shape" of XBRL is always the same. With XML, a programmer has to enable pretty much every new connection when writing code because XML communicates only technical syntax and does so at the data level, not the meaning level, of information and because the shape of different XML implementations can be so varied.
XML replaces a multitude of different approaches to exchanging data with one standard Web-friendly approach. Can traditional XML approaches do all the things that XBRL can do? Absolutely. XBRL is a traditional XML language with an additional layer built on top of it. In order to have the functionality of XBRL, most traditional uses of XML require building all of XBRL's functionality for each XML language created. But XBRL provides all this "out of the box" because things like expressing meaning and validation against that meaning are so core to XBRL's reason for being. XBRL already includes these pieces because business users have said they needed these features.
The XBRL Specification outlines the requirements that drove the development of XBRL. Here's a summary of the drivers behind the development of XBRL:
The business reporting product must improve over the long term.
The needs of all categories of users participating in the process of business reporting (preparers of business information, intermediaries involved in the preparation and distribution process, users of business information, and vendors that supply software and services to those participating in this process) must be balanced.
Business information exchange in general must be facilitated, without a focus on financial information exchange or accounting.
Extensibility is important because business information exchange can be dynamic; it may not be a static form.
The ability to drill down from summary information to detailed information is important.
Preparing, exchanging, extracting, and comparing information is the focus; presenting information is not the focus of XBRL.
Existing technologies and approaches, such as XML, XML Schema, XLink, and Namespaces, should be leveraged rather than new technologies or approaches created.
Although XBRL provides a substantial foundation of functionality to build on, XBRL itself isn't a complete running system any more than XML is a complete solution. XBRL offers a basis for delivering a diverse and rich set of functionality to achieve a system's goals, but it isn't a complete business solution in and of itself. If you had to describe what XBRL provides in a word, that word would be leverage. You can build a broad range of specific systems by using XBRL in a fraction of the time that it would take if you were to start from scratch.
On the other hand, given that XBRL is general in nature, it meets the needs of a broad set of information exchange use cases, which means two things:
XBRL isn't perfect for any specific application of XBRL because XBRL isn't trying to be perfect for any one thing.
XBRL is perhaps more than you need for your specific application of XBRL within your system.
The last point isn't a problem: Just use the pieces you do need and ignore the rest. Keep these important points in the back of your mind:
XBRL isn't a complete solution or system. XBRL is a standard that provides a tremendous amount of leverage, but it is not in and of itself a complete solution or system. XBRL is used within solutions or systems.
XBRL can come in many dialects. XBRL is a general-purpose language. Business systems have many different goals, which you can achieve in many different ways. XBRL users do so in different ways, basically creating what amounts to different dialects of XBRL that don't necessarily all interoperate well with each other unless they're made to do so.
Software tools may not be interoperable. A key to effective information exchange is software interoperability, which XBRL International works hard to enable. However, if two different software vendors support XBRL within their applications, those applications may not necessarily be 100 percent interoperable. For example, if one software tool supports a module of XBRL (such as XBRL Dimensions) that another software tool doesn't support, you may have interoperability problems. Software tool interoperability must be created; it's hard work but achievable.
Business systems may not be interoperable. If two business systems implement XBRL within the systems, you have no guarantee that the two systems will be interoperable, unless they're specifically designed to be 100 percent interoperable. For example, one system may support a module of XBRL (such as XBRL Dimensions) that the other system doesn't support. Or, if one system implements proprietary features (such as the addition of a non-XBRL attribute to a concept, deviating slightly from the standard) and the other one doesn't, the two systems may not interoperate correctly. As with software-tool interoperability, business-system interoperability is achievable, but it does take work.
XBRL taxonomies may not necessarily be interoperable. If two groups create two XBRL taxonomies that use different architectures, those XBRL taxonomies may not be interoperable. Creating different taxonomy architectures isn't a characteristic of XBRL; it's a characteristic of how much (or how little) the two different systems work to make their systems interoperable. Systems sometimes process completely different sets of information, and interoperability isn't necessary. Or, systems can process the same type of information but implement XBRL taxonomy characteristics in different ways, so the systems aren't interoperable. For example, the US GAAP XBRL taxonomy, the IFRS XBRL taxonomy, and the EDINET XBRL taxonomy are all used for financial reporting, but these XBRL taxonomies are significantly different. (You can see a comparison of these three XBRL taxonomies at
www.xbrl.org/TCF-PWD-2009-03-31.html.)Extensibility makes interoperability even harder. If you create an XBRL taxonomy to meet the need of a static reporting problem (for example, an unmodifiable form), interoperability is easier to achieve than if you use XBRL's extensibility. If you're not using extensibility features, you don't have to deal with all the ways users may extend the XBRL taxonomy. If you use XBRL's extensibility, you have to ensure that those extending your XBRL taxonomy do so in consistent ways and in only the ways you intend them to extend the XBRL taxonomy. The XBRL specification doesn't cover how to extend an XBRL taxonomy and not break the information model, so you must build your system to handle these sorts of issues.
Application profiles reduce risk and make interoperability easier. To make implementing an XBRL system easier, you can create an application profile, which articulates an XBRL architecture (meaning it's 100-percent compliant with some specific constrained subset of XBRL), and all the automated validation rules you need to effectively constrain XBRL taxonomies and XBRL instances within a system against that XBRL architecture. You can even use an existing application profile that works correctly.
Warning
A downside of using someone else's application profile is that you must live within its constraints. If you can, implementing XBRL is substantially easier because you have less work to do, and the risk of the system not working as expected is reduced. (Chapter 12 discusses application profiles.)
Extending XBRL with XML extensibility is a possibility. In many areas, XBRL does allow XML-type extensibility, and you can find many good reasons to use it. For example, you can add attributes to an XBRL concept, if you need to. If you're working in a closed system (where you have complete control over all of that system's aspects), XML-type extensibility can be a good strategy. However, this approach can have serious drawbacks. For example, if you add an attribute to an XBRL concept, an XBRL processor may be able to read that attribute, but the application won't know what to do with it. XBRL created extensibility the way it did to avoid just this situation. You need to be conscious of these types of things when you consider how to use XBRL. Be aware of both positive and negative impacts.
Life is full of tradeoffs, and XBRL is no exception. We can sum up the tradeoffs made in the creation of XBRL in one simple mantra: "Easy stuff should be easy, and hard stuff should be possible."
Furthermore, XBRL was designed by a committee, which anyone could join. In addition, any member could participate and push for what he desired. As with any committee-based design, XBRL isn't perfect. Neither is any other standard. Finally, during the creation of XBRL, many other Web standards were still in development and were unavailable for use.
Because of the tradeoffs made in the development of XBRL, XBRL has issues that may need to be overcome in certain situations or use cases. The following sections discuss tradeoffs made in the development of XBRL and provide insight on how to overcome any negative impacts.
It may seem like an obvious choice today, but XML was an upstart in 1998 when XBRL got started. Perhaps you've heard the phrase, "Standing on the shoulders of giants," which was another mantra of those deciding the architecture of XBRL. The World Wide Web Consortium (W3C), the giant in this case, was working on a lot of different specifications to support XML. For example, specifications for encrypting XML or digitally signing an XML document didn't exist at the time. But everyone anticipated that they would exist, so XBRL didn't address these issues, but instead planned to leverage what the W3C would eventually create. As a result, users of XBRL can make use of W3C standards for encrypting and digitally signing their XBRL.
Note
At the time of XBRL 1.0's creation, how schemas would be expressed was unclear. XBRL 1.0 provided a document-type definition (DTD), but the XBRL creators knew that XML Schema, or something like it, would exist. As such, the creators of XBRL didn't want to re-create an approach to expressing business concepts, but rather leveraged XML Schema to express business concepts within XBRL. Likewise, rather than create an XBRL-specific approach to expressing relations, they used XLink (W3C XML language for creating and describe links) to express such relations.
Early in XBRL's life, before it was even called XBRL, its prototypes were mainly related to financial reporting. XBRL's early name was even focused on financial reporting, partially because those who started XBRL came from that background. But as they thought about it more and more, those early pioneers realized that what they were trying to create would have applications far beyond financial reporting. So, they made a choice to focus XBRL not just on financial reporting, but rather on business information exchange in general.
The world of business information exchange is extraordinarily complex. XBRL had to provide a common baseline for the many types of business information exchange. No one will ever use all the features or characteristics of XBRL at the same time. Most XBRL users won't have all the problems of business information exchange in their use cases for XBRL; they'll have a smaller set of problems. All that XBRL provides may seem excessive for these smaller use cases.
However, XBRL's users will use what they need and ignore the parts that aren't applicable to their situation. This choose-what-you-need approach is one reason XBRL is created in a modular manner.
Tip
One impact of this all-purpose nature of XBRL is that, at times, it can be too flexible and have too many options, so systems that make use of XBRL must constrain that flexibility and eliminate undesired options by using an application profile of XBRL (see Chapter 12.)
One early and unanimous choice in the early development of XBRL was to use an atomic approach to expressing values as opposed to the more constraining content model or document model generally used by XML. The decision's primary driver was flexibility.
To understand this choice, you need to understand the two options:
Atomic approach: This approach models information independently of other information to which it might relate. Separating the information from its relations to create atomic, stand-alone pieces of information is quite flexible. However, understanding information that relates to or is even dependent on other information is more challenging because information isn't bound together like more traditional XML languages, which bind information together using the XML content model.
Document approach: In this approach, you can express information that depends on other information. However, this approach isn't as flexible and makes using information independently harder. This approach leverages the XML content model to bind things in order to keep them together. The content model creates one explicit hierarchical information model. The downside is that separating information for independent use is more challenging.
One of XML's greatest strengths is its hierarchical nature — its ability to express related information in the form of a content model. However, the constraint of a content model has two downsides:
You can express only one content model, and that content model is implicit. By implicit, we mean that you really don't understand if the content model expresses, say, a document, a transaction, or something else. It's simply a content model and what it represents is implied.
After you express the content model, you can't easily change it so that you can easily communicate those changes to software applications that use that information model. Basically, the document approach's content model was too constraining.
The constraining content model prevented extensibility, which was high on XBRL's priority list. For that reason, the atomic model was the obvious choice.
However, the atomic approach has some downsides. You must create relationships in order to provide human-readable renderings. For example, rendering XBRL into some human-readable formats involves another step, such as generating a usable content model, because most XML tools for rendering rely on the content model to generate the formatting.
Note
If you feel you need to use the content model when you use XBRL, you can. However, at times, the XBRL's other pieces, which work quite well when you don't use a content model, are harder or impossible to use. For examples, XBRL Dimensions and tuples, or compound facts (see Chapter 22), don't work together well; think twice before you attempt to use XBRL Dimensions and tuples together. The impact of the choice to fine-tune XBRL for the atomic approach is that XBRL is quite flexible in specific areas, yet retains constraint in other needed areas.
XBRL separates the notion of expressing business information and the presentation of that business information. The XBRL creators had a hard enough time agreeing on how to express business information: Agreeing on every nuance of how to present that information would have been impossible.
This separation of the presentation and the information itself means that information users can easily make their own choices about how to present information. The information's creator doesn't dictate how to present that information.
As a result, information can be truly interactive, reformatted on the fly at the whim of the information's users. The downside is that the information's creators may not want users to have that much flexibility in terms of presentation. However, the creators can lock down the presentation. In addition, the separation of presentation and data makes presentation a little bit more difficult for creators and consumers of XBRL.
XBRL isn't just about business reporting. Fundamentally, a business report's purpose is to exchange information, but you're not limited to using business reports for that exchange. The point is, you need to look at business information exchange, which business reporting is a part of.
The world that business operates in today is different than the world businesses operated in yesterday. Tomorrow's business environment will be different than today. The business-information-exchange environment is likewise different.
The creators of XBRL needed to make guesses about the future and give consideration to the past. The following sections discuss premises about the future that the XBRL creators were working under.
Paper is a convenient way to express many types of information. It's simple, it's flexible, and it's a blank slate. But paper also has its disadvantages:
Paper is physical. Paper must be physically transferred from one place to another in order to be used by multiple parties. Copiers and fax machines made the process of multiple people using the same document simultaneously easier.
Paper is two dimensional. Paper has only two dimensions, whereas business information can have more than two dimensions. Approaches to accommodating three dimensions — say, by repeating information and locking down specific dimensions — do work. However, as the number of dimensions increase, so do the challenges of expressing the information on this two-dimensional medium. For example, expressing sales by period, by business segment, by geographic area, by product, or by sales person is possible on paper. However, electronic pivot tables make working with the information much easier.
Paper is static. After you get information on the paper, it's fixed, and you can't change it because the formatting of the information and the information itself are so tightly bound together.
Paper has limited richness. You can put only certain things on paper. For example, you can't put video on paper.
Electronic "paper" formats (meaning HTML, PDF, word-processing documents, and many spreadsheets) are a little better than the "dead-tree" format of a physical piece of paper. You can create multiple copies using digital paper, and you can transfer it over the Web, but electronic paper is two-dimensional and static and has limited richness.
Why stick with paper (the dead-tree type or the electronic type) if other potentially better options are out there? What if we could have more than two dimensions to work with, and they were more dynamic and offered better richness?
New technologies help us visualize the vast quantities of information we have to work with today, quantities that will be even greater tomorrow. We have all heard the phrase "A picture is worth a thousand words." Visualizations can be worth a thousand pictures. For an example, check out the Moritz Stefaner Web site at http://moritz.stefaner.eu/projects/relation-browser. Moritz Stefaner calls itself an "information aesthetics" company. At its Web site, you can read about a radial browser the company has created to "display complex concept network structures in a snappy and intuitive manner." Moritz Stefaner has created a demo of this browser that illustrates countries and geographical features from the CIA's The World Factbook (see Figure 2-1).
We get into how electronic visualization tools, such as radial browsers and pivot tables, can provide more function than a piece of paper more in Chapter 6 when we discuss the notion of interactive information.
To effectively reuse information, the information needs to have context. Simply exchanging data between business systems doesn't automate processes. Although the business system that generates the data understands the context of the generated information, if the receiving system doesn't understand that context, the data isn't reusable. To help drive home this point, a popular view of what is called the knowledge continuum can help you understand the differences between data, information, knowledge, and wisdom:
Data is a piece or a set of measurable or observable value(s). Data is a set of raw facts, such as a list of names and associated addresses or the zip code 98406.
Information is data in some context, and it's usually filtered from the complete set of all data. Information helps you understand; it informs. For example, all the customer names and addresses in your accounting system are information; the information has context because you realize that the addresses are for customers and not for suppliers.
Knowledge is information that you can apply to solve a problem. For example, using the zip code of the customer addresses in your accounting system to find all the customers in a specific area provides you with knowledge.
Wisdom is the application of knowledge to arrive at a decision, usually when you have multiple options. For example, using the zip code from your customer address list and knowledge of traffic patterns helps you plan where to open additional stores.
Note
What constitutes data and what constitutes information may not seem that different, but they are. Information provides context that allows one data value to be understood in the context of other data values. In data exchanges, the contextual information is stripped from the data so that a receiving system doesn't have the required context to use the information in automated computer processes. Humans are required to reconstitute the information. Again, keep in mind that we're talking about dumb computers exchanging information, not smart humans who can look at the data and properly imply certain things. In most cases, computers simply aren't capable of correctly implying context; they do far better if given the proper context explicitly.
Note
You can't realize the knowledge and wisdom until you correctly contend with data and information. More importantly, you can't just leap from data to knowledge. You have to grab hold of certain rungs as you try to climb to the higher levels. To exchange information effectively and make it portable between your business systems, you must exchange information, not data.
Structured information has two parts: syntax and semantics. Both are important, but for different reasons:
Syntax: The syntax of a language describes the valid form that information may take. For example, this valid fragment of XML
<Name>John Doe</Name>
doesn't give any indication of its significance or correct usage.
Semantics: The semantics communicates the meaning of the information. For example, "the balance sheet must balance" or "Assets = Liabilities + Equity" is meaning.
Suppose that one business system sent another business system balance sheet information, and the balance sheet didn't balance. (Don't laugh: In Chapter 1, we discuss how financial institutions made 18,000 errors in their submissions to the FDIC.) For automated information exchanges to work, the meaning of the information must be correctly expressed during creation and correctly interpreted during receipt. This meaning, such as "the balance sheet must balance," is critical to creating reliable automated information exchange processes because it's the meaning that keeps garbage out of the information being exchanged.
Note
When we talk about structured information, we mean information structured for meaning like XBRL, not information structured for presentation like what you'd see on an HTML Web page. There is a big difference between <bold>1000</bold> and <Sales>1000</Sales> (see Chapter 21).
Suppose that you received a piece of paper bearing the information in Figure 2-2. Could you understand that information well enough to effectively rekey that information into, say, a spreadsheet and compare the information with the same information received from ten other companies?
Sure, you could. You'd realize that all the information relates to the company Example Company because it says so on the top of the page. You know that you need to take the numbers and multiply them by 1,000, because it says that the report is showing the information in "thousands of dollars." You know that the two columns of numbers add up because of the single underscore above and the double underscore below the total.
A computer, on the other hand, can't read that printout and imply what a human would be able to imply. All this information must be communicated explicitly.
Seems like a lot of work, being explicit and all, and it is. But it's more work to express the information implicitly and even more work to verify the implicit information is accurately articulated by manually adding up all the numbers printed on the piece of paper.
Why should humans do this? Besides, humans aren't very good at repetitive actions such as this task; they make mistakes. But computers are very good at doing the same repetitive thing over and over and over. They run into problems only when they run into something new that they don't know how to handle.
Tip
Being explicit makes information actionable. You can receive information without prior knowledge of the information, without human intervention, and without custom coding of software applications and get a computer system to do the right thing with that information.
The number of specialized business systems we use is growing. Here are a few examples:
Databases, data warehouses, data marts, and even spreadsheets
Business-intelligence systems
Content-management systems
Knowledge-management systems
Enterprise Resource Planning (ERP) systems
Web services interfaces to these and other systems
Because of the ubiquitous, cheap connectivity offered by the Web, more and more systems, be they your internal systems or external systems of your business partners, can and will need to be integrated. Business users need simple approaches to achieve this integration. Each report is a business user exchanging information with another business user for some purpose.
Metadata is information that describes or classifies other information. Business rules are a type of metadata: a way of expressing semantic meaning important to understanding and getting information exchanged correctly. Another way of saying this is that business rules are a formal and implementable expression of some user requirement. Here are some examples of business rules:
"Assets MUST equal total liabilities plus total equity."
"If property, plant and equipment (PPE) exists on the balance sheet, then a PPE policy and a PPE disclosure MUST exist and they MUST contain. . . ."
Today, business rules are generally stored within each individual application that makes use of those business rules, which causes two problems. First, the approach to expressing the rules is different for each system expressing the business rules. The second, related, problem is that applications that use data can't exchange the business rules that support the data between applications because each system has its own format.
Warning
Because of this dilemma, the important business rules are stripped from information when that information is exchanged between applications. Typically, the business rules are re-created in the receiving system using some different proprietary form, which results in two versions of business rules that can wind up being different in many cases. But what if a global standard for expressing these business rules existed? You could express the rules once and then exchange them between applications along with the information being exchanged.
Tip
That's one of the things XBRL offers: a global standard for expressing business rules, separate from applications, that everyone — the creators of information, consumers of information, and all the parties in between — can use. That means users create the business rules just once, saving both the receiver and the sender time and improving the quality of the information exchange.
Business information exchange is a chain. Most people look at business information exchange from their own perspective as one of the links in that chain. Never before has this fact been as evident as it is today with the ubiquitous connectivity offered for pennies to anyone else on the planet via the Internet. This same technology, the Web, which caused our information overload problem, will be the solution to our information overload problem.
Consider an example from the railroad industry. In the United States, during the evolution of the rail system, competing railroads used different gauges of rails as they spread all over the countryside. At first, it was done by accident because the railroads were usually so far apart and disconnected that they had no need to standardize the width of the tracks. As progress was made and tracks converged into the same cities and towns, a different reason emerged for keeping track widths different: It ensured the rail operators could force freight and passengers to shift one carrier to another.
For a while, when rail travel and transport was a novelty; people were willing to put up with the inconvenience. But as people became dependent on rails for travel and for the shipping of goods, they began to question why all this switching had to take place — especially the owners of the freight, who had to pay significant sums for the labor and time to get their goods from one carrier to the next. The desire for efficient commerce pushed the country toward a common gauge, a standard. In much the same way, commerce is pushing the need for a common approach and vocabulary for exchanging business information today.
After the standardization of the gauges, railroads still faced competition. Instead, railroads competed on the merits of their service rather than the gauge of their track. Many of the lessons from this experience remain relevant today.
Much like a materials-supply chain in manufacturing, an information-supply chain is a critical piece of logistical infrastructure enabling a far more capable organization. An information-supply chain extends upon a preexisting model in the physical world: material-supply chains. If you look at the life cycle of information across organizations, you start to see the information-supply chain. Information-supply chains are so important to understand that we devote all of Chapter 7 to explaining them in greater detail.