XML Flattened The lessons to be learned from XBRL

XML Flattened

The lessons to be learned from XBRL

Presentation structure1. XBRL and the domain it addresses.

2. The XML extensibility problem.

3. The XBRL solution.

4. Strengths and weaknesses of the solution.

What does XBRL do? Primarily reporting rather than transactions. Write once, read many. A complex and changing problem domain.

Data reported in multiple dimensions at once.

A domain that is also highly regulated.

XBRL Architecture

XBRL Architecture Schema with minimal hierarchy. Everything's global. XBRL extensions to schema. Linkbases define relationships between concepts

and resources. 5 standard linkbases.

Why? A counter-intuitive approach?

Doesn’t really use the tree structure that is characteristic of XML!

Requirements for flexibility: eXtensible… … but also semantically stable

The XML extensibility problem Starting from a model that allows this:

<TotalExpenses total="400"> <PostageCosts total="10"/> <TravelExpenses total="10"/> <FoodExpenses total="380"/></TotalExpenses>

How do we extend to allow this:<TotalExpenses total="400"> <PostageCosts total="10"/> <OutOfOffice total="390"> <TravelExpenses total="10"/> <FoodExpenses total="380"/> </OutOfOffice></TotalExpenses>

1: Generic Self-Describing Elements Using dynamic typing in XML:

<Expense type="TotalExpenses" total="400"> <Expense type="PostageCosts" total="10"/> <Expense type="OutOfOffice" total="390"> <Expense type="TravelExpenses" total="10"/> <Expense type="FoodExpenses" total="380"/> </Expense></Expense>

Poor schema validation. Reliant on correct high-level analysis.

2: The XML schema approach Using object orientation and substitution groups. <xs:element name=“Expense” abstract=”true” type=“my:ExpenseType”/> <xs:complexType name=“ExpenseType”> <xs:sequence> <xs:element ref=“my:Expense” minOccurs=“0” maxOccurs=“unbounded"/> </xs:sequence> <xs:attribute name=“total” type=“xs:integer”/></xs:complexType><xs:element name=“OutOfOffice” substitutionGroup=“my:Expense”/>

Allows us to use specific elements: greater semantic rigour.

Content model extensibility still problematic. Defers the problem rather than solving it.

Hierarchies: why do we need them? Hierarchies provide context:<CustomerRecord>

<Name>Joe Bloggs</Name> <TelephoneNo>123456789</TelephoneNo> <FaxNo>24681012</FaxNo>

</CustomerRecord> <CustomerRecord>

<Name>Jane Bloggs</Name> <TelephoneNo>987654321</TelephoneNo> <FaxNo>1357911</FaxNo>

</CustomerRecord>

Without context you have this (!): <JoeBloggsTelephoneNo>123456789</JoeBloggsTelephoneNo><JoeBloggsFaxNo>24681012</JoeBloggsFaxNo><JaneBloggsTelephoneNo>987654321</JaneBloggsTelephoneNo><JaneBloggsFaxNo>1357911</JaneBloggsFaxNo>

Hierarchies: not always so important Some hierarchies are about categorisation rather

than grouping data. Our example can be represented sensibly without

a hierarchy:

<OutOfOfficeFoodExpenses total=“380”/><OutOfOfficeTravelExpenses total=“10”/>

Without hierarchies encoded in Schema, many of the extensibility problems disappear: concepts can be added and removed freely.

Hierarchies the XBRL way Removing hierarchies like this still loses

information. XBRL replaces this information through

linkbases. Linkbases can express inter-concept

relationships in a very “loosely coupled” way. Also allows for an arbitrary number of

“dimensions” to be superimposed on a single concept set.

Strengths and Weaknesses In the remainder of the session we will look at

strengths and weaknesses in 3 areas:

1. Extensibility.

2. Information reuse.

3. Validation.

XBRL Extensibility

XBRL Extensibility XBRL is easy to override and extend.

Loosely-coupled networks of arcs. Add new links and “prohibit” old ones

Modularised extensions - original remains unchanged.

XBRL framework itself designed for extensibility. Add new types of arc, link, even whole linkbases. “Segments” and “scenarios” provide another dimension

for extensibility.

Extensibility - limitations Complex webs of documents. XBRL taxonomies are verbose:<loc xlink:href='ifrs-gp-2004-01-15.xsd#ifrs-

gp_AmountDividendProposedOrDeclaredAfterBalanceSheetDateButBeforeAuthorisationFinancialStatements' xlink:label='ifrs-gp_AmountDividendProposedOrDeclaredAfterBalanceSheetDateButBeforeAuthorisationFinancialStatements' xlink:type='locator' />

<presentationArc use='optional' order='3' xlink:arcrole='http://www.xbrl.org/2003/arcrole/parent-child' xlink:from='ifrs-gp_DividendDeclaredAfterBalanceSheetDate' xlink:to='ifrs-gp_AmountDividendProposedOrDeclaredAfterBalanceSheetDateButBeforeAuthorisationFinancialStatements' xlink:type='arc' />

<loc xlink:href='ifrs-gp-2004-01-15.xsd#ifrs-gp_AmountIncomeTaxConsequencesDividendProposedDeclaredAfterBalanceSheetDateBeforeAuthorisationFinancialStatements' xlink:label='ifrs-gp_AmountIncomeTaxConsequencesDividendProposedDeclaredAfterBalanceSheetDateBeforeAuthorisationFinancialStatements' xlink:type='locator' />

Information reuse Presentation neutral.

Instance contains raw, unstructured data – easy to reformat to whatever structure is necessary.

Modularised handling of internationalisation.

Semantic stability. Meaning of concepts less likely to change over time. Instance documents remain meaningful against new

versions.

Information reuse - limitations Less effective for some types of data structure.

Data with many nested structures may not be any more extensible than normal XML.

But XBRL still gives multi-dimensionality – c.f. XBRL GL

Requires specialist software. Drawing in many documents at once makes

processing complicated. Possible to achieve some processing in XSL, but

complicated, inflexible and fragile.

Validation Modularised validation.

Different sorts of validation can be split up along many different axes.

Some new validation already proposed – formula linkbase.

Fine-grained validation. Each validation rule applies to very precise concepts

Validation - limitations Constrictions of linkbases.

Limitations of calculation linkbase. Future development may use other structures for

some purposes.

Overriding hard to control. No concept of “finality” built-in. But no significant technical barrier to constraining this

more closely for particular applications.

Conclusions An unusual modelling approach. A tool to be used carefully. Good for domains that can be modelled statically. Potentially improves extensibility, validation &

information reuse.