1 Terminology and Formatting

Terminology used in XBRL frequently overlaps with terminology from other fields. The terminology used in this document is summarised in Table 1.

Table 1

abstract element, bind, concept, concrete element, context, Discoverable Taxonomy Set (DTS), duplicate items, duplicate tuples, element, entity, equal, essence concept, fact, instance, item, least common ancestor, linkbase, period, taxonomy, tuple, unit, taxonomy schema, child, parent, sibling, grandparent, uncle, ancestor, XBRL instance, c-equal, p-equal, s-equal, u-equal, v-equal, x-equal, minimally conforming XBRL processor, fully conforming XBRL processor.

As defined in [XBRL].

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	Conforming documents and consuming applications are required to behave as described; otherwise they are in error.

Taxonomy

The word taxonomy refers to an XBRL taxonomy as it is defined in the XBRL 2.1 specification [XBRL]. For the purposes of this document a taxonomy represent the whole DTS rooted at that taxonomy schema file.

Core taxonomy

Normally it refers to a taxonomy that is at the bottom of a set multiple other taxonomies that work together for a particular reporting environment. It may also be a taxonomy that is used in multiple countries. The IFRS taxonomy for example could be seen as the CORE taxonomy of the reporting for one specific country.

Taxonomy User, User

People that will use the taxonomy to produce instance documents (manually or via mapping tools) or private taxonomy extensions.

Software Developers

People that will use the new taxonomy version to produce or adapt software that uses a previous taxonomy version.

Assurers

Entities providing assertions or assurance that a taxonomy is appropriate for the domain, or a particular purpose within that domain.

Version 0

The first initial release of a taxonomy. It may not contain any versioning metadata.

Version n

Any particular release of a taxonomy in the version chain.

Version n-x

Any particular release previous to the version n release of a taxonomy, where x indicates the n^th previous version in sequence.

Version n+x

Any particular release subsequent to the version n release of a taxonomy, where x indicates the n^th previous version in sequence.

Delta

A particular delta is the metadata in whatever format unspecified in this document that holds the difference between two consecutive taxonomy versions.

The following highlighting is used for non-normative examples in this document:

Non-normative editorial comments to be removed from final recommendations are denoted as follows:

IHR: This highlighting indicates editorial comments about the current draft, prefixed by the editor’s initials.

Italics are used for rhetorical emphasis only and do not convey any special normative meaning.

2 Design Principles

Id	Principle	Meaning
P1	Consistency	XBRL concepts and terminology should be used to describe the solution. In particular, versioning components should be described using XBRL related technologies as taxonomies, linkbases, XLink, XML Schema and others.
P2	No redundancy	The solution should not require instances, schemas or linkbases to encode the same information in multiple places.
P3	Simplicity	The solution must not include features for which there is no documented need.
P4	Priority	An implementation of these requirements must not violate the most current edition of the XBRL 2.1 specification.
P5	Usability	It must be possible to implement the solution in software in a user friendly manner for both: the taxonomy authors who want to create new versions of their taxonomies and for instance document authors who must adapt their systems to produce documents according to new the new taxonomy versions. If something in the design were in conflict between the two groups defined above the point of view that should prevalence is the one that gives more simplicity to the instance document authors.
P6	Compatibility	The solution SHOULD be compatible with current XBRL Taxonomies and Taxonomies that are using XBRL modules that are based on XBRL technology, such as the Dimensions Specification 1.0 and the Formula Linkbase Specification.

3 Functional Requirements

