Comparability Business Requirements
Public Working Draft 2.0

Revision: 0.8

2012-12-22

Status

This document is property of XBRL.

This report has the status of a Public Working Draft. As such it is not restricted to XII members.

Revision History

Revision	Date	Description	Author
0.8	2012-012-22	Feedback and updates from further round of feedback. A) 2.1.1.b.1 - comparisons may be of “blocks” level B) 2.7 is added – the author must be able to define the type or quality of the comparison. C) Various calcifications D) 2.8 is added. A assertion author must be able to define a set of pre-conditions or criteria for the assertion. Examples shown.	Thomas VERDIN and Geoffroy de URTASUN, THEIA Partners XBRL Europe Business Registers WG Sean O'Riain, Digital Enterprise Research Institute (DERI)
0.7	2012-09-12	Updates from Ashu Bhatnagar. A) Deleted Contributing work appendix as confusing B) Clarification / terminology on business requirements 2.1.1.a) & 3.1.2.E C) Add XBRL USA as a related stakeholder	Ashu Bhatnagar Greg Soulsby
0.6	2012-05-29	Updates from first round of feedback	Rita Ogun-clijmans. IFRS Herm Fischer And others
0.5	2012-04-10	A) With updates from first round of review - BPB conversation 2012-04-03 B) More clearly show that a comparison can run against multiple pools	Jordan Woodard Greg Soulsby
0.4	2012-03-30	First draft for review outside core team of three. Not for general distribution. Includes feedback from Jason Price.	Ray Lam Jordan Woodard Greg Soulsby
0.3	2012-01-31	Use Case and business rule updates following "final push"	Ray Lam Jordan Woodard Greg Soulsby
0.2	2011-12-05	Use Cases updated	Comparability Task Force
0.1	2011-11-12	Initial draft - composite of working documents to date	Comparability Task Force

1. Introduction

1.1. Purpose

Comparability enables XBRL instance documents, even from different taxonomies, to be compared and consumed.

This document is a tool for defining comparability requirements in detail, from a business point of view.

This report is the core deliverable from phase one of the comparability standard development effort. It is a major input to phase two, where the actual standard will be written. This is to be developed in the next phase by a specially formed working party.

1.2. Scope

This report includes:

1. Formal business requirements, the most important content.

2. Supporting Use Cases from which the business requirements have been developed

3. An abstract model. This is a tools for defining concepts, not a formal or complete model.

4. A stakeholder map.

References to technical issues in this document are abstract, not being intended to be prescriptive for following technical or standards deliverables.

1.3. Document Layout

The sections of this document are:
1) Introduction
2) Use cases: Typical use cases where comparability is required
3) Business requirements: Derived from the Use Cases and review process
5) Appendix:

Stakeholder map

Abstract Domain model: Concepts, attributes, business rules and their relationships -incomplete.

1.4. Stakeholders

It is particularly important that the comparability standards writing process engage its stakeholders.

The greater the level of integration, compatibility and re-use the more effective and efficient Comparability can be.

• End users will have a more consistent experience.

• The standard development process will be faster.

• Vendors will see reduced costs.

Stakeholder types include:

· Standards bodies and organisations, both XBRL and others

· Information consumers

· Information providers

· Vendors

For details of specific parties see the appendix: Stakeholder map.

2. Use Cases

This section describes the Use Cases identified necessary to provide a comparability basis for the broad range of stakeholders.

The Use Cases identified cover the basic operations of:

Instance document writing [1000 Series]
Pooling of instance documents [2000 Series]
Assertion writing [3000 Series]
Writing, running and publishing comparisons [4000 Series]

Each use case section is organized as follows:

· Process overview, outlining the business process that should be adhered to

· A description of each stage of the business process

· Reference to an accompanying appendix that provides further detail on the use case construction, including conditions, event flow and exceptions.

Note that the Use Case numbers are consistent between the diagrams. These numbers are used within the Business Requirements section for cross referencing.

2.1. 01 Basic Comparison Use Case

[1]

Figure 1 - 01 Basic Comparison diagram

2.1.1. Report XBRL Instance[2]

Use Case Name:	Report XBRL Instance		ID:	1000
Primary Actor:	· Reporting Officer
Goal:	[G010] To report company business information in XBRL format.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] XBRL taxonomy must exist. [PRE020] Company business information is prepared for reporting.
Post Condition:	[POST010] XBRL Instance document is published.
Scenarios
Basic Flow of Events:		[BFE010] Reporting officer gathers and prepares company’s business information. [BFE025] Reporting officer maps company’s business information to elements (i.e. concepts) in the XBRL taxonomy. [BFE030] Reporting officer generates XBRL Instance document. [BFE040] Company approves the XBRL Instance document for publication. [BFE020] Reporting officer selects XBRL taxonomy to present company’s business information.
Alternative Flow of Events:		[AFE010] Reporting officer concludes that the chosen XBRL taxonomy is insufficient to meet the needs of the company and thus chooses to extend the taxonomy. [AFE020] Reporting officer generates XBRL extensions to the base taxonomy. [AFE040] Company approves the company-specific extensions for publication. [AFE030] Reporting officer defines, documents, and inserts company-specific extensions into the chosen XBRL taxonomy.
Exceptional Flow of Events:		[EFE010]Reporting officer needs to use more than one XBRL taxonomy to report company business information. For example: local (based on local GAAP) and consolidated accounts (based on IFRS) are published into a single in-line XBRL report. Consumer will use the in-line XBRL report rather than pooling the XBRL instance document. .

2.1.2. Write Basic Assertion

Use Case Name:	Write Basic Assertion		ID:	3000
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertions which support comparability between components of XBRL instance documents.
Assumption:	[A010] The Assertion provider can be authenticated as a reputable domain expert whose Assertions carry authority in the respective domain for which they are providing the Assertions.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider must be able to state authorship of the Assertion so that Consumers are able to verify the author.
Notes:
Narrative
Pre Condition:	[PRE010] XBRL instance documents are available. [PRE020] XBRL taxonomies are available.
Post Condition:	[POST010] Assertions are created and available to be applied in comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE050] The Assertion Provider releases / publishes the assertions for consumption. [BFE020] The Assertion Provider identifies gaps in comparability which can be closed through the provision of Assertions. [BFE030] The Assertion Provider uses the Comparability Specification to create the Assertions. [BFE040] The Assertion Provider tests the Assertions. [BFE010] The Assertion Provider analyzes the inventory of XBRL Instance documents and taxonomies which are available.
Alternative Flow of Events:
Exceptional Flow of Events:

