XBRL taxonomies are comprised of two parts:

A single XBRL taxonomy may be comprised of a set of multiple taxonomy schemas and linkbases. This set has a specific and important name in XBRL: discoverable taxonomy set (DTS).

A DTS is governed by discovery rules, specified by the XBRL Specification, that XBRL processors understand. A DTS can contain any number of taxonomy schemas and/or linkbases and can start from either a taxonomy schema, a linkbase, or an XBRL instance.

Networks are a logical aspect of XBRL expressed physically as a set of linkbases. Linkbases exist within the physical model and are collections of extended links. Extended links work slightly differently in XLink than they do in XBRL. In XLink, each extended link is physically separated. In XBRL, a role attribute is added to an extended link. A network is a collection of all the extended links of a specific type with the same extended link role. An extended link role is nothing more than a unique identifier expressed as a role attribute of an extended link.

Physically, networks come in two types categorized by the type of extended links they use:

Concepts are defined in taxonomy schemas, which are really XML schemas. The XBRL concepts are XML Schema elements. Basically, XBRL leverages XML Schema as the means of defining XBRL concepts. XBRL adds a few attributes to XML Schema elements.

Taxonomy schemas can point to other taxonomy schemas already defined. XBRL uses the XML Schema mechanisms (import and include) to combine sets of concepts defined in separate physical files. XBRL also provides mechanisms (schemaRef and linkbaseRef) for combining DTS components. All these taxonomy schemas become part of the DTS. These mechanisms allow you to build modular taxonomy schemas. Another discovery mechanism for taxonomy schemas is any reference from a linkbase to a taxonomy schema.

Taxonomy schemas can also point to resource or relation networks that likewise become part of the DTS.

Resource networks are physically contained in XLink linkbases in the form of extended links with a specific role. A resource defined within these networks allows you to add information to the XBRL concepts defined in the taxonomy schema. XBRL provides two types of resource networks in the XBRL specification: labels and references. (See the section "Drilling into Resource Networks," later in this chapter, for more information.) The XBRL modules add other types of resources, such as formulas and formatting information (see Chapter 16). You can add your own types of resources using the Generic Linkbase specification (see Chapter 16). Taxonomy schemas or XBRL instances can connect a resource network to the DTS.

XLink linkbases physically contain relation networks in the form of extended links with a specific role. Relation networks allow you to associate one concept with another concept in various ways for many purposes. XBRL provides three types of relation networks in the XBRL specification: presentation, calculation, and definition. (See the section "Drilling into Relation Networks" later in this chapter, for more information.) You can add your own types of relations using the Generic Linkbase specification; refer to Chapter 16. Taxonomy schemas or XBRL instances can connect a relations network to the DTS.

XBRL instances contain the information that is being exchanged. That information is expressed in the form of facts. Each fact is associated with a concept from an XBRL taxonomy, which expresses the concept and either defines it or points to a definition of the concept external to the XBRL taxonomy by using one or more XBRL references. Concepts are associated with an XBRL instance by being part of the DTS. Other information in networks connected to the XBRL instance provides additional information that helps you understand and use the facts within an XBRL instance. Contextual information is also associated with facts to help further explain things like which entity and which period a fact relates to. Numeric information has additional contextual information called units. You can use XBRL footnotes (not to be confused with what an accountant calls a footnote) to communicate additional information, such as comments.

The ability to express concepts, resources, and relations is well and good, but if the XBRL taxonomy isn't exactly what you want, guess what? You can change it. This characteristic is why XBRL is called the Extensible Business Reporting Language. One of the most powerful features of XBRL is that it's dynamic when it needs to be. Although this extensibility is there if you need it, you don't have to use it.

XBRL's need for extensibility makes the physical syntax level seem somewhat confusing. All these separate components provide the required flexibility needed to make XBRL's extensibility work as needed. The good news is that XBRL processors hide much of this physical syntax from you. The logical view of XBRL is much easier to work with.