Id	Text	Use cases
V1	It MUST be possible to create a taxonomy that is version n+1 of another taxonomy that will be the version n	All of them
V2	Two taxonomies that are version n and version n+1 MUST be automatically recognized in their correct position in the versioning chain.	All of them
V3	There MUST be no limitations to changes between version n and version n+1 in a taxonomy version chain.	All of them
V4	If MUST be possible to add documentation metadata to any particular change. That documentation MAY have multiple fields like author names, dates, generic documentation in short, large format etc.	All of them
V5	It MUST be possible for taxonomy users (creators, maintainers of the taxonomy or people responsible for mapping the taxonomy to internal systems) to review the changes from version n to version n+1.	All of them
V6	Prohibition of concepts. In version n+1 of a taxonomy it MUST be possible to invalidate the usage of concepts defined in version n of the taxonomy. Instance document validators implementing the versioning module of XBRL MUST signal an error when prohibited concepts were used. IHR: This requirement may be implemented using the new formula linkbase. See V10.	All of them. Explicit references in A.4, A.5, A.7, A.9, A.10, A.11 and A.12.
V7	Taxonomy authors MUST be able to specify additional metadata that is part of the taxonomy version like version numbers, author names, email addresses URIs etc. That metadata may not be related to any particular change.	All of them.
V8	It MAY be possible to specify a validity period for concepts defined in a taxonomy. The usage of those concepts in a context that is out of that period should be considered as an error. IHR: This requirement may be implemented using the new formula linkbase. See V10.	A.2, A.4, A.5, A.6, A.7, A.8, A.9, A.10, A.11 and A.12
V9	A concept defined in a taxonomy version n+1 can be related to and, if so, MUST be documented as a concept defined in taxonomy version n. The relationship between the concepts MUST be documented using standard roles. Possible roles are: Same concept: The two concepts are the same, but exist in different namespaces and may have different IDs element names and or labels. Remapping of concepts that are declared as they are “the same concept” should be done automatically by mapping engines that are “versioning aware” if the user indicates to apply all possible automatic changes. Concept split: This arc role links a concept from taxonomy version n to a set of concepts defined in Taxonomy version n+1. The concept defined in taxonomy version n may be declared as a prohibited concept (According to V6 above). Note that the “set of concepts” may in part or in whole already exist in the Taxonomy version n. This may or may not be an automatic change in mapping engines. Concept collapse: Multiple concepts from taxonomy version n will be reported with one concept in taxonomy version n+1. Note that the “multiple concepts” may in part or in whole already exist in version n. Concept disappears: support concept prohibition as defined in V6 above.	All of them.
V10	It SHOULD be possible to indicate a standard formula defined in taxonomy version n+1 to help moving and/or validating instance documents from taxonomy version n to taxonomy version n+1.	A.1, A.2, A.7, A.8, A.9, A.10, A.11 and A.12
V11	It MUST be possible to include in the versioning metadata the changes in XML schema components that are not part of the XBRL 2.1 spec. This includes addition or changes to attributes defined in other XBRL modules, changes in data types etc.	A.3, A.7, A.8, A.9, A.10, A.11 and A.12

4 Technical requirements

T1	The specification must include a conformance suite and the requirement that there be two or more independent implementations correctly and consistently (between the two or more implementations) processing that conformance suite.
T2	The solution SHOULD be scalable. Therefore it SHOULD NOT require that the Taxonomy version n be part of the DTS of the Taxonomy version n+1.
T3	It SHOULD be possible to build Taxonomy version n+1 with just the Taxonomy version n and the versioning metadata from n to n+1 versions of the same taxonomy.

5 Out of scope requirements

Some of the use cases include requirements that are not input to the Specification Working Group to develop the specification document. The document author has collected those requirements here because they may be part of best practices or guidelines to Jurisdictions and organizations responsible of developing and maintaining XBRL taxonomies.

O1	Information about taxonomy changes SHOULD be communicated to taxonomy users as early as possible.
O2	Comparing two taxonomy extensions of a base taxonomy
O3	Comparing two different base taxonomies

A. Applications of XBRL taxonomy versioning

There are multiple applications of taxonomy versioning. In this section there is a description of some of those applications in a manner that could be understood by business and technical people.

The application description has been edited by the document author in order to make easy to read the document from the beginning to the end.

Some of the software applications described in this document may not be available in the market. They have been introduced because an application with that functionality may exist in the future or as a consequence of the functionality described in this document.

A.1 Communication of changes to a taxonomy

Contributed by: Trevor Pyman (Trevor@pyman.com.au)

Description:

A taxonomy describes the shared understanding of concepts within a domain, such that instance documents of fact values can be created and disseminated in a manner that requires no interaction between preparer and consumer other than the transmission and receipt of the instance document itself.

