This document sets out the requirements for
a standardised method for the rendering of XBRL instance documents in human
readable form.It defines the specific
features which such a standardised method should support and provides examples
and use cases to illustrate these features.

Requirements centre on the content and
structure of the displayed data.They do
not cover presentational features such as font, colours, graphics and similar
items.These are the province of
specialist rendering applications.

Status

This
is a Public Working Draft whose circulation is unrestricted.Comments should be directed to the authors and
contributors by e-mail.Recipients of
this draft are invited to submit, with their comments, notification of any
relevant patent rights of which they are aware and to provide supporting
documentation.

This document sets out the requirements for
a standardised method for the rendering of XBRL instance documents in human
readable form.

Previous discussion within XBRL working
groups has identified the need for a consistent means of defining how data in
an instance should be ordered and grouped when displayed for human
consumption.Such structuring, including
arrangement in rows and columns, may be critical for human understanding and
interpretation of the data.

This document defines the specific features
which a standardised XBRL rendering method should support and provides examples
and use cases to illustrate these features.

Requirements centre on the content and structure
of the displayed data.They do not cover
presentational features such as font, colours, graphics, pagination and similar
items.These are the province of specialist
rendering applications.

The standardised method is intended to
allow taxonomy authors and instance creators to provide information on how they
want data to be ordered and arranged for display.This rendering metadata will act as an input,
alongside other data and metadata from XBRL taxonomies and instances, for
applications which consume and render XBRL information.

A standardised rendering method MUST
allow both taxonomy authors and instance preparers to create, amend and extend
rendering metadata.

Taxonomy authors may wish to create a
standardised rendering for a typical instance based on a
taxonomy.This provides a
foundation which instance creators MAY use if they wish.

Instance creators MUST be able to amend
any rendering metadata provided in referenced taxonomies.

This implies that some aspects of
rendering will be defined in taxonomies or taxonomy extensions; however, other
aspects, such as the textual content of footnotes (as defined in the XBRL
Specification [XBRL]), may only be defined within an instance.

A standardised rendering method MUST be
able to reproduce completely all facts in an instance, including all
data types and footnotes, without loss of data.

Among other things, this will enable preparers
and consumers of an instance to ensure that a standardised rendering is a
complete view of an instance and no other information is included in an
instance which is not represented in the rendering.

A standardised rendering method MUST NOT
add information to a rendering which is not included in the instance, the
referenced taxonomies or standardised rendering metadata.

A standardised rendering method MUST
reflect all features of an instance and its taxonomy set which are relevant to creating
a basic, human-readable view of the data in an instance.This is to ensure different applications
which implement the standardised method produce consistent and repeatable views
of an instance.Consistency in this case
means the same data content structured in the same way.It does not include presentational features
such as the precise font used.This
document defines the XBRL features which are relevant to such a basic,
standardised rendering.

A standardised rendering method MUST enable
an instance preparer to adjust the facts in an instance and produce a new
rendering which is consistent in organisation and format with a rendering of
the previous instance.This is to
support easy production of updated or amended reports.

A standardised rendering method MUST
show accurately all facts as defined in an instance.In particular, it MUST accurately display
numeric data values in accordance with definitions of number, decimals and
precision in an instance document.

A standardised rendering method MUST
maintain the positive and negative signs on values as defined in the instance
document.The form of distinction
between positive and negative is a presentation issue which is outside the
scope of these requirements and may be application dependent.(Examples of possible representation include
the use of a minus sign or brackets for negative data, or the use of
colour.)

3.7Grouping and ordering

A standardised rendering method MUST enable
the organisation of data into rows.It
MUST enable the definition of content of a row in terms of any individual
element, including a tuple element, and/or contexts,
including combinations of contexts.It MUST also enable the grouping and ordering
of rows.

Grouping will define which rows MUST be
displayed together in a single section.It
MUST support the definition of sub-sections within sections, to an unlimited
level of nesting

Ordering will define (a) the ordering of
rows within sections and sub-sections and (b) the ordering of sections and
sub-sections, to an unlimited level of nesting.

