Hiding the Angle Brackets

1. Hiding the Angle Brackets Rendering XBRL for compliance professionals and regulators Lucian Holland 27 April 2005

2. Introductions • About DecisionSoft • Leading supplier of XBRL technology and consulting to regulators worldwide • Industry standard True North Validator • About me • Technical Architect responsible for True North • Regular contributor to XBRL and XML conferences

3. Presentation overview • The rendering problem • Requirements • Challenges • Look at available solutions • Focus on one promising possibility

4. The CFO’s Dilemma This is some very tiny text that is supposed to be part of the report that is on display. <usfr-pt:MarketableSecurities AvailableSecuritiesCurrentNon current precision=“INF” contextRef =“Inst2002” unitRef=“USDollar”> 23445182</usfr-pt:MarketableSecurities AvailableSecuritiesCurrentNoncurrent> <usfr-fst:LoansHeldSale precision=“INF” contextRef=“Inst2002” unitRef=“USDollar” >7747793</usfr-fst:LoansHeldSale><usfr-fst: LoansLoansHeldPortfolio precision=“INF” contextRef="Inst2002“ unitRef="USDollar"> 73167935</usfr-fst:LoansLoansHeldPortfolio> <usfr-fst:NetLoansAllowanceLoanLeaseLosses precision=“INF” contextRef=“Inst2002” unitRef= “USDollar”>930114</usfr-fst:NetLoansAllowanceLoan LeaseLosses> ??**£$&%!

5. The need for readability • The CFO wants to read what he’s sending out • Regulators want to cross-check reports flagged for closer inspection • Analysts and investors want to see the entity’s own presentation as well as the new analyses made possible by XBRL • Key driver for adoption – people must be able to “see inside” the XBRL

6. Requirements for rendering • Comprehensible to the non-XBRL-literate • XBRL is not human-readable • XBRL does things differently to traditional presentations • Needs a robust “sign-off” mechanism • Get to the point where the XBRL can be audited? • Transparent mapping between rendering and XBRL • Information mustn’t be able to change after sign-off • Signing must be integrated to be of real use • Portability • No specialist software at point of consumption • Needs to be lightweight

7. Challenges • Dimensions • Rendering patterns • Segmentation of information

8. Dimensions • XBRL supports multi-dimensional information • Will soon support even more with new Dimensional Taxonomies work • Which dimensions should you use for display? • Facts can be positioned on 3,4,5 (…100?) dimensions at once – which ones should be used? • Dimensions built-in to existing report layouts • XBRL will often be generated from such layouts (e.g. Excel); dimensional structure gets “lost in translation” • Taxonomy authors have minimal control • Almost no interaction possible between semantic structure of taxonomy and dimensions expressed in reports.

9. Period: 2004 Segment: US Total Scenario: Actual Period: 2004 Segment: UK Total Scenario: Actual Period: 2005 Segment: US Total Scenario: Actual Period: 2005 Segment: UK Total Scenario: Actual Dimensions: an example World-wide overview UK report 2000 1000 200 100

10. Movement analysis • A specific problem with dates in XBRL • Relationship between fact and date changes semantics: beginning vs.end • No way to make this explicit in standard XBRL • Perhaps should be fixed at a specification level, but unlikely to happen soon • Important for rendering • Will require tool support, along with more metadata

11. periodType: Instant Movement analysis Taxonomy Balance Change in balance Report periodType: Duration Movement analysis: an example Date: 2004-04-01 Scenario: Actual Date: 2004-10-01 Scenario: Actual Movement analysis Balance=100 Date: 2005-04-01 Scenario: Actual Balance=200 Date: 2004-10-01 Scenario: Projected Balance=250 Balance=200 Date: 2005-04-01 Scenario: Projected Balance=100 Change=100 Period: H1 2004-5 Scenario: Actual Change=50 Change=-100 Period: H2 2004-5 Scenario: Actual Period: H2 2004-5 Scenario: Projected