2.1.3. Compare Basic XBRL Instances

Use Case Name:	Compare Basic XBRL Instances		ID:	4000
Primary Actor:	· Comparison Consumer
Goal:	[G010] To perform comparisons of XBRL data
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE020] XBRL taxonomies are available [PRE030] Assertions are available [PRE010] XBRL Instance documents are available
Post Condition:	[POST010] Consumer has performed comparisons which have yielded a valid result
Scenarios
Basic Flow of Events:		[BFE010] The Data Consumer selects XBRL instance documents over which he would like to perform comparisons. [BFE020] The Data Consumer identifies gaps in comparability. [BFE030] The Data Consumer locates assertions that have been provided by Assertion Provider(s) to address those gaps in comparability. [BFE035] The Data Consumer chooses from the set of Assertions that exist. [BFE040] The Data Consumer applies the assertions to the comparability scenarios that he wishes to fulfill.
Alternative Flow of Events:		[AFE010] A pre or post condition of an Assertion fails. [AFE020] The Data Consumer is notified of the failure. [AFE030] The Data Consumer corrects the Assertion, such as choosing another Assertion. [AFE040] The Data Consumer re-runs the Comparison. [AFE100] XBRL instance documents are not public available, e.g. regulators may charge a fee to access data. Do we have specific assertions to handle IP and other entitlements? The same applies for assertion providers and external fact providers. [AFE150] Assertion providers and external fact providers are not public available, e.g. there may be a fee to access.
Exceptional Flow of Events:

2.2. 02 Investing Use Case

Figure 2 - 02 Investing diagram

2.2.1. Report XBRL Instance

Use Case Name:	Report XBRL Instance		ID:	1000
Primary Actor:	· Reporting Officer
Goal:	[G010] To report company business information in XBRL format.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] XBRL taxonomy must exist. [PRE020] Company business information is prepared for reporting.
Post Condition:	[POST010]Existing XBRL Instance document is published.
Scenarios
Basic Flow of Events:		[BFE010] Reporting officer gathers and prepares company’s business information. [BFE025] Reporting officer maps company’s business information to elements (i.e. concepts) in the XBRL taxonomy. [BFE030] Reporting officer generates XBRL Instance document. [BFE040] Company approves the XBRL Instance document for publication. [BFE020] Reporting officer selects XBRL taxonomy to present company’s business information.
Alternative Flow of Events:		[AFE010] Reporting officer concludes that the chosen XBRL taxonomy is insufficient to meet the needs of the company and thus chooses to extend the taxonomy. [AFE020] Reporting officer generates XBRL extensions to the base taxonomy. [AFE040] Company approves the company-specific extensions for publication. [AFE030] Reporting officer defines, documents, and inserts company-specific extensions into the chosen XBRL taxonomy.
Exceptional Flow of Events:		[EFE010]Reporting officer needs to use more than one XBRL taxonomy to report company business information. For example: local (based on local GAAP) and consolidated accounts (based on IFRS) are published into a single in-line XBRL report. Consumer will use the in-line XBRL report rather than pooling the XBRL instance document. .

2.2.2. Pool XBRL

Use Case Name:	Pool XBRL		ID:	2000
Primary Actor:	· · Data Aggregator
Goal:	[G010] To collect together XBRL data from a variety of sources, resulting in a single pool of XBRL data that can be consumed by assertions as part of discrete comparisons which would normally have been performed against just a standalone XBRL instance document.
Assumption:	[A010] The ability to pool XBRL data enables richer ways to analyze and consume XBRL data than is possible with separate standalone XBRL instance data. Pooled XBRL into a data base can provide performance enhancements for software consuming the data and simpler data access.
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE020] XBRL taxonomies exist. [PRE010] XBRL instance data exists.
Post Condition:	[POST010] Pools of XBRL data are available to consumers. [POST020] Pools have appropriate controls and access mechanisms.
Scenarios
Basic Flow of Events:		[BFE010] Data aggregator collects XBRL instance data together. [BFE015] Data aggregator provides an inventory or manifest of the XBRL data that is available. [BFE020] Data aggregator publishes the pool of XBRL data.
Alternative Flow of Events:
Exceptional Flow of Events:

2.2.3. Write Basic Assertion

Use Case Name:	Write Basic Assertion		ID:	3000
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertions which state comparability between component of XBRL instance documents.
Assumption:	[A010] The Assertion provider is a reputable domain expert whose Assertions will carry authority in the respective domain for which they are providing Assertions.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider must be able to state authorship of the Assertion so that Consumers are able to verify the author.
Notes:
Narrative
Pre Condition:	[PRE010] XBRL instance documents are available. [PRE020] XBRL taxonomies are available.
Post Condition:	[POST010] Assertions are created and available to be applied in comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE050] The Assertion Provider releases / publishes the assertions for consumption. [BFE020] The Assertion Provider identifies gaps in comparability which can be closed through the provision of Assertions. [BFE030] The Assertion Provider uses the Comparability Specification to create the Assertions. [BFE040] The Assertion Provider tests the Assertions. [BFE010] The Assertion Provider analyzes the inventory of XBRL Instance documents and taxonomies which are available.
Alternative Flow of Events:
Exceptional Flow of Events:

2.2.4. Assert Comparable Reporting Periods

Use Case Name:	Assert Comparable Reporting Periods		ID:	3100
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertion on reporting periods that can be compared and the reasoning for making such a comparison (for example, instant calendars within a 45 day span of defined date are comparable because they are close to the specified date).
Assumption:	[A010] Comparable reporting period assertion is being used to compare facts with reporting periods that are not equal.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider is writing reporting period Assertions that are relevant to the period type of concepts being compared in a comparison scenario
Notes:
Narrative
Pre Condition:	[PRE020] Representation of periods must be in ISO 8601 format. [PRE020] Representation of periods must be in ISO 8601 format and XBRL 2.1 compliant.
Post Condition:	[POST010] Comparable reporting period Assertions are created and available to be applied as a component to comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE020] The Assertion Provider identifies gaps in comparing facts with different reporting period context that are comparable. [BFE010] The Assertion Provider defines the reporting periods to be compared based on knowledge of xbrl Instance documents and concept period types. [BFE030] The Assertion Provider uses the Comparability Specification to write Assertion on comparable reporting periods. [BFE050] The Assertion Provider releases / publishes the reporting period Assertion for consumption. [BFE040] The Assertion Provider tests comparable reporting period Assertion.
Alternative Flow of Events:		[AFE010] The Assertion on reporting periods yields partial results, Assertion Provider writes alternative reporting period Assertion to cover missing data points.
Exceptional Flow of Events:

2.2.5. Asserts Comparable Entities

Use Case Name:	Asserts Comparable Entities		ID:	3200
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertion on entities that can be compared and the reasoning for making such a comparison (for example, entity A, B, and C are comparable because they are in the same standard industry classification code 1600).
Assumption:	[A010] Comparable entities assertion is being used to compare facts with entity identifiers that are not equal.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider is writing reporting entity Assertions to make comparisons on entities with some logical grouping.
Notes:
Narrative
Pre Condition:	[PRE010] Entity identifiers applied to instance document facts are available. [PRE020] Entity and segment identifiers must be XBRL 2.1 compliant.
Post Condition:	[POST010] Comparable entity Assertions are created and available to be applied as a component to Comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE010]The Assertion Provider defines the entities to be compared based on knowledge of xbrl Instance documents and entity categories for logical grouping. [BFE020] The Assertion Provider uses the Comparability Specification to write Assertion on comparable entity identifiers. [BFE030] The Assertion Provider tests comparable entities Assertion. [BFE040] The Assertion Provider releases / publishes the comparable entities Assertion for consumption.
Alternative Flow of Events:
Exceptional Flow of Events:

2.2.6. Asserts Comparable Sets of Units

Use Case Name:	Asserts Comparable Sets of Units		ID:	3300
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertion on units that can be compared and the reasoning for making such a Comparison.
Assumption:	[A010] Comparable units Assertion is being used to compare facts with units that are not equal.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider is writing Comparable unit Assertions to make comparisons on units that are comparable for some good reason.
Notes:	A few remarks on currency: a) Conversion rate may depend on item type. For example: income statement is converted at average whereas balance sheet is converted at year end rate. b) Investors may want to translate using different methods (latest versus historical exchange rates, fixed or flexible euro conversion rates) c) The conversion rate that an investor may want to use can be the one reported in the XBRL instance document by the company. d) Currency re-denomination; it is possible that one set of data items need to be multiplied or divided with a different factor compared to another set of data items. For example: for the Turkish currency redenomination, all per share data and number of shares had to divided by 1000, whereas other monetary data elements had to be divided by 1,000,000. e) Major versus minor unit of currency. Pence may have to be translated into pounds and vice versa
Narrative
Pre Condition:	[PRE020] Units declarations must be XBRL 2.1 compliant. [PRE010] Units applied to instance document facts are available.
Post Condition:	[POST010] Comparable unit assertions are created and available to be applied as a component to comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE010] The Assertion Provider defines the units to be compared based on knowledge of xbrl Instance Documents and available units and conversion rates between units. [BFE030] The Assertion Provider uses the Comparability Specification to write function to perform the conversion of a set of facts to a single unit equivalent. [BFE040] The Assertion Provider tests assertion on comparable units and conversion function. [BFE050] Assertion Provider releases / publishes the comparable units Assertion for consumption. [BFE020] Assertion Provider uses the Comparability Specification to write Assertion on comparable units.
Alternative Flow of Events:
Exceptional Flow of Events:

2.2.7. Asserts Comparable Concepts

Use Case Name:	Asserts Comparable Concepts		ID:	3400
Primary Actor:
Goal:	[G010] To provide public Assertions on concepts that can be compared and the reasoning for making such a Comparison.
Assumption:	[A010] Comparable concepts Assertions are being created to link similar concepts and provide the reasons the concepts are comparable and the potential differences in concepts.
To Do:	[TD010] Verification here is very important
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider is writing comparable concept Assertions to make Comparisons on concepts that are comparable for some good reason.
Notes:	Example: Ifrs:BasicEarningsLossPerShare is comparable to us-gaap:EarningPerShareBasic because they represent a similar accounting concept. The differences in accounting include calculation inconsistencies because USGAAP calculates this concept as "The number of incremental shares is computed using a year-to-date weighted average of the number of incremental shares included in each quarterly calculation." whereas IFRS calculates it "The number of incremental shares is computed as if the entire year-to-date period were “the period” (that is, do not average the current period with each of the prior periods)." amongst other potential differences). For comparable concepts there may be a simple case and the more complex case: a) As reported. Concepts are comparable based on ‘meaning’ of the item. For example: pre-tax profit irrespective how defined or measured across taxonomies. b) Standardized. Concepts are equivalent based on meaning and child parent relationship. For example: pre-tax profit includes equity earnings for company A but not for company B. Adjustment is made to exclude equity earnings for company A based on default or customized rules.
Narrative
Pre Condition:	[PRE020] Concepts are expressed in compliance with XBRL 2.1 specification. [PRE010] Concepts (represented by and XBRL element) applied to Instance Document facts are available.
Post Condition:	[POST010] Comparable concept assertions are created and available to be applied as a component to comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE040] The Assertion Provider uses the Comparability Specification to write assertion on comparable concepts and alternative assertions for comparable concepts. [BFE060] The Assertion Provider releases / publishes the comparable concepts Assertion for consumption. [BFE030] The Assertion Provider defines alternative assertions for comparable concepts should the primary Assertion set provide null results. [BFE020] The Assertion Provider uses the Comparability Specification to write Assertion on comparable concepts. [BFE010] The Assertion Provider defines the concepts to be compared based on knowledge of XBRL Instance Documents, comparable concepts and their definitions. [BFE050] The Assertion Provider tests Assertion on comparable concepts.
Alternative Flow of Events:		[AFE010] Primary Assertion does not find comparable facts based on the Assertion scenario provided. The Assertion Provider creates a hierarchy of alternative assertions to reach the desired comparison. For example, no results were found for us-gaap:EarningPerShareBasic preform calculation for us-gaap:NetIncome divided by us-gaap:CommonStockSharesOutstanding.
Exceptional Flow of Events:

2.2.8. Asserts Comparable Dimensions

Use Case Name:	Asserts Comparable Dimensions		ID:	3500
Primary Actor:
Goal:	[G010] To write Assertions about comparable dimensions.
Assumption:	[A010] The Assertion Provider is writing Comparable dimensions because they know that a concept has been modeled with a concept (XBRL line item element) and a context axis/member.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider is writing comparable dimension Assertions to make comparisons on dimensions that are comparable for some good reason.
Notes:
Narrative
Pre Condition:	[PRE020] Dimensions are XBRL 2.1 compliant. [PRE010] Dimensions (represented in XBRL ContextRef) applied to XBRL Instance Document facts are available.
Post Condition:	[POST010] Comparable dimension Assertions are created and available to be applied as a component to comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE010] The Assertion Provider defines the dimensions to be compared based on knowledge of XBRL Instance Documents and comparable dimensions. [BFE020] The Assertion Provider uses the Comparability Specification to write Assertion on comparable dimensions. [BFE030] The Assertion Provider tests Assertion on comparable dimensions. [BFE050] The Assertion Provider releases / publishes the comparable dimensions assertion for consumption.
Alternative Flow of Events:
Exceptional Flow of Events:

2.2.9. Generate Investment Comparison

Use Case Name:	Generate Investment Comparison		ID:	4000
Primary Actor:	· Investment analyst
Goal:	[G010] For an Investment Analysts to compare Instance Documents using applicable Assertions.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PreC020] Has access to required Assertion Set/s [PreC010] Has access to the required Instance Documents.
Post Condition:	[POSTtC010] A comparison result has been published
Scenarios
Basic Flow of Events:		[BFE020] The Investment Analysts identifies the Instance Documents available from the firms. [BFE050] The comparison is run. [BFE030] The analyst identifies the available assertions based on the Taxonomy of available instance documents. [BFE040] The Instance Documents are sources. [BFE060] The result of the comparison is published to the Investment Advisor. [BFE010] An Investment Analyst identifies two (or more) firms requiring comparison. Analyst selects a group of companies (sector, country, user defined criteria such as companies with a market value greater than 1 billion in a particular country etc..) .
Alternative Flow of Events:		[AFE010] The comparison of one firm is against an external data source, not from another XBRL Instance Document. [AFE100] The author wants to force the comparison to be done in another currency than is specified by the Assertion Provider. <undefined>
Exceptional Flow of Events:		[EFE010] One of the XBRL Instance Documents does not have some of the information required by one of the Assertions.

2.2.10. Write Comparison

Use Case Name:	Write Comparison		ID:	4100
Primary Actor:
Goal:	[G010] To define a valuable comparison of XBRL Instance Document facts and define Assertion sets that maximize the comparison based on a set of Assertions.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE020] Instances are available. [PRE010] Assertion sets for data are available.
Post Condition:	[POST010] Users of the Assertion model have defined the entities, concepts, reporting periods, units, and dimensions to perform comparison. User defines Assertion set to maximize comparability and query results.
Scenarios
Basic Flow of Events:		[BFE040] The Investment Analyst defines Assertions (or Assertion set) to use when running the comparison (for example use the E&Y Assertion set for comparing US GAAAP to IFRS). [BFE030] The Investment Analyst defines entities to be compared (for example SAP to IBM). [BFE010] The Investment Analyst defines the concept (s) for comparison (For example us-gaap:EarningPerShareBasic). [BFE020] The Investment Analyst defines the reporting period for comparison (For example <xbrli:period><xbrli:startDate>2011-01-01</xbrli:startDate><xbrli:endDate>2011-02-21</xbrli:endDate></xbrli:period>). Assertion providers would have written business rules to ‘normalize dates’. For example: an user specifies as date the fiscal year 2011. A normalized business rule would return all companies that have a XBRL end date falling within a particular range.
Alternative Flow of Events:		[AFE010] The Investment Analyst could define units to be compare (for example <xbrli:unit id="USDPerShare"><xbrli:divide><xbrli:unitNumerator><xbrli:measure>iso4217:USD</xbrli:measure></xbrli:unitNumerator><xbrli:unitDenominator><xbrli:measure>xbrli:shares</xbrli:measure></xbrli:unitDenominator></xbrli:divide></xbrli:unit>). [AFE020] The Investment Analyst could define dimensions to be compared.
Exceptional Flow of Events:

2.2.11. Run Comparison

Use Case Name:	Run Comparison		ID:	4200
Primary Actor:
Goal:	[POST010] Software is able to find all instances that meet the defined requirements of the Investment Analyst based on assertions set provided.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] Assertions set for data are available. [PRE020] Instances are available. [PRE030] Investment analyst has written the comparison.
Post Condition:	[POST010] A comparison of instance document facts and assertions required to make that comparison.
Scenarios
Basic Flow of Events:		[BFE010] The software scans instance documents for defined instance document attributes. [BFE020] The software pulls the facts that meet the requirements defined in the assertion from the Investment Analyst. [BFE030] The software scans instance documents for defined instance document attributes. [BFE040] The software looks to assertion set to see is assertion is provided for unattached data (for example SAP does not contain us-gaap:EarningPerShareBasic but assertion 1234 us-gaap:EarningPerShareBasic to Ifrs:BasicEarningsLossPerShare exists - use this assertion for writing comparison result.). [BFE050] The software does not return data that is not explicitly defined by Investment analyst or explicitly defined in an assertion.
Alternative Flow of Events:		[AFE010] Software scans instance documents for defined instance document attributes. [AFE020] software pulls the fact that meet the requirements defined in the assertion from the Investment Analyst. [AFE030] Software scans instance documents for defined instance document attributes. <undefined> [BFE040] Software looks to assertion set to see is assertion is provided for unattached data (for example SAP does not contain us-gaap:EarningPerShareBasic but assertion 1234 us-gaap:EarningPerShareBasic to Ifrs:BasicEarningsLossPerShare exists - use this assertion for writing comparison result.). [AFE050] Software does return data that is explicitly defined by Investment analyst, explicitly defined in an assertion, and data that has not been completely defined and is considered implicitly comparable.
Exceptional Flow of Events:		[EFE010] User has the option to re-run comparison to include companies that are not fully comparable. For example: user want to compare Q004 growth rates for all constituents of an European stock exchange index for the fiscal year 2010. One company changed accounting policies in Q003 but did not provide restated or cumulative Q003 data. Before publishing the result, the user is alerted to this fact and is asked if he wants to include Q004 data for this company based on original disclosed information only. User can select yes or no. If selected as ‘yes; and when result is published, a warning message appears. If selected no, no value is provided and the reason as to why no value is provided is given to the user.

2.2.12. Publish result