The means of delineation between
sections or sub-sections is a presentational issue which is application dependent
and outside the scope of these requirements.(Typically, this might be done with line spaces and/or indentations, but
other approaches are possible.)

The method MUST preserve the underlying
order of facts in the instance when there is no other ordering metadata
provided by the user.

A standardised rendering method MUST
enable the definition of the arrangement of instance facts and contexts in
tables of rows and columns.This is the
general case of the arrangement of data in rows as described in section 3.8 on
Grouping and Ordering.

The method MUST allow:

·the definition of the content of each column in terms of an individual
element, including a tuple element, and/or contexts,
including combinations of contexts.

·the grouping of columns into sections
and sub-sections to an unlimited level of nesting,

·the ordering of columns within sections and sub-sections and the
ordering of sections and sub-sections themselves.

The method MUST enable taxonomy authors to
assign default contexts to rows and columns.This allows taxonomy authors to define default renderings for contexts
which are defined only at the instance level (unlike members of a dimensional
domain which may be defined in a taxonomy).The default contexts may represent individual
contexts such as period or combined contexts, such as entity and period.

A standardised rendering method MUST enable
the assignment of identifying labels to a row or column.These identifying labels MAY reflect the
element or context(s) represented or both.

3.9.1Use of
taxonomy labels

The method MUST enable taxonomy authors
and instances preparers easily and efficiently to select labels from a
referenced taxonomy for use in a rendering of an instance.It MUST support the ability to select which
label role should be used on particular rows and columns.This MAY be done on the basis of individual
data values or on sets of data values.For example, standard labels may be appropriate on some sets of data,
terse on some, period-start on some and period-end on others.

3.9.2Amendment
of taxonomy labels

The method MUST enable an instance author
easily and efficiently to amend existing taxonomy labels or create new ones for
the purposes of rendering.

3.9.3Identification
of contexts

The method MUST also enable the
assignment of identifying labels to a row or column to represent the context,
unit, precision or decimal attributes which apply to the data.Examples of such contexts include period and
currency.

Such labels MUST be able to represent multiple
contexts applying to the data in addition to precision or decimals.Examples are 2006; $million,Q3,2005; £,000s.

Such contexts and their representation
by a standardised rendering method will normally be defined by the instance
author, but, as described in section 3.8 on Tables, the taxonomy author MAY
assign default contexts for some rows and columns.

The method MUST allow the instance
author to create human readable representations of contextual data. For example, an instance author may wish to render
data with the context

Note that labels to represent contexts are
tied to the values in a specific row or column of data and are NOT the same as the
more general descriptive headings described in 3.10 which apply to a section of
data, such as a whole note or table (even though the latter may include the
extreme case of a single row or column).

3.9.4Construction
of identifying labels

The method MUST enable information on
elements, contexts, units, precision and decimals to be provided as separate labels
in a rendering or to be combined within composite labels.Typically, one label in a rendering may
represent the taxonomy label for an element and another composite label may
describe the context, unit and precision.However, taxonomy or instance creators may wish to provide context and
unit information in separate, not composite, labels.In other cases, they may wish to run all
identifying information, including element label, contextual and related
information, into a single composite label in a rendering.(An example of the latter would be: Net
profit, company A, Q3, $000s.)

The method MUST allow the provision of empty
identifying labels (or empty fields within composite identifying labels). Labels may be inappropriate for some rendered
data.An example is a textual
declaration on which a label would be redundant.(A specific example of this might be an
element with a label such as Additional explanation on xyz or xyz free text
description.)

A standardised rendering method MUST
allow the assignment of a descriptive heading to any section or sub-section of
a rendering.The (sub-)section may be defined
in terms of either a number of rows or columns or both.

The content of descriptive headings MAY
be based on the labels of elements, including abstract elements, in referenced
taxonomies.

