xml flattened

of 21 /21
XML Flattened The lessons to be learned from XBRL

Upload: glynis

Post on 04-Jan-2016




1 download

Embed Size (px)


The lessons to be learned from XBRL. XML Flattened. Presentation structure. XBRL and the domain it addresses. The XML extensibility problem. The XBRL solution. Strengths and weaknesses of the solution. What does XBRL do?. Primarily reporting rather than transactions. - PowerPoint PPT Presentation


Page 1: XML Flattened

XML Flattened

The lessons to be learned from XBRL

Page 2: XML Flattened

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

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

XBRL Architecture

Page 5: XML Flattened

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

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

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

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

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>


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

Page 11: XML Flattened

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

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

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

XBRL Extensibility

Page 15: XML Flattened

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

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

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


Page 18: XML Flattened

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

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

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

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.