Use Case Name:	Publish result		ID:	4300
Primary Actor:
Goal:	[G010]Produce a report that points the investor to reported facts and assertions made on those facts to make them comparable for investing decisions.
Assumption:	[A010] Investor knows what they would like to compare but might not understand the complexities to make multiple facts comparable. Assertions on data yield more comparison results. Investor wants to know what was asserted on the data to make comparisons in order to make better investment decisions.
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] Comparable fact set exists. [PRE030] Assertions applied to context to create comparable result are known and linked to the fact. [PRE020] Comparison contexts are defined and tied to comparable facts.
Post Condition:	[POST010] Output of comparable facts. [POST020] Identification of context of fact defined in writing comparison (Use Case Number 3100). [POST030] Identification of context of fact defined in run comparison that utilized assertions set artifact. [POST040] Produce a report for Investment Analyst that shows the comparison requested and assertions made on data to yield expected results.
Scenarios
Basic Flow of Events:		[BFE010] – Report comparable facts. [BFE020] – Report context details defined by the Investment Analysis in the Write Comparison use case and link them to the facts. [BFE030] – Report Assertion set used to make comparison. [BFE040] – Write assertion used on comparable calendar and link them to the facts that they apply to. [BFE050] - Write assertion used on comparable entities and link them to the facts that they apply to. [BFE060] - Write assertion used on comparable units and link them to the facts that they apply to. [BFE070] - Write assertion used on comparable concepts and link them to the facts that they apply to. [BFE080] - Write assertion used on comparable dimensions and link them to the facts that they apply to.
Alternative Flow of Events:		[AFE010] - User has the option to re-run comparison to include companies that are not fully comparable. For example: user want to compare Q004 growth rates for all constituents of an European stock exchange index for the fiscal year 2010. One company changed accounting policies in Q003 but did not provide restated or cumulative Q003 data. Before publishing the result, the user is alerted to this fact and is asked if he wants to include Q004 data for this company based on original disclosed information only. User can select yes or no. If selected as ‘yes; and when result is published, a warning message appears. If selected no, no value is provided and the reason as to why no value is provided is given to the user.
Exceptional Flow of Events:

2.3. 03 Benchmarking Use Case

Figure 3 - 03 Benchmarking diagram

2.3.1. Report XBRL Instance

Use Case Name:	Report XBRL Instance		ID:	1000
Primary Actor:	· Reporting Officer
Goal:	[G010] To report company business information in XBRL format.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] XBRL taxonomy must exist. [PRE020] Company business information is prepared for reporting.
Post Condition:	[POST010]Existing XBRL Instance document is published.
Scenarios
Basic Flow of Events:		[BFE010] Reporting officer gathers and prepares company’s business information. [BFE025] Reporting officer maps company’s business information to elements (i.e. concepts) in the XBRL taxonomy. [BFE030] Reporting officer generates XBRL Instance document. [BFE040] Company approves the XBRL Instance document for publication. [BFE020] Reporting officer selects XBRL taxonomy to present company’s business information.
Alternative Flow of Events:		[AFE010] Reporting officer concludes that the chosen XBRL taxonomy is insufficient to meet the needs of the company and thus chooses to extend the taxonomy. [AFE020] Reporting officer generates XBRL extensions to the base taxonomy. [AFE040] Company approves the company-specific extensions for publication. [AFE030] Reporting officer defines, documents, and inserts company-specific extensions into the chosen XBRL taxonomy.
Exceptional Flow of Events:		[EFE010]Reporting officer needs to use more than one XBRL taxonomy to report company business information. For example: local (based on local GAAP) and consolidated accounts (based on IFRS) are published into a single in-line XBRL report. Consumer will use the in-line XBRL report rather than pooling the XBRL instance document. .

2.3.2. Pool XBRL

Use Case Name:	Pool XBRL		ID:	2000
Primary Actor:	· Data Aggregator
Goal:	[G010] To collect together XBRL data from a variety of sources, resulting in a single pool of XBRL data that can be consumed by assertions as part of discrete comparisons which would normally have been performed against just a standalone XBRL instance document.
Assumption:	[A010] The ability to pool XBRL data enables richer ways to analyze and consume XBRL data than is possible with separate standalone XBRL instance data. Pooled XBRL into a data base can provide performance enhancements for software consuming the data and simpler data access.
To Do:	[TD010] What about the extensions?
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE020] XBRL taxonomies exist. [PRE010] XBRL instance data exists.
Post Condition:	[POST010] Pools of XBRL data are available to consumers. [POST020] Pools have appropriate controls and access mechanisms.
Scenarios
Basic Flow of Events:		[BFE010] Data aggregator collects XBRL instance data together. [BFE015] Data aggregator provides an inventory or manifest of the XBRL data that is available. [BFE020] Data aggregator publishes the pool of XBRL data.
Alternative Flow of Events:
Exceptional Flow of Events:

2.3.3. Write Basic Assertion

Use Case Name:	Write Basic Assertion		ID:	3000
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertions which state comparability between component of XBRL instance documents.
Assumption:	[A010] The Assertion provider is a reputable domain expert whose Assertions will carry authority in the respective domain for which they are providing Assertions.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider must be able to state authorship of the Assertion so that Consumers are able to verify the author.
Notes:
Narrative
Pre Condition:	[PRE010] XBRL instance documents are available. [PRE020] XBRL taxonomies are available.
Post Condition:	[POST010] Assertions are created and available to be applied in comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE050] The Assertion Provider releases / publishes the assertions for consumption. [BFE020] The Assertion Provider identifies gaps in comparability which can be closed through the provision of Assertions. [BFE030] The Assertion Provider uses the Comparability Specification to create the Assertions. [BFE040] The Assertion Provider tests the Assertions. [BFE010] The Assertion Provider analyzes the inventory of XBRL Instance documents and taxonomies which are available.
Alternative Flow of Events:
Exceptional Flow of Events:

2.3.4. Compare Against a Pool of XBRL Data

Use Case Name:	Compare Against a Pool of XBRL Data		ID:	4000
Primary Actor:	· Comparison Consumer
Goal:	To perform comparisons of XBRL data against a pool of other similar XBRL data gathered from a collection of XBRL sources
Assumption:	There are cases where it is valuable to compare XBRL instance data against a pool of other similarly reported XBRL instance data.
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] XBRL instance documents are available [PRE020] XBRL taxonomies are available [PRE030] Pools of XBRL data are available [PRE040] Assertions are available which can leverage the presence of pools of XBRL data [PRE050] Assertions can define new and additional comparison points which are possible against the pool (e.g. compare against an average, against a standard deviation, against a certain percentile, etc.)
Post Condition:	[POST010] Data consumer has performed comparisons of XBRL data against a pool of XBRL data
Scenarios
Basic Flow of Events:		[BFE010] Data Consumer selects XBRL instance documents over which he would like to perform comparisons. [BFE030] Data Consumer locates assertions that have been provided by Assertion Provider(s) to address those gaps in comparability. [BFE040] Data Consumer applies the assertions to the comparability scenarios that he wishes to fulfill. [BFE020] Data Consumer evaluates the availability of XBRL pools against which he can perform comparisons. [BFE030] Data Consumer selects an XBRL pool against which to compare his instance document. [BFE040] Data Consumer evaluates the availability of assertion sets which can leverage the data in the XBRL pool. [BFE050] Data selects one or more assertion sets which fulfills his comparison needs. [BFE060] Data Consumer performs comparisons between his instance document and the pool of XBRL data.
Alternative Flow of Events:		[AFE010] A pre or post condition of an Assertion fails. [AFE020] The Data Consumer is notified of the failure. [AFE030] The Data Consumer corrects the Assertion, such as choosing another Assertion. [AFE040] The Data Consumer re-runs the Comparison.
Exceptional Flow of Events:

