How XBRL differs from other XML standards

Developers familiar with XML standards often look at XBRL and ask the same questions:

  • XBRL looks different: how does it differ?
  • Why does XBRL differ?

In this article, Steve Baker, Director of Product Development, explains how and why XBRL differs from most other XML standards.

Check back for later articles on how XBRL works and how to work with it.

XBRL is a framework, not an implementation

Most XML standards provide a schema that defines fairly tightly what structures and datatypes are allowed. If a standard is extensible, it is only in defined places and often in only narrow ways.

XBRL is different: an XBRL report is defined to contain contexts, units and concepts but the XBRL standard does not provide any concrete concepts one can use. Instead, XBRL is defined in terms of the two types of concept: items and tuples. Concrete items and tuples are provided by XBRL taxonomies.

By leaving items and tuples to be defined by domain experts in taxonomies, XBRL provides a great way to model typical business reports in a uniform way, while allowing preparers to report whatever they need to.

XBRL models tables of data

A typical business report will have a column of labels on the left, indented to indicate structure. A table is formed by providing the data for those headings for each of several periods in time: the rows are the facts, the columns are the different periods or instants. The units of the report are given, as is the name of the business entity to which the facts refer. Additionally, footnotes are added, and certain facts typically sum to subtotals.

Sketch these features in a spreadsheet and hand them to a dozen XML gurus and you will get at least a dozen different designs. And remember we didn’t tell the gurus what we would actually be reporting!

XBRL’s big win is that it takes these typical features and gives us one design so we can move forward.

XBRL reports are defined in several parts

Where a schema is usually sufficient, XBRL requires a definition in several parts:

  • The general structure of an XBRL report is defined by the schema for XBRL.
  • The concepts which may be used in a report – the items and tuples – and any datatypes are defined in a taxonomy schema.
  • Relationships between concepts and about concepts are stored in taxonomy linkbases for flexibility:
    • The label linkbase gives various human-readable labels for concepts, often in several languages.
    • The reference linkbase points to authoritative documentation for concepts.
    • Hints about how to present concepts in relation to one another – those indents in the business report – are provided by the presentation linkbase.
    • Statements about how concepts should sum to other concepts are provided by the calculation linkbase.
    • Miscellaneous – and infrequently used! – relationships are given in the definition linkbase.

The way these components of the definition are brought together varies, but typically a report points to a taxonomy schema and the taxonomy schema points to all the other components. Taxonomies often point to other taxonomies.

XBRL uses some uncommon XML technologies and techniques

In addition to the now run-of-the-mill XML technologies like namespaces and XML Schema, XBRL has some uncommon features.

Nothing could work without substitution groups. The schema for XBRL reports says, “you can put items here” but it makes items abstract: you can never use an item directly. Taxonomies declare concrete items that can be substituted wherever XBRL allows an XBRL item. Don’t worry: we’ll be coming back to this in a later article!

A quite arcane part of the landscape of XML standards is XLink. XLink allows the definition of arbitrary networks, or graphs, of relationships between things of any type. XBRL takes XLink and applies it to good effect: all the linkbases use XLink to relate concepts to one another and to other information.

IDs and IDREFs have always been available in XML, but in XBRL they are indispensible. Taxonomy schemas give every concept an ID to which links can refer out of the linkbases. Footnotes use IDs on reported facts with IDREFs to add that extra information to the report.

XBRL is typically quite flat

No doubt you are used to seeing deeply-nested elements in XML documents: tags within tags within tags. In XBRL, reports are usually quite flat. Most of the structure is in the linkbases.

XBRL is not completely flat. Contexts use structure to lay out entity, period, segment and scenario information and units are structured. Tuples can contain other concepts – that is, items or tuples – so they can reintroduce as much structure as is necessary.

But why?!

It’s all about extensibility:

  • Allowing multiple accounting standards within the same framework.
  • Allowing extensions to accounting standards by adding new concepts with new labels and references while changing relationships.
  • Removing concepts from presentation views.
  • Removing concepts from calculations.
  • Permitting labels for concepts in new languages.
  • Inserting new concepts into a report, changing the existing presentation and calculation relationships.

As you can imagine, flexibility and extensibility are available in XBRL to a degree unseen in most standards. Thankfully, all this change happens within the same defined framework, so tools and applications can still get on with the processing.

Further reading

Check back for further articles as we explain how XBRL works in detail. You can also see our paper XML Flattened.