David vun Kannon Member, XBRL Standards Board Director, PricewaterhouseCoopers

1. Issues and Approaches to Rendering XBRLhttp://www.xbrl.orgPhiladelphia ConferenceDecember 6, 2006 David vun Kannon Member, XBRL Standards Board Director, PricewaterhouseCoopers David.k.vun.kannon@us.pwc.com Diane Mueller Member, XBRL ISC VP, XBRL Development Just Systems Diane@JustSystems.com

2. Discuss Rendering Issues Showcase some approaches Ponder some questions Discuss some possible solutions Some possible future directions Hear your projects’ requirements Today’s Agenda

3. Rendering Define the problem The different approaches The implications for XBRL Consider the requirements Outline

4. Financial Content Life Cycle Same Data, Different Views

5. More than the act of Creation Validation Review Attestation More Review Filers’ Assumption: WYSIWYG: What You See Is What You Get Or What The Filer Sees Is What the SEC will See – WFSIWSS… What does it mean to prepare an Instance Document for filing?

6. Who are the stakeholders? The viewing audience: • Preparers • (Accountants>Auditors>Legal>Corporate Communications>etc…) • Regulators • Analysts & Investors • One version of the truth • But visually we are seeing differences

7. Good News: There’s more than one choice… 97 total filings by 32 unique entities Source: http://www.xbrlspy.org/scorecard_details As of Oct 20 2006

8. Same Data; Different Vendor Approaches • SEC Viewer: http://69.56.156.236/viewer • Rivet Open Source Viewer • Fujitsu Plug-in Viewer • JustSystems Viewer

9. Different Implementations; Different Solutions • Each Implementation has a different solution • HMRC • 150,000 lines of hand-coded XSLT for computations • Distributed & Maintained by HMRC • FDIC • Re-use of Reference & Definition Linkbase • Distributed & Maintained by FDIC

10. Each Approach to Rendering • Leverages • different aspects of XBRL • different aspects of XML technologies • Is proprietary to vendor or implementation • Must be maintained & supported • Is not interoperable • No standard approach to rendering • Why is this so?

11. Consider: Some Basic Rendering Questions • What to Render • Where to Render • How to Render

12. #1 – What to Render • XBRL instance documents contain a multitude of data that is not necessarily all related to each other • This data must be collected and sorted into logical and cohesive reports

13. #2 – Where to Render • Reports for financial data have standards which govern the overall layout of a report • Balance sheets are laid out vertically, with the most liquid assets presented first, and ultimately with the totals at the bottom • Other types of reports may choose to lay out numbers side-by-side for comparison purposes

14. #3 – How to Render • Colors and fonts do not matter much to a machine, • but they make a significant contribution to the overall quality and readability of a report for human end users • Visual cues like double-underlining can make the navigation of a very long statement much easier for end users

15. Now Consider: the XBRL Structure Defines the technical standard for the composition of XBRL Taxonomies XBRL-Specification XBRL- Taxonomy Defines a set of data tags in a certain business reporting area (i.e. US GAAP, IAS) “Output” from tagging data using one or more taxonomies XBRL- Instance XBRL- Applications Software that uses “tagged” data for presentation, analytics, etc.

16. XBRL Taxonomy Structure • Intended purposes: • Describing the Taxonomy Linkbases

17. What is Canonical Rendering? • Consider how HTML is rendered in a consistent, reliable and predictable manner across various browsers and platforms • Could XBRL be rendered consistently, reliably and predictably regardless of platform and solution vendor?

18. Self-Describing Tags • HTML works because: • 1) a standards body has defined the formatting semantics to be associated with each tag • 2) vendors have implemented user agents or browsers which interpret those formatting semantics in more or less the same way • XBRL tags have no formatting semantics associated with them, and thus the interpretation of how they should be rendered are entirely arbitrary

19. Possible Reuse Industry Efforts • Intent is not to reinvent the wheel since there has been a significant effort around conducted around formatting XML • Is it possible to leverage the standards work already created by the XSL-FO working group

20. Where does the formatting information belong? • Should the Formatting semantics be left up to the interpretation of software vendors? • If not, where is the most appropriate place to introduce formatting semantics? • At the taxonomy level through the use of a dedicated linkbase? • This would empower taxonomy authors to be in control of the rendering of their financial information • This could reduces the rendering burden on the XBRL community since it can be defined once and reused across thousands of instance documents

21. Making the impossible, possiblea quick demoa linkbase approach to Rendering

22. XBRL Taxonomy Structure Enter the “Rendering” Linkbase

23. Rendering Unit • A single, discrete definition of the above 3 criteria forms a rendering unit: • Rendering units can be nested within other rendering units • Rendering units can exist at any arbitrary granularity - from something as comprehensive as a 10Q report, to something as discrete as the Cash Assets

24. Multiple Views and Formats • As with any linkbase documents, custom roles and arcroles can be used to define multiple, custom views • The Formatting Linkbase can render to any text-based or tag-based output format including HTML, ASCII, XSL-FO (PDF), and even WordML, ExcelML

25. Productivity Gains • A Rendering Linkbase would greatly reduces the number of lines of code compared to conventional XSLT-based solutions • Sometimes by orders of magnitude, from thousands of lines to merely dozens • Also, by defining formatting semantics at the taxonomy level, a tremendous degree of reuse can be realized

26. Extensible Formatting • The Formatting Linkbase is unique in its ability to understand taxonomy extensions at the instance document level • The formatting semantics provided by the taxonomy form the baseline view, but instance documents can capture local formatting semantics to be used only by that instance document • A reviewer may want to redline a particular figure and have that captured as part of the instance document