3. Business Requirements

This section defines the requirements of all XBRL Comparability Use Cases.

Defining a standard that enables these requirements to be met is a major goal of the phase two Comparability Task Force.

3.1. Approach

The business requirements have been written to these rules:

1. Hierarchical: The requirements are structured into Parent Child relationships

2. Complete: The children of a parent define the parent in fully and completely

3. Orthogonal: Each requirement is standalone – the requirements are as independent, with the least amount of overlap as possible.

4. Acceptance criteria: Each requirement has criteria by which the implementation is measured. The criteria of a parent are a summary of the criteria of the children.

3.2. “Requirements” versus “Needs”

In the process of writing the Business Requirements the working party found it helpful to make the following distinctions:

· XBRL Comparability requires management of, and integration into, elements that are non XBRL. For example, external data, such as an exchange rate, is required to be integrated into an XBRL Comparability authoring and execution

· This wider scope means the working party identified issues outside the direct scope of the Comparability standard that are still dependencies

· Therefore, the team determined to define

o "Requirements" to mean something to be reflected in the XBRL Comparability standard

o "NEEDS" to mean a dependency of comparability that would not directly be expressed in the XBRL Comparability standard.

3.3. The tick-back process [3]

The business requirements are derived from the Use Cases. In order to show completeness and avoid duplication and overlap, the relationship from the Use Case to the Business Requirements is shown directly.

The right hand column of this table is a cross reference to the Use Case, and the element within the Use Case, from where the requirement is derived.

e.g. "01 1000 BFE 010" refers to:

- The 01 Use Case diagram

- The Use Case numbered 1000 within that diagram

- The Basic Flow of Events number 010 within that Use Case

The Children BR are assumed to inherit the BR of their Parents, unless stated otherwise. For example:

The entities / nouns in the UML Class diagram, where used in a business requirement or Use Case, in CAPS. This enables unambiguous cross reference.

3.4. Business requirements

These requirements are broken into four parts:

Defining the Comparison Standard
Manage the "externals" provided by assertions providers
Writing a comparison
Publishing a comparison result
Publishing XBRL instances

Number	Requirement	Source Use Case
1	Define comparison standards	01 2000 BFE030
1.1	Manage Comparability specification.
1.1.1	The Comparability specification must be managed in the same regime as other XBRL Standards
1.1.2	The Comparability specification must be integrated with other external standards. Examples are those standards to do with identification, authentication etc.

Number	Requirement	Source Use Case
2	Define Global Comparability EXTERNALS. EXTERNALS are "remote" functions and must adhere to the same requirements as 2.1.3. OUTSTANDING: Clear definition of EXTERNALS. Is an EXTERNAL the concrete implementation of an ASSERTION?
2.1	Requirement: An Externals author must be able to define a function that any appropriate Comparison Author can use:
2.1.1	An External must be writable for
2.1.1.a	Accessing external facts and non XBRL data (such as enterprise identifiers, security identifiers or exchange rates).
2.1.1.b	Mapping between variables (such as exchange rates). Note: these details are specifically for mappings, a simple assertion type.
2.1.1.b.1	Mappings must relate two data points together NOTE: Looking for better name than "data point". The connection may be to blocs of concepts (that are linked by presentation/calculation relationships) for rendering the results of assertion (ex: be able to connect the address abstract item from two different taxonomies, as well as the postal code tag and country tag, for finally rendering two address blocs that contains those concept but also other detailed information – such as street, city… - organized differently in each original taxonomy/instance)
2.1.1.b.2	Mappings must have a single input.
2.1.1.b.3	Mappings must have a single output.
2.1.1.b.4	Mappings preserve type from input to output?
2.1.1.c	Performing a function (such as a mathematical function or a set of functions).
2.1.1.d	Calling a web service.
2.1.1.e	Pools (as well as instances)
2.2	A catalogue of Externals must be published and available to the XBRL community.
2.3	The Externals must be accessed by the community under agreed conditions (covering Intellectual Property, commercial and other criteria).
2.4	Externals must integrate with other standards (such as group http://www.w3.org/RDF/).
2.5	EXTERNALS must be uniquely identifiable by a comparison author, for example by a URI.
2.6	EXTERNALS must be able to draw on other EXTERNALS for input.
2.7	The author must be able to define the “type” of comparison they are defining. For example they may define the quality of the links (we use “exact match” and “narrow match” but many other qualifications may be considered). The expertise on ontologies may give some ideas. Related to this requirement is 3.3.2.2.1 –the end user must be able to access this a comparison result.
2.8	The author must be able to define a set of pre-conditions or criteria for the assertion. Examples include:
2.8.1	The taxonomy that the external applies to
2.8.2	The period e.g. an assertion may only be valid for a specified financial period.
2.8.3

Number

Requirement

Source Use Case

Write a Comparison

3.1

Comparisons Inputs

3.1.1

Comparisons must be able to draw on taxonomies for input.

01 2000 PRE 010

3.1.1.1

Concepts

3.1.1.2

Dimensions

3.1.1.A

The same NEEDS exists for Taxonomies as for Instance Documents – see 2.1.2.A, 2.1.2.B, 2.1.2.C etc

3.1.2

Comparisons must be able to draw on XBRL instance documents for input.

01 2000 PRE 020

3.1.2.1

XBRL facts

3.1.2.2

XBRL periods

3.1.2.3

XBRL entity declarations

3.1.2.4

XBRL concept

3.1.2.5

XBRL dimensions and members

3.1.2.6

XBRL unit

3.1.2.A

An Instance document NEEDS to be uniquely identifiable. A comparer (and a Comparison author) must be able to refer to a unique instance document (i.e. it has a unique id) Aside: See the URN standard http://en.wikipedia.org/wiki/Uniform_Resource_Name for an existing standard.

3.1.2.B

Instance document NEEDS be gettable.

A comparer must be able to retrieve an instance document (ie. it has a URL)

See URL standard http://en.wikipedia.org/wiki/Uniform_Resource_Locator

The document must be accessible by typing the URL into a browser.

IMPLEMENTATION THOUGHT: a candidate technology would be hashed blog objects like git uses?

3.1.2.C

Instance documents NEED be verifiable (Document must be provably valid and unchanged from publication).

For example, Instance documents NEED to be published with a checksum.

Example approach is Md5 http://en.wikipedia.org/wiki/Md5sum

3.1.2.D

Instance documents NEEDS to be authenticable – the consumer should be able to prove that the document is from the author claimed.

The authenticating protocol NEEDS to be open - the end user should be able to chose from a number of the authentication options like http://en.wikipedia.org/wiki/OpenID or VeriSign or other vendors.

3.1.2.E

Instance documents NEEDS be findable / searchable / screenable

An instance consumer / comparer NEEDS be able to find instance documents by search criteria (e.g. "I want all instances of the

a) xyz taxonomy

b) issued by firms in the abc industry