This requirement is intended to cover
the assignment of a descriptive heading to any defined grouping of data,
whether it represents a single element, a (sub-)section,
a table, a note with a broad grouping of data, a primary statement or a full
set of accounts.In the extreme case, a
section could consist of a single row or column, but note that the requirement
for identifying labels tied to an individual row or column is already covered
in section 3.9.

The requirement is for the definition of
one single descriptive heading for any one section of data  multiple levels of
descriptive headings (for example main heading, sub-heading) on a single
section are NOT required for a standardised method.Clearly, a section with sub-sections may have
a descriptive heading for the top-level section and a descriptive heading for
each individual sub-section.

Note that appropriate descriptive
headings are NOT necessarily provided by a parent items in a presentation
linkbase used for presentation of a referenced taxonomy.

The formatting and positioning of
descriptive headings in a rendering is NOT a subject for these requirements.Those are presentational issues and are
application specific.The objective of a
standardised rendering method is limited to (a) identifying the grouping of
data to which a descriptive heading applies and (b) the content of the descriptive
heading.(The requirements for the
definition and ordering of sections are covered above in 3.7 Grouping and ordering.)

A standardised rendering method MUST
enable the identification of important data which should be highlighted in a
rendering.It MUST allow multiple levels
of highlighting without imposing any limit on the number of available
levels.It MUST allow any level of
highlighting to be applied to any row, column or individual item of data in a
standardised rendering of an instance, including descriptive headings.

Examples of data which taxonomy authors
or instance preparers may wish to highlight in different ways include totals
and sub-totals, data with a particular context, such as a specific currency,
audited and unaudited data, and different classes of
information, such as domestic and foreign data.

The standardised rendering method is
only required to identify levels of highlighting and the data to which each
level applies.It is NOT required to
determine the specific means of highlighting or of distinguishing between
different levels of emphasis.This is a
presentational issue and is application specific.(Possible means of highlighting which may be
adopted by applications include varying size and types of font and underlining,
bold, line spaces and colour.)

A standardised rendering method MUST
enable an instance preparer to specify:

·the data groupings (i.e. the sections or sub-sections) in which a
footnote should appear.

·the ordering of footnotes in each section or sub-section.

Any rendering produced by a standardised
method MUST include a display feature to identify the data item(s) to which a
footnote is linked in the instance.The
form of that feature (such as a superscript number) is a presentational issue
which is outside these the scope of these requirements.

A standardised rendering method MUST enable
the identification of data which should be viewed as a whole and not broken when
rendered.It may sometimes be important,
for example, to ensure that a table is viewed in its entirety and not broken
between pages or other forms of display.(Whether rendering applications are apply to comply with such a
requirement in particular circumstances given other formatting constraints is a
matter for those applications, but it must be possible to indicate which
information should not be broken.)

A standardised rendering method is NOT
required to support the general embedding of fact values from an instance
within free text strings.This is a
specialised aspect of presentation which should be achieved with appropriate
rendering applications.Users may create
such presentations themselves using the output from a standard rendering
application as an input.

Note that a standardised rendering method
is required to support the creation of identifying labels which may combine
information on an element and its context, as stated in section
3.9 on labelling.This concerns the
handling of labels and is not a general case of mixing a variety of fact values
and text.

A standardised rendering method is NOT
required to support the application of particular formatting such as font,
bold, underlining, spacing or colour to any text or
numbers, including monetary values.This
is part of presentation which is out-of-scope and the province of specialised
rendering applications.(Such
applications may be expected to handle a variety of international writing
systems, number representation systems, character sets, conventions and other presentational
features.)

A standardised rendering method MUST be
able to reflect all relevant information in the DTS of an instance.The method MUST NOT be
limited to using information in a base taxonomy:it MUST be able to handle any type of
extension while meeting the other requirements set out in this document.

A standardised rendering method MUST
enable taxonomy authors or instance preparers to define alternative renderings
for an instance, including alternative data groupings, ordering, and labelling.It MUST support practical means for users to
select between the alternatives provided.

