21
XML Flattened The lessons to be learned from XBRL

XML Flattened The lessons to be learned from XBRL

Embed Size (px)

Citation preview

Page 1: XML Flattened The lessons to be learned from XBRL

XML Flattened

The lessons to be learned from XBRL

Page 2: 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.

Page 3: XML Flattened The lessons to be learned from XBRL

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.

Page 4: XML Flattened The lessons to be learned from XBRL

XBRL Architecture

Page 5: XML Flattened The lessons to be learned from XBRL

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

and resources. 5 standard linkbases.

Page 6: XML Flattened The lessons to be learned from XBRL

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

Page 7: XML Flattened The lessons to be learned from XBRL

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>

Page 8: XML Flattened The lessons to be learned from XBRL

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.

Page 9: XML Flattened The lessons to be learned from XBRL

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.

Page 10: XML Flattened The lessons to be learned from XBRL

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>

Page 11: XML Flattened The lessons to be learned from XBRL

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.

Page 12: XML Flattened The lessons to be learned from XBRL

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.

Page 13: XML Flattened The lessons to be learned from XBRL

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.

Page 14: XML Flattened The lessons to be learned from XBRL

XBRL Extensibility

Page 15: XML Flattened The lessons to be learned from XBRL

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.

Page 16: XML Flattened The lessons to be learned from XBRL

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' />

Page 17: XML Flattened The lessons to be learned from XBRL

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.

Page 18: XML Flattened The lessons to be learned from XBRL

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.

Page 19: XML Flattened The lessons to be learned from XBRL

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

Page 20: XML Flattened The lessons to be learned from XBRL

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.

Page 21: XML Flattened The lessons to be learned from XBRL

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.