When a taxonomy is altered there are five things present:

1. an original taxonomy;

2. a changed taxonomy (either a completely new taxonomy or one capable of creation from the original taxonomy plus the delta changes);

3. an authoritative entity responsible for the change;

4. a reason for the change; and

5. stakeholders affected by the change.

The purpose of this application is to describe the requirements of the stakeholders affected by a change to a taxonomy where these 5 things are present.

The stakeholders affected by a change include:

· Taxonomy users;

· Software developers;

· Assurers.

Requirements

1.	Taxonomy builders MUST be able to supply sufficient and appropriate information to allow taxonomy users or software vendors to determine the impact of the changes for the taxonomy users Taxonomy builders MUST be able to supply sufficient and appropriate information to allow taxonomy users to determine - which can also be worded as ‘explain’ or communicate - the impact of the changes in the taxonomy on the different types of users. Changes have different impacts on different types of users. Correcting a typographical error in a taxonomy can mean that the taxonomy needs to be ‘refreshed’ in a software application but does not need to be remapped. It is not (always) possible to automate the assessment of a change; you need people who do the actual assessment. The taxonomy authors in general know who the users of their taxonomy are and what a change in taxonomy really means. If there is a mechanism that a taxonomy author can use to communicate the level of impact to users, this is a way to include people assessment. It should be possible that software developers use this mechanism to translate the level of impact to the different types of users.	V1, V2, V3, V4, V5, V7, V9
2.	Sufficient appropriate information MUST be supplied to software developers to allow them to assess the impact on the users of their software of the change to the taxonomy. Software developers need to make the transition from one taxonomy to another version of it as seamless as possible for their users. The entity releasing the new version of a taxonomy cannot predict the impact on any particular software application so they must provide as much information as possible about the change and the reasons for it, so that software developers can assess the impact for themselves. The amount and type of information provided cannot be formalised as it will depend upon the circumstances in each case. Changes may or may not require any action by software developers or the users. New elements will almost always require some action by software developers to advise the users of the new element, the reason for its existence, and a series of recommended steps users should take to address the new element (e.g. a “wizard” to set up the element within the system to populate data against it). Removal of elements is also highly likely to require action to remove any usage of the elements within the applications. These changes are obvious and from here we enter the “grey area” where changes are made. A change considered irrelevant for one stakeholder may be considered critical by another. The entity most capable of assessing the impact of the change is the affected stakeholder, so such decisions should be left to them. In order to make an effective decision, full information must be provided. The same principle applies here as well – information considered trivial by one stakeholder could be crucial to another, so decisions on what is, or is not, important enough for communication with the changed taxonomy should not be made. ALL information at the disposal of the taxonomy publisher should be disclosed with the changed taxonomy.	V1, V2, V3, V4, V5, V7, V9
3.	Sufficient appropriate information MUST be supplied to Assurers to allow them to assess the impact on the assertions they have made in respect of the original taxonomy and to make new assertions in respect of the changed taxonomy. In some cases a domain may require that assertions are made by an appropriately qualified entity as to the appropriateness of a taxonomy for use by stakeholders in that domain. Where such a taxonomy is changed, the requirement for the assertion/assurance remains and so the assurers must have sufficient appropriate information to determine the effect on their assertions. For example, an error has been discovered in the original taxonomy that may or may not render an assertion invalid, or the underlying authority for the taxonomy (or any of its elements) has changed such that continued use of the original taxonomy is inappropriate and consequently any assertion that it is an appropriate taxonomy for certain uses may need to change. Also, an assertion may need to be made in respect of the changed taxonomy and so the assurers will need to have sufficient appropriate information to be able to form an assessment of the changed taxonomy in respect of the assertions they need to make. Again, it is not possible to predict what assertions will be requested or required in respect of taxonomies, and by whom, so what is sufficient appropriate information will depend upon the circumstances.	V1, V2, V3, V4, V5, V7, V9
4.	The information provided in respect of a change to a taxonomy MUST be objective and general in nature - i.e. not intended or focussed on any particular, or group of, software applications. What constitutes sufficient appropriate information depends upon the circumstances in each case. However at the very least it should not be biased or skewed in any way toward a particular group or scenario. Broad and generalised information need not lack detail. It is also possible, in fact probable, that information in respect of specific applications and circumstances can be more detailed than for others. Provided as much detail as possible is provided for as many circumstances as possible, without the deliberate omission of any particular group or scenario, then the requirement will have been met.	V1, V2, V3, V4, V5, V7, V9
5.	To the extent practical, the means of communicating the details of the change should be automated. It is recognised that not all information in relation to a change is capable of being communicated automatically to a consuming application. Some information can only be effectively understood by a human who must then apply judgement in making any changes to consuming applications. However, the intent of the versioning requirements is to support the goal of requiring the absolute minimum of human intervention in the change process. If a change can be communicated in such a way that consuming applications can be aware of the change and the impact upon the users without human intervention, then it should be communicated this way.	V10
6.	Information should be communicated to affected stakeholders as early as possible. There is nearly always a lead time between understanding the impact of a change and the implementation of required changes to applications as a result of that change. In some cases quite a significant lead time. To smooth the transition from one taxonomy to the next version of it, information about the change and reasons for it should be communicated to affected stakeholders as soon as is practical after this information becomes known with certainty.	O1