For example, users may wish to arrange
data in different sections and under differing headings depending on the
prospective audience.A preparer may
want to apply one layout to a report generated from an instance for senior
management and a different layout for sales management.Clearly, this could be achieved by
manipulating the output of a standardised rendering method in a suitable
reporting tool, but this may involve significant effort, and it will typically
be much more efficient to generate the different structures at source.

A standardised rendering method MUST be
format neutral in that it MUST NOT assume or force the use of a particular
solution or file format for the final rendering of instance documents.Similarly, it MUST NOT prevent the use of
common file formats.Preparers and
consumers may wish to generate reports from instances in a variety of formats,
including HTML, XLS and PDF.

A standardised rendering method MUST
enable rendering metadata to be created easily and efficiently by taxonomy
authors and instance preparers.

While this is a general statement which offers
no simple means of measuring compliance, ease-of-use should be an important consideration
in choosing between prospective solutions.The harder it is to achieve ease-of-use in standardised rendering
applications, the slower adoption and progress may be.Among other things, this requirement implies
that any solution should be consistent and compatible with existing XBRL methods.

A standardised method MUST support
instance preparers, helping them to check their progress and verify their
work.A standardised rendered report MUST
NOT be a difficult-to-achieve product after the
completion of a fully validated instance  it MUST be an easily achieved output
during instance creation.

A simple example is that a standardised
rendering method MUST enable different values representing an item in a tuple to be handled in a consistent way, not forcing an
instance creator into a series of repetitive actions to apply the same
rendering definition to each value.

The rendering solution MUST enable an
instance preparer to include formatted content from an external file other than
the instance and its DTS.This would
allow externally sourced content to be mixed with instance-based data in a
standardised rendering.

Reasons for rejection:

This was rejected as out-of-scope of a
standardised XBRL rendering method, which is intended only to cover the
rendering of data in a single instance and its DTS.Mixing of XBRL-based and other data raises a
range of definitional and technical issues.It would undermine the ability to provide assurance on XBRL instances
using standard renderings, since such renderings could contain external data
not based on the instance.Such data
might conflict with the content of the instance, as well as changing over
time.The creation of composite
documents containing XBRL and other data is the province of specialist
applications, which may used a standardised XBRL rendering method as an input.

XBRL instance documents may include a
URI reference or escaped text, but a standardised rendering method MUST pass
this through unchanged.

This section includes a range of examples
of the rendering of business data in real reports.They show general features which a
standardised rendering method must support.It is NOT intended that such a method will support the particular
presentational styles used in these examples.As has been repeatedly emphasised in this document, presentational
features, such as font, bold, underline and other graphics, are the domain of
specialised rendering applications and outside the scope of the standardised
XBRL method.

The description with each example describes
the relevant features which a standardised rendering method must support.

Other examples of rendering, without
commentary, are available in the USFRTF Patterns document.These should be considered as an adjunct to
this requirements document.The latest set
of examples from the USFRTF Patterns document is available in the Rendering
Working Group Sharepoint files, in the Supporting
Materials folder.

This is a relatively simple example of a
table.It includes a section heading (3.
Operating Costs), rows defined by elements and columns defined by contexts,
including dimensional information.Note
the column labels, which combine dimensional, contextual, unit and precision
information.

A standardised rendering method would
not be expected to reproduce all presentational features of this
rendering.This is UK GAAP data and the
columns represent data breakdowns (existing, acquisitions, continuing
total) which are handled by dimension members in the latest UK GAAP
taxonomy.A standardised rendering might
distinguish the labels for dimension members from other context and precision
headings (2000, £000).Equally, a
standardised rendering might be expected to show a full label for the
depreciation of tangible fixed assets under finance leases (rather than
supporting the indent feature shown above) and to include by default a label
for the totals shown in the final row.

This is a full version of the note shown
in Example 1.Points to note are:

a.Values for the items in the
bottom section MUST be aligned under the correct column in the tables (or carry
their own column headings which make their context clear).

b.The use of a label for expanded
information.Under the requirements set
out in the document, the preparer would have the option of amending a standard
label to achieve this result  or including a separate footnote to carry the
relevant data.

