1 / 21

XML Flattened

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.

glynis
Télécharger la présentation

XML Flattened

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The lessons to be learned from XBRL XML Flattened

  2. Presentation structure XBRL and the domain it addresses. The XML extensibility problem. The XBRL solution. 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. XBRL Architecture 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: <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>

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

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

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

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

  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: Extensibility. Information reuse. Validation.

  14. XBRL Extensibility

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

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

  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.

More Related