A.2 Dealing with instances of multiple taxonomy versions

Contributed by: Walter Hamscher (walter@hamscher.com)

Two scenarios describe the situation that may be the real use case in one company using XBRL to communicate the Financial Statements to stakeholders. The first test case is the most simple one because it does not include taxonomy extensions from the company side.

In this test case the string Tv(n) means taxonomy version n, Iq(n)v(m) means instance of quarter (n) according to taxonomy version (m), and Te(n)v(m) means taxonomy extension version (n) as an extension of taxonomy version (m).

This use case covers the issues regarding how to create new instances for taxonomy Tv2 from data in instances using taxonomy Tv0 and Tv1.

Description

A plausible sequence of events occurring in, say, the SEC VFP:

1. Party A publishes Taxonomy Tv0.

2. Party B publishes instance Iq1v0 using Tv0.

3. Party B publishes the next quarter's instance Iq2v0 using Tv0.

4. Party B institutionalises a roll-forward process for making next quarter's instance Iq3v0 using Tv0.

5. Party A publishes a new Taxonomy version Tv1.

6. Party B needs to publish next quarter's instance Iq4v1.

Party B's tool need to be updated to use Tv1

Party B's instances Iq1v0, Iq2v0 and Iq3v0 need to be

· migrated to Tv1 or;

· generated again from scratch using new mappings.

The first option (migration) may be of use by people that have stored a copy of Iq1v0 locally. The second option may be less powerful because only the original author of the document is able to create a new version.

Requirements

In addition to generic requirements V5, V9 and V10 may be particularly useful in this situation.

Migration of local copies of data between different taxonomy versions may require access to additional internal information not disclosed in Iq1v0, Iq2v0 and Iq3v0 by Party B. Also, the migration of local copies of instances would generate other kind of data inconsistencies.

The already published documents Iq1v0, Iq2v0 and Iq3v0 are all valid according to the taxonomy Tv0 that was the taxonomy selected by Party B at that time.

In the process of Party B making a decision to adopt Tv1 the following requirements may help:

V5 helps the Party B to review the impact of the taxonomy changes and decide about when and how the new taxonomy will be adopted.

V9 should help Party B to identify the strategy for adoption element by element in case it is necessary.

V10 should help Party B in the following two processes:

a) Moving Iq1v0, Iq2v0 and Iq3v0 to Iq1v1, Iq2v1 and Iq3v1 respectively. Setting up the Formula engine in XBRL Instance Production mode, the data of instances based on Tv0 could be converted and new required information could be added from external sources.

b) Validating the new instances against the new Taxonomy version and possible validity periods established in V8.

Description

Here is a more realistic and more complex scenario:

· Party A publishes Taxonomy Tv0.