c.The use and placement of a
footnote for additional information on fees to auditors. (This information
could have been included in the main table by the use of appropriate elements from
the taxonomy which represent additional fees.)

An example of a table in which rows
represent both element (unallocated central costs) and dimensional (geographic
regions) information and columns represent elements and contexts. Again, a
label differs from the standard taxonomy version  in this case, to illustrate
a calculation relationship through the use of less.

An example of a table in which rows
represent both element (total operating profit etc.) and dimensional
information (continuing operations, acquisitions) and columns represent
dimensional and contextual information.

This example also includes note links
which relate an item in a primary statement to a particular supplementary
note.(For example, turnover is related
to supplementary note 1.)This
represents cross-linking and is NOT a footnote in the XBRL sense.XBRL has no method to support such cross-linking
and the inclusion of this feature in a standardised rendering method is NOT a
requirement.

Another example of a
table with columns representing dimensional information.This table has various
descriptive headings (2 Segmental analysis for the whole note;Ongoing
businesses  for the top section of the table) and a set of footnotes at the
bottom of the note which relate to various rows and sections in the note.

This is a simple example of a nested
table.The Profit and loss account
table is effectively a section with the main Reserves table.

This example also highlights a label
processing requirement.The date labels
used in the top and bottom rows effectively replace start and end period labels
 which exist for each column item.(For
example, Share Premium Account has start and end
period labels.)The use of a table
forces the merging of these labels in the left hand column.

The default action of a standard
rendering method in merging labels in tables in the case of conflicts has still
to be defined.

This table is similar to other examples
 it differs primarily on being based on data which happens to be represented
in the underlying taxonomy by tuples.

In this case, the rows represent
elements within a standard tangible fixed assets tuple
and the columns represent tuples for each major class
of fixed asset.(In the taxonomy, the
standard fixed asset tuple contain elements for
additions, disposals, depreciation and a large number of other items.This is nested within a tuple
for each major class of fixed asset.)

Clearly, typical taxonomies may contain
a wide range of tuples, including nested tuples, which may have to be rendered in tables.

These examples show data values embedded
in text.Support for embedding of
instance fact values within text in this general way is specifically excluded by section
3.15 from the requirements for a standardised rendering method.

A standardised method is expected to produce
a typical tabular display of fact values.Users may then incorporate this within text using appropriate
applications.

This section outlines briefly a range of
use cases in which preparers and consumers of XBRL data need to render instance
documents.This is intended to
illustrate potential uses of rendering as background to the requirements set
out in this document.It is not an
exhaustive description of all possible uses of rendering or a standardised
rendering method.

Preparers need easily and reliably to
create a human-readable reports which fully and accurately represent the data
in an instance in order to:

·Confirm that the instance
correctly represents the intended information.

·Circulate reports for review by
other individuals or departments in the organisation.For example, a company finance department may
wish to circulate a report for review by senior management.

·Provide a report for external
consumption.For example, an accountancy
firm will need to present accounts to clients for approval, either on paper or
via electronic means.

In creating an XBRL instance and
rendering, preparers may be extracting data from internal systems directly into
an instance, entering data in an application or working from an existing human
readable report.They may be creating an
entirely new report or modifying or updating an existing report.

Preparers will in general need to
produce a limited range of types of report from any one particular taxonomy
set.The report creator will usually be
familiar with the data being provided and primarily requires an easy and
efficient way to generate a report from a single instance.

The form of the instance and report may
be regularly reused.The preparing
organisation may need to make periodic adjustments to the content in a
particular type of instance and see that reflected accurately in a report.

Once a clear, rendered version of an instance
is available, a preparer may adjust its look and feel, using appropriate tools,
to meet particular presentational needs, but that is beyond the scope of a
standardised XBRL rendering method  it is the province of report-writing
tools.

Auditors and other third party
organisations which may be called upon to verify or give assurance on instance
documents need easily and reliably to create human readable reports which fully
and accurately reflect the content of instances.This will enable them to confirm an accurate
match and give necessary assurance across an instance and the corresponding
report.