We get into the details of how extensibility works later in the section "Gaining Flexibility Through Extension"; for now, just realize that it exists. You never change someone else's taxonomy schema or linkbases, but you can create your own taxonomy schemas or linkbases, which add to or change things others have defined by becoming part of the DTS. You can even nullify what exists in someone else's taxonomy, rendering it unusable. As such, you can change the overall DTS, effectively virtually changing what you should never change physically. Further, the users of the XBRL instance information can clearly see the changes you've made because you communicated those changes in the form of an XBRL taxonomy that is part of the DTS.

Does all this stuff seem complex? Business reporting is complex; sometimes incredibly complex. The good news is that computers, not you, deal with this complexity. Software guides you through the process, makes sure that you follow the rules of XBRL, and otherwise helps you achieve your goals. Software verifies that everything is okay by checking to be sure that your code doesn't have any errors, a process known as validation. You can make a mistake in lots of different ways and places, so you can check for errors in many different ways. (Chapter 12 covers validation in detail.)

XBRL requires everything in an XBRL instance to be explicitly defined. An XBRL instance must directly or indirectly physically reference all those XBRL taxonomies whose concepts, resources, and relations have bearing on the XBRL instance's contents. The first thing an XBRL processor does when it encounters an XBRL instance is attempt to discover all its related XBRL taxonomies; if it can't, it goes no further!

Schema files in XML and XBRL taxonomies work differently. The XBRL taxonomies must exist and be discoverable. XML can provide hints about the schema or point to a schema, or it may not provide a schema at all. Not with XBRL. Those schemas that are XBRL taxonomies must exist because the XBRL taxonomies enable you to understand the information in the XBRL instance. Figure 4-1 shows how multiple taxonomy schemas and linkbases are brought together into a DTS.

In Figure 4-1, the XBRL instance is connected to a set of two XBRL taxonomies. Each XBRL taxonomy is comprised of one taxonomy schema and two linkbases. The DTS is the combined set of all taxonomy schemas and linkbases from both XBRL taxonomies.

When we talk about networks in this book, we're not talking about computer networks, broadcasting networks, or any other form of communication. Although network is clearly not an accounting or business term, it's a way to describe something that does occur in business information.

Figure 4.1. A DTS.

Networks have two important states:

Here's an example of a network: Property, Plant and Equipment, Net is an accounting concept that would likely be designed in a calculation network in XBRL to denote their mathematical accounting relationship, shown in Figure 4-2.

Figure 4-2 shows that XBRL is saying that Property, Plant and Equipment, Net = Land + Buildings + Furniture and Fixtures + Other. To express relations in an XBRL taxonomy, you must have at least one network because all resources and relations exist within a network.

Figure 4.2. A depiction of a relationship expressed within a network describing Property, Plant and Equipment, Net and its subcomponents.

When to use networks

When you build an XBRL taxonomy, you express resources and relations within networks. Understanding why you'd use a network helps you understand what networks are. You separate relations into different networks for two general reasons:

• Convenience: The taxonomy creator may want to create several smaller networks rather than one big network. For example, in the US GAAP taxonomy, the information contained in the taxonomy is broken up into multiple networks. Another way that the taxonomy may have been created is by combining all those networks into one single network. Sometimes working with several smaller pieces rather than one big piece is easier. Networks allow you to create pieces, if you want.

• Out of necessity: Sometimes you have to create networks. Eliminating conflicts when one parent concept has two or more possible sets of child concepts is another reason to create a network. For example, it would be impossible to express these three different ways to arrive at the one value for Receivables, Net in one network:

  • Receivables, Net = Receivables, Gross minus Allowance for Bad Debts

  • Receivables, Net = Receivables, Net, Current plus Receivables, Net, Noncurrent

  • Receivables, Net = Trade Receivables, Net plus Financing Receivables, Net plus Other Receivables, Net, and so on

Tip