· Party B publishes instance Iq1e0 using Te0v0 (Te0 is an extension of Tv0).

· Party B publishes the next quarter's instance Iq2e1 using Te1v0 (Te1 is another extension of Tv0).

· Te1v0 has delta versioning metadata from Te0v0.

· Party B institutionalises a roll-forward process for making next quarter's instance Iq3e1 using Te1v0.

· Party A publishes Taxonomy Tv1.

· Party B has a short window of time to publish next quarter's instance Iq4e1.

Party B's tool need to be updated to use Tv1, a new taxonomy extension Te0v1 should be created and the process has to be as simple as possible.

Requirements

In addition to requirements indicated in the requirements section above, taxonomy extension Te1v0 should be moved to Te0v1. Some of the changes may be automatic and some others may not.

The following procedure may help solving the issues of creating Te0v1:

· compare the concepts defined in Te1v0 with the concept tracking history from Tv0 to Tv1

- Examine concept splits - are new concepts defined in Tv1 defined in Te1v0? If so then Te0v1 will not contain that concept.

- Examine concept collapses - are concepts defined in Te1v0 affected by a concept collapse? If so then manual intervention should be required.

- Examine new concepts out of splits and collapses and compare with concepts defined in Te1v0.

- Examine concept prohibitions. - are concepts defined in Te1v0 affected by a concept prohibition? If so, then manual intervention is required.

- In theory, for the concepts that are marked as “same concept” between Tv0 and Tv1 according to V9 above, the new Taxonomy Te0v1 can automatically copy all arcs and concept definitions from Te1v0.

This process is just a hint for tools implementing taxonomy mapping. The effective requirement behind this application is V5 in combination with requirements V1, V2, V3, V4 and V7.

A.3 Documenting changes in dimensional taxonomies

Contributed by: Ignacio Hernández-Ros (ihr@xbrl.org)

Description

Dimensional taxonomies are a new functional module of XBRL developed by the Specification Working Group. Dimensional taxonomies utilize XBRL technologies (taxonomies, linkbases and arc roles defined in the LRR) to create elements and relationships between elements that define multidimensional structures. The Dimensional Taxonomies Specification 1.0 also defines some new attributes under its own namespace that appear on standard arc elements and XBRL elements defined in the XBRL 2.1 Specification. An example is the xbrldt:targetRole attribute that may appear on definitionArc elements.

As with many other XBRL taxonomies, dimensional taxonomies are subject to taxonomy life cycle and taxonomy maintenance. Taxonomies will appear in the market and will be maintained by organizations. Those changes may have an impact on running systems and software applications that produce instance documents.

People responsible for reporting using tools producing XBRL instances according to a dimensional taxonomy may need to migrate those systems to produce instances according to new versions of the dimensional taxonomy.

The DTS of dimensional taxonomies follow the same rules defined for non-dimensional taxonomies in the XBRL 2.1 Specification.

Requirements

New XBRL modules will be implemented using XML technology. The modification, addition or removal of the attributes specifically created for the dimensional specification shall be part of the versioning requirements. The xbrldt:contextElement attribute, for example, defines the context container (segment or scenario) in which the user must fill in the dimensions and dimension values. A change in this attribute will have an impact on software producing XBRL instances.

The requirement V11 is particularly useful to be able to maintain taxonomies that use XBRL modules.

A.4 Analyse the impact of changes in the base taxonomy on taxonomy extensions

Contributed by: Marc van Hilvoorde (vanHilvoorde.Marc@kpmg.nl)

Description

A taxonomy extension is built as an extension of base taxonomy. The following types of relationships may exist if changes are made to the base and/or extension taxonomies:

Starting position (Root of the DTS under versioning):

· Extension taxonomy, version m

· Base taxonomy, version n

[1] After a change in the base taxonomy:

· Extension taxonomy, version m (still uses Base taxonomy, version n)

· Base taxonomy, version n+1

[2] After a change in the extension taxonomy:

· Base taxonomy, version n

· Extension taxonomy, version m+1 (still uses Base taxonomy, version n)

[3] After a change in the base and extension taxonomy

· Base taxonomy, version n+1

