1. XML Flattened The lessons to be learned from XBRL

2. Presentation structure 1.XBRL and the domain it addresses. 2.The XML extensibility problem. 3.The XBRL solution. 4.Strengths and weaknesses of the solution.

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

4. XBRL Architecture

5.  Schema with minimal hierarchy.  Everything's global.  XBRL extensions to schema.  Linkbases define relationships between concepts and resources.  5 standard linkbases.

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

7. The XML extensibility problem  Starting from a model that allows this:  How do we extend to allow this:

8. 1: Generic Self-Describing Elements  Using dynamic typing in XML:  Poor schema validation.  Reliant on correct high-level analysis.

9. 2: The XML schema approach  Using object orientation and substitution groups.  Allows us to use specific elements: greater semantic rigour.  Content model extensibility still problematic.  Defers the problem rather than solving it.

10. Hierarchies: why do we need them?  Hierarchies provide context: Joe Bloggs 123456789 24681012 Jane Bloggs 987654321 1357911  Without context you have this (!): 123456789 24681012 987654321 1357911

11. Hierarchies: not always so important  Some hierarchies are about categorisation rather than grouping data.  Our example can be represented sensibly without a hierarchy:  Without hierarchies encoded in Schema, many of the extensibility problems disappear: concepts can be added and removed freely.

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

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

14. XBRL Extensibility

15.  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.

16. Extensibility - limitations  Complex webs of documents.  XBRL taxonomies are verbose:

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

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

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

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

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