On the left side of Figure 4-3, nothing is physically separating the three ways to compute Receivables, Net. Humans can see this separation; we understand that they're distinct. But how would a computer know that they're separate? However, on the right side, see how networks physically separate the three different computations? Computers need to be told that the three computations are, in fact, separate. Otherwise, they'd collide. Networks provide that physical separation, communicating that separation to software applications.

Figure 4.3. Showing how networks help avoid conflicts.

Trying to express all three of these relations within one network would result in collisions in the relations. To get around this issue, you must use three different networks, one expressing each of the different calculation relations.

Essentially, taxonomy schemas are all about concepts, modeling the pertinent aspects of a collection of business concepts (controlled vocabulary) related to some exchange of business information. XBRL instances use concepts from a taxonomy schema to express fact values for the purpose of exchanging this information.

Concepts have the following characteristics expressed as attributes of XML Schema xs:element elements:

Here's what a concept looks like within a taxonomy schema expressed as an XML Schema element:

<xs:element
name="NetIncomeOrLoss"
id="basic_NetIncomeOrLoss"
type="xbrli:monetaryItemType"
substitutionGroup="xbrli:item"
xbrli:periodType="duration"
xbrli:balance="credit"
>

The preceding code fragment expresses the concept NetIncomeOrLoss in the form of an XML Schema xs:element element within a taxonomy schema. The element has a number of attributes. Many of these attributes are provided by XML Schema, including the name, id, type, and substitutionGroup. The xbrli:periodtype and xbrli:balance are attributes added to XML Schema by XBRL. The values for the attributes are rather straightforward; refer to the list before the code fragment.

Another piece of the taxonomy schema that you may find are references to other taxonomy schemas and linkbases. You can create references using the following elements:

These pointers allow you to use taxonomy schemas, XML schemas, or linkbases others have created; let you modularize your taxonomy so that you or others can use some parts of your XBRL taxonomy without being forced to use other parts; and otherwise physically separate the files that make up your XBRL taxonomy.

XBRL instances always refer to an XBRL taxonomy or a set of XBRL taxonomies, collectively known as the DTS. Because the XBRL taxonomies make up the DTS that determines the controlled vocabulary and the other semantic meaning expressed by the XBRL taxonomies, you'll want to know where to get those all those XBRL taxonomy pieces. The references to these physical files tell you where to get the XBRL taxonomy pieces that explain the controlled vocabulary the XBRL instance uses and all the other meaning expressed for the information model by the DTS.

Figure 4.4. Relations between XBRL instance components and XBRL taxonomy components.

An XBRL instance can refer to pieces of the DTS in two ways:

An XBRL processor is responsible for grabbing all the referenced XBRL taxonomy pieces that make up the DTS, putting all the pieces together correctly, and communicating any issues relating to that process to the user of the XBRL instance.

Here is an example schemaRef:

<link:schemaRef xlink:type="simple" xlink:href="Example.xsd" />

The preceding code fragment shows a schema reference to the taxonomy schema with the name Example.xsd. A linkbase reference is similar, with the only difference being a different element name.

Contextual information helps users of the information in the XBRL instance understand the context in which the information is being used. Context is provided using the xbrli:context element, which contains

Putting these pieces together, here's an example of a xbrli:context element:

<xbrli:segment>
      >>>>>segment information would go here<<<<<
     </xbrli:segment>
</xbrli:entity>
<xbrli:period>
 <xbrli:startDate>2009-01-01</xbrli:startDate>
 <xbrli:endDate>2009-12-31</xbrli:endDate>
</xbrli:period>
 <xbrli:scenario>
   >>>>>scenario information would go here<<<<<
 </xbrli:scenario>
</xbrli:context>

The preceding code sample shows the components a xbrli:context element from an XBRL instance. The context has an id value of D-2009, which is the same value of the contextRef on one or more facts, which we discuss in the upcoming section "Expressing the values for facts." The entity xbrli:identifier element has a value of SAMP, which comes from the scheme http://www.Sample.com. The segment element in our example is empty (we just wanted to show you were it would be located) — see Chapter 22. The xbrli:period element has a duration (a period of time) value with a start date of 2009-01-01 and an end date of 2009-12-31. As with the xbrli:segment, the xbrli:scenario element values aren't shown, as we don't want to get into this topic at this time (see Chapter 22).