c) who are headquarted in def

d) in this specified time period,

e) suing this financial statement type (annual or interim),

f) and I want the statement update type of …(original, restated, reclassified, pro-forma)."

3.1.2.F

There NEEDS to be a standard language which an end user can use to define a search - see http://en.wikipedia.org/wiki/SPARQL for an example.

3.1.2.G

External suppliers NEED be able to "add value" by codifying / annotating instance documents with meta data (so end users can do the searches, even if the XBRL instance document author did not provide that info). One standard for this is http://en.wikipedia.org/wiki/Resource_Description_Framework#Resource_identification.

3.1.3

Comparisons must be able to draw on functions for input.

3.1.3.1

Functions must be defined in terms of a signature, which consists of input parameters and a result type. E.g. A "Round" function might have a signature of a real number and the number of positions to round. The returned type might be an integer.

3.1.3.2

Functions must be able to handle exceptions.

3.1.4

Comparisons must be able to draw on services for input.

3.1.6

Comparisons must be able to draw on other comparison results for input.

3.1.7

The author must be able to define 2 sides of the comparison. [OUTSTANDING ISSUE: is there a reason to restrict to 2 sides?]

3.1.7.1

For each side of the comparison the author must be able to define the where XBRL compared must be "sourced" (bad name).

3.1.7.1.A

XBRL instance document

3.1.7.1.B

XBRL pooled data

3.1.7.1.C

Other data

3.1.7.1.Ci

Web services

3.1.7.1.Cii

Static data

EXAMPLES
Name	View
Local drive	C:\.
Web address	http:www.mysite.com/xbrl/
Database	Data Source=username/password@myserver/myservice:dedicated/instancename;

3.1.7.2

For each side of the comparison the author must be able to identify the DOCUMENTS [bad name?] within the SOURCE.

3.1.7.2.a

An individual instance document.

3.1.7.2.b

A set of instance document by a set of criteria, which may be meta data.

EXAMPLES
Name
Individual instance file	RIM_2011.xbrl
Individual by unique identifier	Examples of unique identifiers include - Hash keys (a unique key derived from the content http://en.wikipedia.org/wiki/SHA-1) -
Selected pool	All instances where the company is headquartered in Japan and Industry is Mobile Phones

3.1.7.3

For each side of the comparison the author must be able to identify the target within TARGETS the DOCUMENTS.

3.1.7.3.1

The TARGETS may be:

3.1.7.3.1.i

FACTS within an instance document.

3.1.7.3.1.ii

The result of a "function" (e.g. SUM).

3.1.7.3.1.iii

The result of service call such as an exchange rate conversion.

3.1.7.3.1.iv

Data point from a pool (the result of an assertion).

EXAMPLES
Name
Single data point	Annual profit
Derived	Average of "Annual profit"
Service call	Annual profit, converted to USD using Reuters exchange rates as at 2010-01-01

3.2

Comparisons RESULT

For examples of what RESULTS look like see the section Error! Reference source not found. Introduction.

3.2.1

Comparisons must generate a COMPARISON RESULT.

3.2.1.1

A RESULT must be a side by side comparison.

3.2.1.2

The columns and the left hand and right hand side must be of the same form.

3.2.1.3

The columns must reflect the dimensions and criteria used in the authoring of the comparison.

1) There must be a extra column [or more?] to allow feedback to the end user Examples include:

a. feedback from web services

i. Messages, such as definitions, from Assertion providers

ii. Warnings

iii. Errors / failures

b. Pre-condition failures

c. Post condition failures

3.2.1.

There must be a rows must represent the selected left and right hand side.

3.2.1.1

There is a row for each unique member of the DIMENTIONs of the TARGET elements.

3.2.1.2

If there is a match on one side but not on the other then the empty side should show null e.g. you ask to compare the revenues by region of 2 companies – if one operates in a region that the others does not the region should still be listed.

3.2.2

Comparisons must be publishable, so consumers can find and access them.

01 2000 BFE050

3.2.2.1

The approach to publishing results should be the same as for publishing instance docs and taxonomies.

Example: In this example the user asks to compare

1. One and only one instance document on each side

2. For Nokia on the LHS

3. For RIM on the RHS

4. For the year 2011 –include rows even if the data is not there ([NOT] covered?)

5. TARGETED figure of profit (without currency conversion). It is a pre-condition that in both taxonomies the profit figures are listed by product.

6. By the product dimension –include rows even if the data is not there ([NOT] covered?)

7. Using the "Original" reported values

RESULT:

Notes:

1. They selected target instances using the firm names of Nokia and RIM – so the name is shown. This could be shown once rather than repeated on each row.

2. The year is shown as it is a selection criteria. In this case both documents have 2011 year. If there was no data for that year then the columns would be empty. (however, see the note below about the pre and post condition checks). If year was not a selection criteria then it would not be shown. In the case where there is data for more than one year then the amounts would be summed. If profit is defined, say, by month, then it would be summed to the year figure.

3. If, within either taxonomy, the profit figure is broken down by, say, region and product then this request for profit by product alone implies the summing of profit across region.

4. The products "Phones", "Pads" and "Services" are listed and matched on both sides. In this case the profit for the "Minutes" product is in the instance document for RIM but not for Nokia.

5. The profit data point is not specified with a currency conversion, so the result is in the reported currency.

