1. Introduction
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.
2. Terminology
Terminology used in XBRL frequently overlaps with terminology from other fields. The terminology used in this document is set out below.
|
Term |
Meaning
(Normative) |
|
Taxonomy, instance document, element, context, footnote |
As defined in the XBRL 2.1 Specification [XBRL] |
|
Rendering |
The rendering of an XBRL instance document means the presentation of the data in an instance either on screen or on paper for consumption by a human reader. |
|
Rendering metadata |
Information contained in taxonomies or instance documents which defines how data in an XBRL instance document should be rendered. |
|
Layout |
The arrangement of data on screen or on paper in terms of grouping, ordering and organisation in rows and columns. This does not include presentational features such as font, colour and the like. |
|
must, must not, required, shall, shall not, should, should not, may, optional |
See [RFC2119] for definitions of these and other terms. These include, in particular: should: Conforming documents and applications are encouraged to behave as described. must: Conformant documents and consuming applications are required to behave as described; otherwise they are in error. |
|
User, author, creator,
preparer, consumer. |
Author, creator and preparer are interchangeable. They are a subset of users, since users also includes consumers who only view the instance and cannot (or do not) modify it. |
Editorial comments and discussion that are not intended to be part of the final document are shown as follows:
PSC: This highlighting indicates editorial comments and discussion about the current draft. It should normally be prefixed by the contributor’s initials.
Bold and italics are used for emphasis only and do not convey any special normative meaning.
3. Requirements
3.1 Control of rendering metadata
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.
3.2 Completeness
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.
3.3 Repeatability and consistency
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.
3.4 Adaptability and consistency
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.
3.5 Accuracy
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.
3.6 Positive and negative signs
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.7 Grouping 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.
3.8 Tables
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.
3.9 Labelling of rows and columns
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.1 Use 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.2 Amendment 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.3 Identification 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
(context ((id …)) (identifier …) (period (startDate
2005 01 01) (endDate 2005
09 30)) (scenario (explicitMember ((dimension
reliability)) (unaudited))))
as "Nine months ended 30 September, 2005 (Unaudited)”.
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.4 Construction 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”.)
3.10 Descriptive headings for sections
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.
Examples of possible descriptive headings include: “Notes to Balance Sheet”, “Tangible fixed assets”, “Key performance indicators”, “Five-year summary”, “Breakdown by business division” etc. etc.
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.)
3.11 Data highlighting
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.)
3.12 Footnotes
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.
3.13 Unbroken data
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.)
3.14 Paper and screen
A standardised rendering method is NOT required to support distinctions between rendering required for paper or screen.
3.15 Embedding of data in text
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.
Example 4.9 shows samples of data values embedded within text.
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.
3.16 Handling of text, numbers and monetary values
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.)
3.17 Referenced taxonomies
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.
3.18 Alternative formats
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.
3.19 Output of standardised rendering method
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.
3.20 Standardised rendering process – general requirements
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.
4. Rejected Requirements
The following requirements have been considered and rejected.
4.1 Inclusion of formatted content from external source
Proposed requirement:
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.
5. Examples of Rendering and Rendering Features
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.
5.1 Example 1 – simple table
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.
5.2 Example 2 – note with mixed tables
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.)
5.3 Example 3 – table with rows for dimensions and elements
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”.
5.4 Example 4 – table with dimensions in both rows and columns
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.
5.5 Example 5 – table with different sections, headings and footnotes
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.
5.6 Example 6 – nested tables will illustration of a label processing requirement
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.
5.7 Example 7 – table based on information in a tuple
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.
5.8 Example 8 – footnotes
This example shows a range of footnotes, the top one attached to the full note, the following ones attached to specific items.
5.9 Example 9 – embedding of data within text
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.
6. Use Cases
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.
6.1 Preparers of instances
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.
6.2 Auditors
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.
6.3 Receivers
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.
References
|
Extensible Business Reporting Language (XBRL) Specification Version 2.1, Recommendation with corrected errata to 2005-11-07. |
|
|
Key words for use in RFCs to Indicate Requirement Levels, March 1997 |
Intellectual Property Status
Copyright © 2007, XBRL International Inc., All Rights Reserved
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).
Acknowledgements
To be added
Document History
|
Date
|
Author
|
Summary
of changes |
|
2007-01-05 |
P Calvert |
Initial draft for discussion by Rendering Working Group |
|
2007-02-01 |
P Calvert |
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. |
|
2007-07-24 |
Wallis |
Editorial for publication |
_________