· Extension taxonomy, version m+1

What are the effects of these changes for (re)mapping of the taxonomies and the rendering and validation of instances?

Examples of use cases are:

· A general GAAP taxonomy (base) is extended by local GAAP requirements (extension). Due to changes in accounting rules a new GAAP taxonomy version is published;

· A general GAAP taxonomy (base) is extended by corporate requirements (extension). Due to changes in accounting rules a new GAAP taxonomy version is published;

· A general GAAP taxonomy (base) is extended with a Definition linkbase and Formula linkbase business rules (extensions) for audit purposes. Due to changes in accounting rules a new GAAP taxonomy version is published;

Requirements

Each one of the three use cases are examined here.

In case [1] the base taxonomy is changed but the taxonomy extension is not. The DTS that is discovered starting with the taxonomy extension includes the old version of the base taxonomy. If the base taxonomy cannot be part of new instances it is necessary to update taxonomy extension m to use taxonomy base n+1.

In case [2] the base taxonomy is the same and there are only changes in the taxonomy extension. A DTS discovery starting at the new taxonomy extension should discover the base taxonomy which is okay.

Case [3] may be expanded into different use cases but the most relevant one is when taxonomy extension version m+1 uses taxonomy version n:

If base taxonomy version n should no longer be used then taxonomy extension version m+1 should be updated to taxonomy extension version m+2 and changes should include the migration to use taxonomy base n+1

General requirements about documenting and reviewing the changes between two versions of the same taxonomy apply in this use case: V1, V2, V3, V4, V5, V6, V7, V8, V9.

A.5 The evolution of a concept over the time

Contributed by: John Turner (john.turner@corefiling.com)

Description

· The concept appears in one taxonomy version

· The concept changes in different taxonomy versions

o References, typos, minor changes

o The concept collapses – split into multiple concepts.

· The concept dies

Requirements

General requirements about documenting and reviewing the changes between two versions of the same taxonomy apply in this use case: V1, V2, V3, V4, V5, V6, V7, V8, V9.

A.6 Validating the items according to time periods

Contributed by: Michele Romanelli (michele.romanelli@bancaditalia.it)

Description

Suppose you have a taxonomy Tv0 with the following concepts:

v0:TotalAssets

v0:AssetsComponent1

v0:AssetsComponent2

and a calculation linkbase with the following relationship:

v0:TotalAssets = v0:AssetsComponent1 + v0:AssetsComponent2

Suppose the business context changes at 1^st of July 2005 so that “AssetsComponent2” is replaced by a new “AssetsComponent3”

We could create a new version of our taxonomy Tv1:

v1:TotalAssets

v1:AssetsComponent1

v1:AssetsComponent3

and we can create the following relationship in the calculation linkbase:

v1:TotalAssets = v1:AssetsComponent1 + v1:AssetsComponent3

Suppose a regulator has an exchange agreement with a sender such that the sender must send the regulator an annual report containing four occurrences (one for each quarter) for “TotalAssets” and its components.

In the described scenario, the sender can build the following instances:

Instance1

Item	2005-03-31	2005-06-30	2005-09-30	2005-12-31
v0:TotalAsset	80	100	150	200
v0:AssetsComponent1	70	20	50	70
v0:AssetsComponent2	10	80	100	130

Instance2

Item	2005-03-31	2005-06-30	2005-09-30	2005-12-31
v1:TotalAsset	90	110	160	210
v1:AssetsComponent1	70	20	50	70
v1:AssetsComponent3	20	90	110	140

Instance3

Item	2005-03-31	2005-06-30	2005-09-30	2005-12-31
v0:TotalAsset	80	100
v0:AssetsComponent1	70	20
v0:AssetsComponent2	10	80
v1:TotalAsset			160	210
v1:AssetsComponent1			50	70
v1:AssetsComponent3			110	140

All the previous instances are “formally valid” according to the referenced DTS.

However, from a business viewpoint it happens that:

1. instance1 is wrong because “AssetsComponent3” should not exist before 1^st July 2005

2. instance2 is wrong because “AssetsComponent2” is not valid after 30^th June 2005