In order to provide the proper context for a numeric value, you need to know the units for the numeric values. For example, say that you have a value of 1,000. Is that some particular currency, and if so, is it U.S. dollars, euros, yen, or some other currency? Or, is it square feet, the number of employees, or something else?

An XBRL instance contains units whenever you have any numeric fact values. A xbrli:unit element contains the additional context:

Have a look at how you can express units within an XBRL instance:

<xbrli:unit id="U-Monetary">
 <xbrli:measure>iso4217:EUR</xbrli:measure>
</xbrli:unit>

The code sample of unit shows the unit element with an id attribute value of U-Monetary that would correspond to one or more fact unitRef attribute value, which ties the fact to this unit. The xbrli:unit element has a xbrli:measure element with the value of iso4217:EUR, which means that the ISO 4217 standard currency code value of EUR for euros is the unit of measure.

An XBRL instance's meat is the fact that the XBRL instance is communicating. What a fact looks like can be slightly different depending on whether it's numeric. Numeric facts need to indicate the units in which the numeric fact value is expressed and the decimal places of the numeric value.

These parts make up a fact in an XBRL instance:

Here is an example of a numeric fact:

<basic:NetIncomeOrLoss
  contextRef="D-2009"
  unitRef="U-Monetary"
  decimals="-3">5347000</basic:NetIncomeOrLoss>

The preceding XBRL instance fragment shows a fact with the value of 5347000. That fact expresses information for the concept basic:NetIncomeOrLoss. It points to a context with the contextRef of D-2009 and units information with the unitRef of U-Monetary. (Refer to the earlier sections "Giving facts context" and "Units provide additional context for numeric facts.") The numeric fact is accurate to −3 decimal places (in thousands), as you can see in the decimals attribute value of −3.

XBRL instances can also contain what are basically comments but are referred to in XBRL as footnotes. XBRL footnotes are used in the XBRL instance as comments or notations that refer to one or more fact values.

Footnotes are good to know about and useful if you have a special case where you need them, but in the grand scheme of things, they really aren't that important. (For more on footnotes, see Chapter 22.)

Suppose that someone created an XBRL taxonomy that included concepts, resources, and relations. An extension can

The user who wants to extend some base XBRL taxonomy creates a new XBRL taxonomy, pulls that base XBRL taxonomy into her extension XBRL taxonomy by referencing it, and thus modifies the DTS with the extension and/or prohibition information from the extension XBRL taxonomy she created. So basically what you're doing with either extension or prohibition is adding pieces (taxonomy schema or linkbase) to the set that comprises the DTS, thus modifying the overall DTS.

The exact opposite of an extension is a form. A form is static. The person completing the form can't change a form to meet his needs. (The creator, though, can update the form from year to year to add new things.) If your information is static like a form, the extensibility features of XBRL may not be that useful to you. But other XBRL features, such as the ability to express the semantics (meaning) of the form, might still be useful, such as form computations or other relations. The underlying point here is that forms are static and don't need extension, whereas many types of business information aren't forms; they are dynamic.

Here are two examples of static versus dynamic data:

The three primary reasons why you may want to create an extension XBRL taxonomy are to

One scenario in which extensibility is valuable is in the financial reporting of publically traded companies. Particularly in the United States, even companies in the same industry don't all report similar information in precisely the same way. In other words, financial statements aren't forms that must be filled in; they're more dynamic. Financial statements have a lot in common, but companies have flexibility in reporting their financial information, taking into consideration the unique aspects of their business. Flexibility, in this case, may mean including a concept that no other business uses, adding things up slightly differently, or putting things in one place rather than in another. XBRL was built to handle this flexibility.