12. 2004 Actual Movement analysis 2004-04-01 – 2004-10-01 Starting Balance 100 Profits 100 Ending Balance 200 2004-10-01 – 2005-04-01 Starting Balance 200 Profits 50 Ending Balance 250 2004 H2 Projected 2004-10-01 – 2005-04-01 Starting Balance 100 Profits 100 Ending Balance 200 Movement analysis example continued Date: 2004-04-01 Scenario: Actual Date: 2004-10-01 Scenario: Actual Balance=100 Date: 2005-04-01 Scenario: Actual Balance=200 Balance=250 Date: 2004-10-01 Scenario: Projected Balance=200 Balance=100 Date: 2005-04-01 Scenario: Projected Change=100 Change=50 Period: H1 2004-5 Scenario: Actual Change=-100 Period: H2 2004-5 Scenario: Actual Period: H2 2004-5 Scenario: Projected

13. Segmentation • Presentation linkbase only gives a hierarchy • No indication of how to split into tables/sections • As discussed, no link to date, segment or scenario dimensions • Unclear what to do when information is missing • Already a problem for calculations in US-GAAP sample preparation • Will be problematic for rendering as well – how to present a hierarchical structure when some parts may be missing?

14. Presentation overview • The rendering problem • Requirements • Challenges • Look at available solutions • Focus on one promising possibility

15. The shape of a solution • Must handle complex processing – simple transformations inadequate • Will need significant metadata: • “Patterns” – identify standard ways of expressing information and define renderings (e.g. describe the XBRL “shape” of a movement analysis) • “Hints” – allow authors of taxonomies or instances to specify rendering in more detail (e.g. identify specific elements used for movement analysis) • Must be possible for non-technical domain experts to define and shape this metadata

16. Spreadsheet 1 2 3 A 32423 23234 22 B 3789 356 34 C 4799 4394 26 D 338 5799 43 Report Possible solutions: Rekeying • Requires no technology investment • Unreliable • Expensive • Huge maintenance cost • Assumes that XBRL is not the primary format

17. <HTML> Processor 1 2 3 A 32423 23234 22 B 3789 356 34 C 4799 4394 26 D 338 5799 43 Report Possible solutions: Standalone HTML • Portable, open standard • Signing possible, but not built-in • Not an integrated solution, lacks a lot of features • Hard for domain experts to define format • Every report must pass through renderer Distributable Package

18. Web Browser <HTML> 1 2 3 A 32423 23234 22 B 3789 356 34 C 4799 4394 26 D 338 5799 43 <XSLT> Report Possible solutions: XSLT • Widely available, standard and light weight • Rendering can be generated by end user • Can’t sign final rendering • Poor support/performance for complex processing • Nightmarishly difficult to support extension taxonomies • Specialist technical knowledge required to write • Works best for “closed form” solutions Distributable Package

19. Presentation overview • The rendering problem • Requirements • Challenges • Look at available solutions • Focus on one promising possibility

20. The real answer: PDF • “PDF – isn’t that just a static rendering format?” • Can contain a wide variety of machine-readable data including XML • Dynamic layouts that restructure based on XML data • Interactive controls • Sophisticated document management including element-level digital signing

21. Report Report PDF PDF: Encapsulating an XBRL instance • Rich client, ubiquitously available • Already a standard medium for accounts presentation • Rendering driven directly from the data • Signing the rendered form signs the data • Can support complex document workflows • Sophisticated design environments

22. Conclusions • Rendering XBRL poses a lot of challenges technically, logically and on a business level • The obvious solutions aren’t necessarily the right ones! • In general terms, the way forward is to look for “patterns” of standard usage and build rendering support for them • May even lead to a formal specification in the long run • However the “shape” of the output is defined, PDF has the edge as a delivery mechanism: power, flexibility and ubiquitous deployment

23. < /> Thanks for listening!