3. instance3 is valid according to the business scenario.

In our opinion, it is good to have a XBRL validator able to assert the validity only for instance3.

All of us agree that instances are “time dependent”; we deem it important to also consider concept definitions as a sort of “time dependent” objects. This way it becomes possible to properly describe (and understand, and check) instances at each referenced time.

We do not like to talk about technical solutions to this problem at the current phase of the versioning work; however, a little example could (hopefully) clarify what we mean.

Suppose that the Versioning spec standardizes two new arcroles: “start-date” and “end-date” whose meaning is to state the validity period of a concept.

In this situation one could build the following taxonomy:

v1:TotalAssets (start-date/end-date = forever)

v1:AssetsComponent1 (start-date/end-date = forever)

v1:AssetsComponent2 (start-date= 0; end-date=2005-06-30)

v1:AssetsComponent3 (start-date=2005-07-01; end-date=forever)

v1:TotalAssets = v1:AssetsComponent1 + v1:AssetsComponent2 + v1:AssetsComponent3

The corresponding instance document could be:

Instance4

Item	2005-03-31	2005-06-30	2005-09-30	2005-12-31
v1:TotalAsset	80	100	160	210
v1:AssetsComponent1	70	20	50	70
v1:AssetsComponent2	10	80
v1:AssetsComponent3			110	140

Requirements

A validator “versioning aware” could make use of the suggested dates on each concept definition to correctly validate the instance4. V8

A.7 Maintaining a core taxonomy

Contributed by: Eric Cohen (eric.e.cohen@us.pwc.com)

Description

A new taxonomy version of a core taxonomy (about 3.000 elements) has to be created. The changes will be reviewed by hundreds of people worldwide - some will create new versions of their own taxonomies using taxonomy extensions of the core taxonomy and others will have to create new instances according to the new taxonomy.

It is desirable to reduce the amount of work for people who will use the new taxonomy version n and have previously worked with the previous taxonomy version n-1. The work includes mapping existing data items from taxonomy version n-1 to the new taxonomy version n, or creating instance documents with the new taxonomy version n.

Requirements

V1, V2, V3, V4, V5, V6, V7, V8, V9, V10, V11.

A.8 Publishing corrections to taxonomy

Contributed by: Eric Cohen (eric.e.cohen@us.pwc.com)

Description

A taxonomy that has been recently approved and put in production has to be changed because a sign has been found incorrectly defined in a calculation linkbase. A correction is urgently needed.

Requirements

V1, V2, V3, V4, V5, V7, V8, V9, V10, V11.

A.9 Maintaining a public taxonomy extension

Contributed by: Eric Cohen (eric.e.cohen@us.pwc.com)

Description

The country of Youthanasia has created an extension (version n-1) to core taxonomy version n-1. New elements have been added, labels have been overridden and presentation links have been prohibited. A year later, version n of the core taxonomy has been created. The Youthanasia Domain WG needs to evaluate core taxonomy version n to see if any; new elements overlap with their extension taxonomy version n-1 new elements, items have disappeared, other changes affect the elements that they touched in their own extension version n.

Requirements

V1, V2, V3, V4, V5, V6, V7, V8, V9, V10, V11.

A.10 Maintaining a private taxonomy extension

Contributed by: Eric Cohen (eric.e.cohen@us.pwc.com)

Description

Megacola Corporation has prepared its 10Qs and 10K using the US GAAP C&I taxonomy (version n-1) with corporate extensions (version n-1) for both 10Q and 10K purposes.

XBRL US has now delivered version n of the C&I taxonomy. Megacola Corporation needs tools to analyze both its own extensions (how to best incorporate customizations used for the 10Qs into its 10K) and then analyze the new C&I's (version n) ramifications on its 10Q and 10K extensions."

Requirements

V1, V2, V3, V4, V5, V6, V7, V8, V9, V10, V11.

A.11 Maintaining an XBRL International taxonomy

Contributed by: Eric Cohen (eric.e.cohen@us.pwc.com)

Description

