issues and approaches to rendering xbrl philadelphia conference december 6, 2006 david vun kannon...
DESCRIPTION
3 Outline Rendering Define the problem The different approaches The implications for XBRL Consider the requirementsTRANSCRIPT
Issues and Approaches to Rendering XBRL
http://www.xbrl.org Philadelphia Conference
December 6, 2006David vun Kannon
Member, XBRL Standards BoardDirector, [email protected]
Diane MuellerMember, XBRL ISC
VP, XBRL DevelopmentJust Systems
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, [email protected]
Diane MuellerMember, XBRL ISC
VP, XBRL DevelopmentJust Systems