Issues and Approaches to Rendering XBRL

http://www.xbrl.org Philadelphia Conference

December 6, 2006David vun Kannon

Member, XBRL Standards BoardDirector, PricewaterhouseCoopersDavid.k.vun.kannon@us.pwc.com

Diane MuellerMember, XBRL ISC

VP, XBRL DevelopmentJust Systems

Diane@JustSystems.com

2

Today’s Agenda Discuss Rendering Issues Showcase some approaches Ponder some questions Discuss

some possible solutions Some possible future directions

Hear your projects’ requirements

3

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

4

Financial Content Life Cycle

Viewing Content

Aggregating Content

Validating Content

Creating Content

Storing Content

Analyzing Content

Publishing Content

Same Data, Different Views

5

What does it mean to prepare an Instance Document for filing? More than the act of Creation

ValidationReviewAttestationMore Review

Filers’ Assumption: WYSIWYG: What You See Is What You Get Or What The Filer Sees Is What the SEC will See –

WFSIWSS…

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…

As of Oct 20 2006Source: http://www.xbrlspy.org/scorecard_details

97 total filings by 32 unique entities

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

XBRL- Applications

Defines the technical standard for the composition of XBRL Taxonomies

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

Software that uses “tagged” data for presentation, analytics, etc.

XBRL-Specification

XBRL- Instance

XBRL- Taxonomy

16

XBRL Taxonomy Structure

Schema

Labels

Reference

Definition

Calculation

Presentation

FormulasLinkbases

Intended purposes:

• Describing the Taxonomy

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

Making the impossible, possible

a quick demo

a linkbase approach to Rendering

22

XBRL Taxonomy StructureEnter the “Rendering” Linkbase

Schema

Labels

Reference

Definition

Calculation

Presentation

Formulas

Rendering?

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

Part 2

28

Tutorial Topics1. What is the goal of XBRL Rendering?2. A framework for thinking about rendering3. Analysis of issues in rendering4. Approaches to coding a rendering engine5. 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<page>

<row><col/><col/><col/>

</row></page>

<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=“”/>

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

51

Situation Inputs

Instance Includes XBRL Profile data for end user choices

DTS Includes Rendering Linkbase Includes XBRL Profile metadata

Outputs XHTML

Embedded XLink simple links back to the inputs

52

What is the processor? We will assume the inputs will be processed by a

stylesheet This will make clearer some of the issues, but other

choices of technology are possible.

Instance,DTS

XSLT Processor XHTML + XLink

Stylesheet

53

“Then a Miracle Occurs…” We need to be more explicit in Step 2…

Instance,DTS

XSLT Processor PageRowColML

Stylesheet

54

That’s just changing the miracle… It is obviously cheating to assume that the

stylesheet already exists The key work of rendering is to write the

stylesheet automatically, based on the inputs! Get used to the idea of writing programs that write

programs…

55

One approach Discover all parts of the chosen PL link role Deal with any prohibition/overrides Sort the concepts into the correct order Eliminate concepts that do not exist in the

instance for any of the chosen presentation dimensions Any modification of the instance due to essence-alias,

etc has to be done prior to this point Apply labels of the proper language and role to

create the header list Assign sequence numbers to facts

56

Wash, rinse, repeat Apply the same process to the other dimensions

that are mapped to presentation dimensions. Each fact that will be presented now has three

sequence numbers Assuming FRTA, ignoring possible duplicate facts

For each pagefor each row

for each columngenerate PageRowColML

57

5. What should a Rendering Linkbase contain? Based on the previous discussion framework

A way to relate dimensions in XBRL to presentation dimensions

A way to compose dimensions from sub-dimensions (aka sort keys)

A way to specify the order of the dimension members From linkbase order From natural order From a call back function

58

Rendering Linkbase (cont.) Labeling for any dimension (not just concepts)

Can be provided by generic linkbase functionality Could include “preferred style” resources for properties

such as font, size, bold, etc based on CSS or other standards

59

Rendering Processor considerations Linking the inputs and outputs

Data to facts Headers to labels Control breaks to Rendering Linkbase resources

Avoid/eliminate semantic firewall issues.

Thank YouPresentation available at: http://conference.xbrl.org/tutorials/tutr04Philadelphia

ConferenceDecember 6, 2006

David vun KannonMember, XBRL Standards Board

Director, PricewaterhouseCoopersDavid.k.vun.kannon@us.pwc.com

Diane MuellerMember, XBRL ISC

VP, XBRL DevelopmentJust Systems

Diane@JustSystems.com