The XBRL GL Working Group has implemented a minor change to the COR taxonomy necessitated by the realization that an important element needs to be deeper into the hierarchical structure for the most efficient data representation. (NB: This is a theoretical situation only.) When the accounting and business application development community gets the latest taxonomy, they need tooling to highlight the changes in the taxonomy.

Requirements

V1, V2, V3, V4, V5, V6, V7, V8, V9, V10, V11.

A.12 Comparing two taxonomy versions

Contributed by: Eric Cohen (eric.e.cohen@us.pwc.com)

Description

An Auditor is performing an assurance engagement on Megacola Corporation and needs a handy tool to assure that the impact of changes made to XBRL US taxonomy version n have been properly reflected in Megacola’s changes to its extension taxonomy (version n-1 to n).

Requirements

V1, V2, V3, V4, V5, V6, V7, V8, V9, V10, V11.

B. References (non-normative)

[EXCELV]	IASCF XBRL Team
	Detailed documentation about implications of a change in a taxonomy. Internal Working Group Draft.
	http://finance.groups.yahoo.com/group/XBRL-Domain/files/Current%20Projects%20%2A%2A%2A/Versioning/2005-08-12%20Versioning%20Matrix.xls

[RFC2119]	Scott Bradner
	Key words for use in RFCs to Indicate Requirement Levels, March 1997
	http://www.ietf.org/rfc/rfc2119.txt

[XBRL]	Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis.
	Extensible Business Reporting Language (XBRL) 2.1 Recommendation with corrected errata to 2005-04-25.
	http://www.xbrl.org/SpecRecommendations/

C. Intellectual Property Status (non-normative)

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).

D. Acknowledgements (non-normative)

The participants in the XBRL International Domain Working Group contributed to this document. The XBRL International Domain Working Group is chaired by Josef Macdonald (IASB) and vice chaired by Marc van Hilvoorde (KPMG). We also thank the following people for their comments and suggestions: Makoto Koizumi (Fujitsu), John Turner (CoreFiling).

E. Document History (non-normative)

Date	Editor	Summary
2005-07-18	IHR		First draft of document prepared.
2005-08-03	IHR		Incorporated editorial changes Expanded the requirement V03 to clarify the ideas.
2005-08-09	IHR		Incorporated suggestions from MvH
2005-09-05	IHR		Some changes in the wording plus answers to comments from Walter Hamsher.
2005-09-18	IHR		Incorporated most of the corrections from Homer Bradford review. Added IASCF references.
2005-12-01	IHR		Incorporated new applications of Versioning. Changed the document name to taxonomy life cycle.
2006-01-20	IHR		Third edition, applications moved to Appendix 1. Overall document changes.
2006-01-25	IHR		Incorporated editorial changes from Jim Richards. Added a new column in the functional requirements table to reference the use cases.

F. Errata corrections incorporated in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Domain Working Group up to and including 2005-11-07. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

Erratum number	Brief description and link(s) to relevant discussion thread(s)	Affected section(s)	Date Correction Approved by the DWG

There are no errata at this time for this Draft Public Working Draft.

	Stage (* - Current)	Party responsible for decision	Decision	Revisions needed	Target date for decision
1	Internal WD	SWG	Recommend for Stage 2	Stay in Stage 1	2005-07-31
2	Internal WD pending publication	ISC	Approve for Stage 3	Return to Stage 1	2006-02-20
3*	Public WD under 45 day review	WD Editors	Minor revisions – to Stage 4	Major revisions, Restart Stage 1
4	Draft Candidate Recommendation	SWG	Recommend for Stage 5	Restart Stage 3
5	Candidate Recommendation	ISC	Approve for Stage 6	Restart Stage 4
6	Recommendation

Walter Hamscher	walter@hamscher.com	Standard Advantage / PricewaterhouseCoopers
Masatomo Goto	mg@fla.fujitsu.com	Fujitsu Limited
Marc van Hilvoorde	vanHilvoorde.Marc@kpmg.nl	KPMG
Eric Cohen	eric.e.cohen@us.pwc.com	PricewaterhouseCoopers
Josef Macdonald	jmacdonald@iasb.org.uk	IASCF