27. Part 2

28. Tutorial Topics • What is the goal of XBRL Rendering? • A framework for thinking about rendering • Analysis of issues in rendering • Approaches to coding a rendering engine • What should a Rendering Linkbase contain? Please ask questions when you have them!

29. 1. What is the goal of XBRL Rendering? • How to make XBRL into HTML • NOT • This session should incite you to • Participate in the XBRL Rendering work stream • Write better code • Demand high quality from your XBRL software vendor

30. XBRL into HTML - NOT • But what about PDF or XSL FO or … • The ideas we discuss will applicable to most targets • But what about SVG? • We will focus on tabular presentation • Many tools already exist to move from a tabular presentation to a graphical presentation

31. 2. A framework for thinking about rendering • XBRL has clearly separated data from presentation • And some aspects of presentation are currently underspecified! • Rendering is a namespace to namespace transformation • From the namespace of data • To the namespace of presentation

32. Mapping dimensions • Business data is inherently multi-dimensional • Concept, period, entity, etc. • Tabular presentations also have dimensions • Row, column, page, etc. • Rendering is a mapping between semantic dimensions and presentational dimensions • Arrangement in space means nothing to a computer but is very important to us!

33. What is an Income Statement? • Rows = Concepts, order by PL( link role = “Income Statement”, arc role = “parent-child”) • header = preferred label in LL, language = “jp” • Columns = Periods, max = 3, descending order • header = preferred label in GNL, language = “jp” • Page = Entity • header = preferred label in GNL, language = “jp”

34. Swap rows and columns, and it’s still an Income Statement! • Columns = Concepts, order by PL( link role = “Income Statement”, arc role = “parent-child”) • header = preferred label in LL, language = “jp” • Rows = Periods, max = 3, descending order • header = preferred label in GNL, language = “jp” • Page = Entity • header = preferred label in GNL, language = “jp”

35. What is an Expense Report? • Rows = Entities, order by PL( link role = “Org Chart”, arc role = “parent-child”) • header = preferred label in LL, language = “jp” • Columns = Scenarios, order by PL( link role = “Budget”, arc role = “parent-child”) • header = preferred label in GNL, language = “jp” • Page = Concept, Period • header = preferred label in GNL, language = “jp”

36. Required functionalities • Establishing the elements of a dimension • Establishing the ordering of those elements • Either in XBRL or a natural order (date, alphabetic collation, etc.) • Establishing the maximum number of elements • Every element has one or more labels • Currently true of concepts • Must be extended to other dimensions • A presentation dimension may be composed of multiple, ordered subdimensions

37. Still no forcing of design <fact page=“” row=“” col=“”/> <fact page=“” row=“” col=“”/> <fact page=“” row=“” col=“”/> <fact page=“” row=“” col=“”/> <fact page=“” row=“” col=“”/> <fact page=“” row=“” col=“”/> <fact page=“” row=“” col=“”/> <page> <row> <col/> <col/> <col/> </row> </page>

38. 3. Analysis of issues in rendering • Issues to consider (from Hamscher 2004) • Universal • Robust • Accurate • Genuine • Complete • Transparent • Self-contained • Inseparable • Irredundant • Reversible

39. Universal • “Any two users with access to the web must be able to produce the same Display Document given an XBRL instance.” • More of a requirement of accessibility of the rendering application than a requirement on the rendering technology itself.

40. Robust • “The rendering process must either indicate that the instance is invalid or produce a Display Document.” • The rendering application should work with a validator, but validation is a separate part of the process. Assume the input to the renderer is valid.

41. Accurate • “The data in the instance must be consistently rendered in the Display Document.” • The framework developed in the preceding section addresses this area, in which consistency means an order predictable to the human user. • This involves a convolution of data and metadata. • The result may be sparser, denormalised, etc, but still preferred by a person!

42. Genuine • “Only information in the instance and its DTS must appear in the Display Document.” • The preceding framework supports this and makes it explicit. • End user preferences should be captured as part of the DTS • For example, the choice of language, use of labels, etc • Use essence-alias, assume CWA • Has been discussed elsewhere (Madrid) as XBRL Profile

43. Complete • “All the data explicit in the instance must appear in the Display Document.” • A well designed rendering engine should be capable of satisfying this requirement • An end user can choose to deviate from it • Display only the last three periods on the income statement, even though the instance contains twenty periods.

44. Transparent • “The derivation of each display fragment in Display Document, whether from instance, PTVx, or DTS should be traceable.” • No Semantic Firewall! • Allow drill down into the original instance • Includes the Rendering Linkbase!

45. Self-contained • “All information needed to render must be in the Display Document.” • For some targets, such as PDF, this is easy. • HTML + JS + CSS can be spread across many files however.

46. Inseparable • “The Display Document and instance should be bound together if rendering is not reversible.” • This may be infeasible in some circumstances • Virtual instances • Very large instances • Transparency mitigates the risk of not achieving this requirement

47. Irredundant • “The Display Document should not contain unnecessarily repeated renderings of the same fact or visible metadata.” • The preceding framework helps with this, but issues such as page breaks can force judgement calls.

48. Reversible • “Obtaining the Display Document should allow recovery of an equivalent instance.” • Trivially achieved if Inseparable is achieved.

49. Summary on Issues • A useful checklist for looking at vendors • Many of these requirements represent ideals that will not be necessary of desired in specific situations

50. 4. Approaches to coding a rendering engine • Coding approaches • Assume the framework developed earlier • Assume a desire to work within the requirements defined in the last section