Receivers require standard, consistent
and reliable means of viewing instances covering different entities and
submitted by different preparers in order to:

·Carry out human review of the
contents of a submission.

·Ensure that different
individuals and departments can see identical renderings of a particular
instance.

In order to handle such tasks, receivers
must be able to:

·Confirm that a rendering is a
full and accurate representation of a data in an instance.

Some receivers may wish to view reports
whose presentation is determined by preparers.This may be a matter of policy, particularly to avoid the risk of
misunderstandings between the receiver and preparer.In these circumstances, receivers will
typically receive a wide variety of formats and will not have any direct
control over the format used.An example
may be a tax regulator receiving GAAP accounts.

Other receivers may be in a position to
impose a standard view on submissions, irrespective of any presentation desired
by preparers.An example may be a
central bank which is able to impose a format on some particular type of
regulatory reporting.

Both receivers and preparers may have to
follow the requirements of legislation which determines how data in some
financial reports is presented for viewing.For example, some national legislation determines the content and
ordering of data in the balance sheet.

In some cases, receivers may be
responsible for the external publication of submissions in human readable
form.In these cases, some may have to
publish in a format required by the preparer; others may be able to impose the
format of publication.

Some receivers may accept rendered
reports from preparers alongside the instances themselves.But receivers then need to (a) retain a
reliable link between the rendered version and instance and (b) have means of
confirming that the content of the instance fully matches the content of the
rendered report.We do not expect
receivers in general to accept companion files for XBRL instances.Even those receivers which are willing to
receive companion files may not be willing to accept certain types of files
which might be used for rendering, such as stylesheets
which have not been pre-approved, since doing so will involve running arbitrary
code on their internal systems, creating a significant security risk.

In the general case, receivers will
require renderings for a wide variety of different instances and implied
presentations  even when those instances may be intended to fulfil a single
regulatory purpose.For example,
financial statements produced under an individual national GAAP may differ
greatly in form and content.In this
general case, renderings must cope with instances based on taxonomy extensions
created by the preparers or other entities.

Receivers will not wish (if indeed they
are able) to invest manual effort in improving the readability of reports from
instances.

Regulators are one important example of
a receiving organisation.Other examples
include financial institutions, investing organisations and risk-assessors.

This document and translations of it may be
copied and furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or references
to XBRL International or XBRL organizations, except as required to translate it
into languages other than English. Members of XBRL International agree to grant
certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained
herein is provided on an "AS IS" basis and XBRL INTERNATIONAL
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is
directed to the possibility that compliance with or adoption of XBRL
International specifications may require use of an invention covered by patent
rights. XBRL International shall not be responsible for identifying patents for
which a license may be required by any XBRL International specification, or for
conducting legal inquiries into the legal validity or scope of those patents
that are brought to its attention. XBRL International specifications are
prospective and advisory only. Prospective users are responsible for protecting
themselves against liability for infringement of patents. XBRL International
takes no position regarding the validity or scope of any intellectual property
or other rights that might be claimed to pertain to the implementation or use
of the technology described in this document or the extent to which any license
under such rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights. Members of XBRL
International agree to grant certain licenses under the XBRL International
Intellectual Property Policy (www.xbrl.org/legal).

Range of amendments based on feedback and
discussion in Rendering Working Group:additions to list of contributors;addition of text in abstract; change rendering mechanism to
rendering method throughout; revision of section on labelling and
inclusion within it of statements on the labelling of contextual information,
which had previously been in a separate section;change of previous pagination section to
make clear this refers to unbroken rendering of particular data and remove
references to pagination;removal of
section on excluded requirements from the MRA;include cross-reference to USRTF patterns
document in examples section;range of
other detailed, clarifying edits; some
minor renumbering of sections to accommodate these changes.

2007-02-12

Calvert

A number of detailed edits to improve
clarity, reflecting feedback from Walter Hamscher and discussion in the
Rendering WG.Positive and negative
values requirement clarified;example
of context label improved.Section on
rejected requirements added.