6. Any messages are also allowed for on each side. In this case the Minutes profit is annotated with "estimated". This message might come, for example, from the service provider who is augmenting an original XBRL instance document.

7. If more than one instance document existed for either company in 2011 then the single instance document pre-condition would fail and the result would be a pre-condition exception. [Comment: You would have assertions which would handle this. For example: company produces and 10K and 10KA. The assertion could be then unless specified differently, the 10K A is used. You would also have assertions to handle year end changes and annualize data where appropriate.]

8. If one or both sides did not have matching data (even if there was an instance document) then the post condition of one and only one instance document would fail and the result would be post–condition exception.

Number	Requirement	Source Use Case
3	Perform a comparison
	The user must be able to perform a comparison where an XBRL instance document exists on at least one side of the comparison.
3.1	Specify Explicit comparison inputs
3.1.1	Resolve differences in currency
	The user must be able to resolve differences which are introduced due to numeric figures being given in different currency.
3.1.2	Resolve differences in dates (periods and instances)
	The user must be able to resolve differences which are introduced due to dates being reported which are not identical, but which are close enough for comparison purposes. For example, there should be a way to assert that a date which is within a "15-day" overlap period is close enough for comparison purposes.
3.1.3	Resolve differences in entity declarations /securities etc,,
	The user must be able to resolve differences which are introduced due to entity declarations (pointing at the same entity) being of different format.
3.1.4	Define a way to declare pre-conditions
	Pre-conditions are assumptions that must be met in order for an assertion to execute. For example, an assertion which states that 1.5USD = 1EUR might have a pre-condition that the accompanying date must be "August 2011".
3.1.5	Define a way to declare post-conditions
	Post-conditions are assumptions that must be met in order for an assertion's output to be valid.
3.1.6	Resolve differences in XBRL Concept (taxonomy element) declarations
	The user must be able to resolve differences which are introduced due to reporting elements which are fundamentally the same concept but which use different names because they come from different namespaces/taxonomies.
3.1.7	The user must be able to select COVERED and UNCOVERED. To do: Correct words needed here about COVERED and UNCOVERED, to match with their use in other parts of standard.
3.2	Run a comparison
3.2.1	Inputs
3.2.1.1	Must be able to select a comparison to perform.	10 3000 PRE030
3.2.1.2	Must be able to select both sides of a comparison.	10 3000 PRE010 10 3000 BFE010
3.2.1.3	Must be able to over-ride default setting for a comparison. See ASPECT POINT CUTS and ASPECTS in the domain model.	10 3000 BFE030
3.2.1.4	Must be able to specify pre-conditions.
3.2.2	Execute a comparison	10 3000 BFE040
	Acceptance criteria: A comparison can only execute with mandatory inputs present.
	Acceptance criteria: There is a log or proof of execution.
	Acceptance criteria: All errors are trapped, where they exist, being reported back to the user, with trace information that enables a user to identify the root cause/s.
3.3	Publish a comparison result	01 1000 POST010
3.3.1	Must be able to uniquely identify a COMPARISON RESULT.
3.3.2	From the result you must know what the result is for.
3.3.2.1	Left and right hand sides
	This implies that anything underneath EXTERNALS must have a way to also identify themselves.
3.3.2.2	The comparison
3.3.2.2.1	Syntactic definition of explicit inputs entered into comparison.
3.3.2.2.2	Syntactic definition of implicit results returned.
3.3.2.2.3	Semantic definition of all results in comparison included in the assertion set.
3.3.2.3	The overrides used
3.3.2.4	Timestamp
3.3.2.5	The environment. This might end up being optional due to privacy concerns.
3.3.2.6	The user. This might end up being optional due to privacy concerns.
3.3.3	Readable : there must be a known "standard" by which potential reads can read the result – it is in XML, it is to a particular XSD, it is in xHTML / CSV

Number	Requirement	Source Use Case
4	Prove a comparison result
4.1	A comparison must be expressed in a formal way, un-ambiguous way.
4.2	There must be a set of expected results by the author of a comparison.
4.3	There must be a "reference implementation" of a comparison.

Number	Requirement	Source Use Case
5	Publish XBRL instances
5.2	XBRL data must be able to be made available for consumption by others – to "Publish"
5.1	Owners must be able to assert intellectual property rights	Use Case Pool XBRL [POST020] Pools have appropriate controls and access mechanisms.

4. Appendix:

4.1. Abstract domain model [4]

This section describes the domain in terms of the classes, their attributes and their relationships.

This firstly forms the basis of a taxonomy and or data dictionary. It also is the beginning of the process of expressing the Comparability Standard in terms of the XBRL Abstract Model.

4.2. Comparability domain model

Figure 1. Comparability domain model

[1] This and the other diagrams have been developed using the MagicDraw UML tool.

[2] These Use Case definitions were generated using the MagicDraw UML Tool’s report writer.

[3] As At version 1.0 this has yet to be implemented fully.

[4] As at version 0.4 this section is under review by the modeling SME.

[5] This section requires more input to ensure completeness.

Name	Location
[1] XBRL Strategic plan	http://www.xbrl.org/sites/xbrl.org/files/imce/XBRL2010Initiatives.pdf
[2] XBRL Comparability brief	http://xbrl.org/comparability-task-force
[3] XBRL Standards	http://www.xbrl.org/SpecRecommendations/
[4] XBRL Conformance Suites	http://www.xbrl.org/SpecRecommendations/
[5] XBRL Comparability Taskforce Sharepoint site	http://sharepoint.xbrl.org/INT-COMP/default.aspx
[6] MagicDraw Comparability model	The XBRL MagicDraw TeamServer.
[7] This document	http://sharepoint.xbrl.org/INT-COMP/Files/XBRL_comparability_taskforce_report_phase_1.docx
[8] XBRL Comparability White Paper (intro for XBRL Product Managers)	http://sharepoint.xbrl.org/INT-COMP/Files/XBRL%20Comparibility%20whitepaper%20-%202012-01-31.docx

Name	Type	Dependency	Enterprise Activity	Contact point
W3C	· Standards Body	Interoperabiity with XBRL abstract model	Interoperability, integration	….
XBRL Function standard	· Standards bodies · Information comsumers · Information producers	The GI will be a common taxonomy for assertion writers to use as it holds detailed information about an enterprise.	The type of activity of interest e.g. integration, information comparability, information rendering …??
XBRL GL standard		They have a number of existing standards which must be leveraged by XBRL Conformance.
OMG		Their technology must implement the standard.
Vendors
Power users		They have a SEC Comparability project.		IFRS Global Banks
XBRL USA