GL Taxonomy Framework Technical Architecture 1.0
Recommendation dated 2007-04-17
Corresponding to XBRL 2.1 Recommendation 2003‑12‑31 with Corrected Errata 2006-12-18 and the XBRL Global Ledger Framework Recommendation dated 2007-04-17

Copyright © XBRL International 2006/7. All Rights Reserved. 

This version:
	GLTFTA-REC-2007-04-17.rtf
is NORMATIVE. All other versions and formats are non-normative.

Editors
Name	Contact	Affiliation	
Jeff Fedor	Jeff.fedor@gmail.com	InDimensions Systems Inc.	
Hugh Wallis	hughwallis@xbrl.org	XBRL International	
Contributors
Name	Contact	Affiliation	
Eric E. Cohen	eric.e.cohen@us.pwc.com	PricewaterhouseCoopers	
George Farkas	gfarkas@xbisoftware.com	XBI Software	
Gianluca Garbellotto	gg@iphix.net	Iphix	
Masatomo Goto	mg@us.fujitsu.com	Fujitsu Laboratories Of America, Inc.	
Diane Mueller	diane@justsystems.com	Justsystems Canada	
Nobuyuki Sambuichi	n-sanbuichi@hitachi-system.co.jp	Hitachi Systems and Services, Ltd.	
Abstract
This document describes the technical architecture of journal focussed taxonomies using the eXtensible Business Reporting Language [XBRL] – commonly known as XBRL-GL.  The recommended architecture establishes rules and conventions that assist in comprehension, usage and performance among different journal focussed taxonomies.  
This document assumes use of the XBRL 2.1 Specification.
Status
This is a Recommendation whose circulation is unrestricted. Recipients of this document are invited to submit to the editor their questions and comments, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Table of Contents
Editors
Contributors
Abstract
Status
Table of Contents
Table of Tables
Table of Figures
Table of Examples
1.	Introduction
1.1	Scope of the architecture
1.2	Terminology and document conventions
2.	The structure of the GL Taxonomy Framework
2.1	Requirements/Motivation
2.2	Structure
2.3	Namespaces
2.4	Content models
2.5	Control over the modification of content models
2.6	Directory structure
3.	How to create extensions within the GL Taxonomy Framework
3.1	Public extensions
3.2	Private extensions
Appendix A.	References (non‑normative)
Appendix B.	Intellectual Property Status (non‑normative)
Appendix C.	Document history and acknowledgments (non‑normative)
Appendix D.	Errata corrections incorporated in this document
Table of Tables
Table 1.  Terminology used in this document.
Table 2. Namespaces defined by the XBRL-GL Taxonomy Framework
Table of Figures
Figure 1. High level conceptual view of the taxonomy framework
Figure 2. Comparison of two different "compiled" versions
Figure 3. Folder structure for the GL Taxonomy Framework
Table of Examples
Example 1. "Palette" schema (gl-plt-2006-10-25.xsd) that imports the COR schema
Example 2.  Fragment of the COR schema (gl-cor-content-2006-10-25.xsd) that contains content model declarations and imports the BUS, MUC and USK module schemas
Example 3.  Fragment of the COR schema (gl-cor-2006-10-25.xsd) that contains the element declarations
Example 4.  Fragment of the COR schema (gl-cor-content-2006-10-25.xsd) that contains content model declarations and imports only the BUS module schema
Example 5.  entryDetail content model declaration in the COR schema (gl-cor-content-2006-10-25.xsd) that does not reference any other modules
Example 6.  entryDetail content model declaration in the COR schema (gl-cor-content-2006-10-25.xsd) that references the BUS module
Example 7.  entryDetail content model declaration in the COR schema (gl-cor-content-2006-10-25.xsd) that references the BUS and MUC modules

1.	 Introduction
1.1	Scope of the architecture
This document defines the technical architecture of the XBRL GL taxonomy. It is strictly limited to aspect related to the organisation of the technical artefacts (schemas, linkbases etc.) and does not address any issues related to how the concepts defined in the taxonomy should be used or applied.
1.2	Terminology and document conventions
Terminology used in XBRL frequently overlaps with terminology from other fields.
Table 1.  Terminology used in this document.
Architecture	“The fundamental organization of a system embodied by its components, their relationships to each other and to the environment and the principles guiding its design and evolution.  This definition may just as usefully be applied to technical architecture” [IEEE].  
This document describes in the form of design rules the organization of journal-focussed reporting taxonomies embodied by schemas, linkbases, concepts, links, and other components, their relationships to each other and to financial reporting standards, and principles that justify the design rules both for base taxonomies and for the extensions that will inevitably follow.  
Contrast this with the IEEE definition of Software Engineering: “A systematic approach to developing, using, maintaining and liquidating systems;” this document does not cover approaches to development, use, maintenance or liquidation of taxonomies.	
abstract element, ancestor, base set, bind, child, concept, concrete element, context, duplicate items, duplicate tuples, element, entity, essence concept, fact, fully conforming, instance, item, least common ancestor, linkbase, minimally conforming, parent, period, sibling, taxonomy, taxonomy schema, tuple, unit	As defined in XBRL 2.1 specification. 	
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.	

DTS	Discoverable Taxonomy Set  As defined in XBRL 2.1 specification.	
base DTS
extension DTS	An extension DTS is a DTS that is a proper superset of a base DTS.  Because an extension must be a proper superset, a DTS is not an extension of itself.	
extended-type link	As defined by the XML Linking Language [XLINK].  XBRL linkbases are made up of extended-type links.	
GLTFTA	GL Taxonomy Framework Technical Architecture: the set of rules described in this document.	
LRR	Link Role Registry.  An online listing of XLink role and arc role attribute values that MAY appear in XBRL International acknowledged and approved taxonomies, along with structured information about their purpose, usage, and any intended impact on XBRL instance validation [LRR].	
Module	An XBRL International recommendation that depends on XBRL and defines the syntax and semantics of additional elements, attributes, roles or arc roles that cannot be defined entirely within an XBRL valid taxonomy.	
Persisting DTS (persisting extension)	A DTS whose purpose is to be stored as files to be referenced by instances of multiple entities and published in some fashion for users to examine.  This contrasts with a DTS that is ephemeral—for example, dynamically created while processing instances, only to be discarded.  	
source	The source of an arc is the element indicated by the “from” attribute.	
target	The target of an arc is the element indicated by the “to” attribute.	
Taxonomy status:
Acknowledged	

Approved	

Recommended	

	This is non‑normative; see the Taxonomy Recognition Process [TRP]:
Acknowledged: XBRL International recognizes that the taxonomy is technically in compliance with all appropriate specifications.
Approved: In addition to being Acknowledged, XBRL International warrants that the taxonomy was developed in an open fashion and it complies with all best practices for compatibility.
Recommended:  In addition to being approved, XBRL International singles out a Recommended taxonomy as being the one preferred for a given type of reporting.  Financial reporting taxonomies are not expected to achieve this status from XBRL International since it is not the custodian of the financial reporting standards themselves.  	
version control	A version control system maintains an organized set of all the versions of files that are made over time. Version control systems allow people to go back to previous revisions of individual files, and to compare any two revisions to view the changes between them.	
XBRL	XBRL 2.1 Recommendation, with corrected errata to 2006-12-18 [XBRL].	
XBRL valid	XML instances and schemas that satisfy the syntax requirements of XBRL.	
The following highlighting is used for non-normative examples in this document:
	
The following highlighting is used for non-normative counterexamples in this document:
	
Non-normative editorial comments are denoted as follows and removed from final recommendations:
HW: 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.	The structure of the GL Taxonomy Framework
2.1	Requirements/Motivation
The XBRL GL taxonomy framework has been designed to support all the constructs that were provided by the XBRL 2.0 and 2.0a compliant versions of the taxonomy but using the 2.1 version of the XBRL Specification [XBRL]. XBRL GL requires a highly tuple based taxonomy architecture. The way in which XBRL 2.1 supports this is significantly different from that in which XBRL 2.0 and 2.0a supports it. In the previous versions of the specification the content model of tuples was defined by means of constructs in the definition linkbase. In version 2.1 the XML Schema [SCHEMA-1] content modelling mechanism is employed for this purpose. This creates a new challenge when it comes to extensibility of a tuple’s content model since such extensibility is not well supported in XML Schema and thus an architecture that permits this is necessary.
2.2	Structure
The architecture employed to support the requirements stated in the previous section requires a set of interrelated schema documents that when assembled or compiled together form, with the associated linkbases, of course, an XBRL taxonomy. Diagrammatically this can be represented thus:

GL-COR

GL-MUC

GL-BUS

GL-USK

GL-BUS

GL-USK

XBRL GL

Element declarations only

Content Model declarations only

import

import

GL-MUC

GL-TAF

include

GL-TAF

include

include

include

include

GL-COR

Figure 1. High level conceptual view of the taxonomy framework

Each box in the above diagram represents one schema file. This framework allows for the element declarations of the elements in each module of the framework to remain fixed but the content models to be extensible. The element declaration schema files are not valid schemas in their own right but are included (by means of an <include>) in the content model declaration files which, together, form a valid schema. The various content model files also import (by means of an <import>) other namespaces as appropriate where they need to in order to reference elements from those namespaces.

Tying it all together is a “palette” schema (marked XBRL GL in Figure 1) that does nothing more than <import> the appropriate version of the GL-COR schema for the application for which this is being used.

To better understand this consider two examples presented here side by side:

GL-COR

GL-MUC

GL-BUS

GL-USK

include

include

include

include

XBRL GL

import

import

import

GL-COR

GL-BUS

include

include

GL-BUS

XBRL GL

import

import

GL with cor, muc, bus, usk, taf

GL with cor, bus

complexType definitions and import (not include) statements may be different.

GL-TAF

include

GL-MUC

GL-COR

GL-BUS

GL-USK

GL-TAF

import

import

GL-COR

Figure 2. Comparison of two different "compiled" versions

The first (leftmost) of these shows how a taxonomy that uses elements from four modules (COR, MUC, BUS and USK) is compiled: the second (rightmost) shows how a taxonomy that uses elements from just two of the modules (COR and BUS) is compiled.

The naming convention is that the schema files that contain the content model declarations are named gl-cor-content-2006-10-25.xsd, gl-muc-content-2006-10-25.xsd etc., those that contain the element declarations are named gl-cor-2006-10-25.xsd, gl-muc-xsd etc. The file containing the “palette” schema is gl-plt-2006-10-25.xsd

Some XML code fragments might make this clearer.

Example 1. "Palette" schema (gl-plt-2006-10-25.xsd) that imports the COR schema
<schema
  targetNamespace="http://www.xbrl.org/int/gl/plt/2006-10-25"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified"
  xmlns="http://www.w3.org/2001/XMLSchema">
  <import namespace="http://www.xbrl.org/int/gl/cor/2006-10-25" schemaLocation="gl-cor-content-2006-10-25.xsd"/>
</schema>	
Example 2.  Fragment of the COR schema (gl-cor-content-2006-10-25.xsd) that contains content model declarations and imports the BUS, MUC and USK module schemas
<schema
  targetNamespace="http://www.xbrl.org/int/gl/cor/2006-10-25"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified"
  xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:xbrll="http://www.xbrl.org/2003/linkbase"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:xbrli="http://www.xbrl.org/2003/instance"
  xmlns:gl-cor="http://www.xbrl.org/int/gl/cor/2006-10-25"
  xmlns:gl-bus="http://www.xbrl.org/int/gl/bus/2006-10-25"
  xmlns:gl-muc="http://www.xbrl.org/int/gl/muc/2006-10-25"
  xmlns:gl-usk="http://www.xbrl.org/int/gl/usk/2006-10-25">
  <import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/>
  <import namespace="http://www.xbrl.org/int/gl/bus/2006-10-25" schemaLocation="gl-bus-content-2006-10-25.xsd"/>
  <import namespace="http://www.xbrl.org/int/gl/muc/2006-10-25" schemaLocation="gl-muc-content-2006-10-25.xsd"/>
  <import namespace="http://www.xbrl.org/int/gl/usk/2006-10-25" schemaLocation="gl-usk-content-2006-10-25.xsd"/>

  <include schemaLocation="../../cor/gl-cor-2006-10-25.xsd"/>

...
Complex type definitions for elements in the version of the COR module that requires elements from the BUS, MUC and USK schemas
...

</schema>	

Note that in Example 2 there is an <include> that brings in the element definitions for the elements whose content models are defined in this schema.
Example 3.  Fragment of the COR schema (gl-cor-2006-10-25.xsd) that contains the element declarations 
<schema elementFormDefault="qualified" xmlns:xbrll="http://www.xbrl.org/2003/linkbase" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.xbrl.org/int/gl/cor/2006-10-25" attributeFormDefault="unqualified" xmlns:xbrli="http://www.xbrl.org/2003/instance" xmlns:gl-cor="http://www.xbrl.org/int/gl/cor/2006-10-25" xmlns:gl-gen="http://www.xbrl.org/int/gl/gen/2006-10-25">
  <annotation>
    <appinfo>
      <xbrll:linkbaseRef xlink:type="simple" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="gl-cor-presentation.xml" xlink:title="Presentation Links, all" xlink:role="http://www.xbrl.org/2003/role/presentationLinkbaseRef"/>
      <xbrll:linkbaseRef xlink:type="simple" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="gl-cor-label.xml" xlink:title="Label Links, all" xlink:role="http://www.xbrl.org/2003/role/labelLinkbaseRef"/>
    </appinfo>
  </annotation>
  <import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/>
  <import namespace="http://www.xbrl.org/int/gl/gen/2006-10-25" schemaLocation="../gen/gl-gen-2006-10-25.xsd" />

...
Element declarations for elements in the COR module
...

</schema>	

Note that in Example 3 the references to the relevant linkbases (presentation and label) are present since they are independent of the content model for the elements. Only the element declarations are present - there is no content model defined for the elements. As a consequence, this schema file is not a valid schema in its own right – it is simply a necessary part of the whole schema for the COR namespace that gets incorporated into the complete namespace definition as a result of being <include>d as in Example 2 and Example 4.

The <import> of the namespace http://www.xbrl.org/int/gl/gen/2006-10-25 defined in gl-gen-2006-10-25.xsd should be noted here. This contains type definitions that are used in various modules and which MUST NOT be altered by anyone extending the taxonomy (see section 2.5 for further explanation).

Example 4.  Fragment of the COR schema (gl-cor-content-2006-10-25.xsd) that contains content model declarations and imports only the BUS module schema
<schema elementFormDefault="qualified" xmlns:xbrll="http://www.xbrl.org/2003/linkbase" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.xbrl.org/int/gl/cor/2006-10-25" attributeFormDefault="unqualified" xmlns:xbrli="http://www.xbrl.org/2003/instance" xmlns:gl-cor="http://www.xbrl.org/int/gl/cor/2006-10-25" xmlns:gl-bus="http://www.xbrl.org/int/gl/bus/2006-10-25">
  <import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/>
  <import namespace="http://www.xbrl.org/int/gl/bus/2006-10-25" schemaLocation="gl-bus-content-2006-10-25.xsd"/>

  <include schemaLocation="../../cor/gl-cor-2006-10-25.xsd"/>

...
Complex type definitions for elements in the version of the COR module that requires elements from the BUS schema
...

</schema>	

Note in Example 4 how the <import> of the MUC and USK modules is not present (compare with Example 2).
2.3	Namespaces
This section enumerates and describes the namespaces used in the GL Taxonomy Framework. Except where indicated these namespaces will be modified by those extending the taxonomy if they need to extend the content models of elements declared in those namespaces. The rules governing what types of modifications are permitted are given in section 3 below.
Table 2. Namespaces defined by the XBRL-GL Taxonomy Framework
Namespace	Recommended prefix	Description	
http://www.xbrl.org/int/gl/gen/2006-10-25	gl-gen	Defined in gl-gen-2006-10-25.xsd. This namespace contains type definitions that MUST NOT be changed by anyone extending the taxonomy. No elements are defined in this namespace.	
http://www.xbrl.org/int/gl/bus/2006-10-25	gl-bus	Defined in gl-bus-2006-10-25.xsd and gl‑bus-content-2006-10-25.xsd. This namespace contains element declarations and content model definitions that are relevant to the BUS module of the XBRL-GL taxonomy.	
http://www.xbrl.org/int/gl/cor/2006-10-25	gl-cor	Defined in gl-cor-2006-10-25.xsd and gl‑cor-content-2006-10-25.xsd. This namespace contains element declarations and content model definitions that are relevant to the COR module of the XBRL-GL taxonomy.	
http://www.xbrl.org/int/gl/muc/2006-10-25	gl-muc	Defined in gl-muc-2006-10-25.xsd and gl‑muc-content-2006-10-25.xsd. This namespace contains element declarations and content model definitions that are relevant to the MUC module of the XBRL-GL taxonomy.	
http://www.xbrl.org/int/gl/plt/2006-10-25	gl-plt	Defined in gl-plt-2006-10-25.xsd. This is the targetNamespace of the palette taxonomy defined in gl-plt-2006-10-25.xsd. There are no elements of types defined in this namespace and, as such, it does not serve any particular purpose except to provide a targetNamespace for the palette schema document.	
http://www.xbrl.org/gl/int/taf/2006-10-25	gl-taf	Defined in gl-taf-2006-10-25.xsd and gl‑taf-content-2006-10-25.xsd. This namespace contains element declarations and content model definitions that are relevant to the TAF module of the XBRL-GL taxonomy.	
http://www.xbrl.org/int/gl/usk/2006-10-25	gl-usk	Defined in gl-usk-2006-10-25.xsd and gl‑usk-content-2006-10-25.xsd. This namespace contains element declarations and content model definitions that are relevant to the USK module of the XBRL-GL taxonomy.	

2.4	Content models
The schema files that contain the content models (gl-cor-content-2006-10-25.xsd etc.) will differ depending on which modules are in use for the specific application. The differences are in which other namespaces are <import>ed and in the content models themselves. The content models are defined in type declarations and the set of type declarations will not change (as they are simply the types for the elements that are declared in the element declaration schema files and those do not change), only the actual content models themselves will change.
The following 3 examples show how one complex type declaration (entryDetailComplexType, which defines the content model for the gl-cor:entryDetail element) varies depending on which modules are in use.
Example 5.  entryDetail content model declaration in the COR schema (gl-cor-content-2006-10-25.xsd) that does not reference any other modules
  <complexType name="entryDetailComplexType" id="gl-cor_entryDetailComplexType">
    <complexContent>
      <restriction base="anyType">
        <sequence>
          <element minOccurs="0" ref="gl-cor:lineNumber"/>
          <element minOccurs="0" ref="gl-cor:lineNumberCounter"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-cor:account"/>
          <element minOccurs="0" ref="gl-cor:amount"/>
          <element minOccurs="0" ref="gl-cor:signOfAmount"/>
          <element minOccurs="0" ref="gl-cor:debitCreditCode"/>
          <element minOccurs="0" ref="gl-cor:postingDate"/>
          <element maxOccurs="unbounded" minOccurs="0" 
                          ref="gl-cor:identifierReference"/>
          <element minOccurs="0" ref="gl-cor:documentType"/>
          <element minOccurs="0" ref="gl-cor:invoiceType"/>
          <element minOccurs="0" ref="gl-cor:documentNumber"/>
          <element minOccurs="0" ref="gl-cor:documentApplyToNumber"/>
          <element minOccurs="0" ref="gl-cor:documentReference"/>
          <element minOccurs="0" ref="gl-cor:documentDate"/>
          <element minOccurs="0" ref="gl-cor:postingStatus"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-cor:xbrlInfo"/>
          <element minOccurs="0" ref="gl-cor:detailComment"/>
          <element minOccurs="0" ref="gl-cor:dateAcknowledged"/>
          <element minOccurs="0" ref="gl-cor:confirmedDate"/>
          <element maxOccurs="1" minOccurs="0" ref="gl-cor:shipFrom"/>
          <element minOccurs="0" ref="gl-cor:shipReceivedDate"/>
          <element minOccurs="0" ref="gl-cor:maturityDate"/>
          <element minOccurs="0" ref="gl-cor:terms"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-cor:taxes"/>
        </sequence>
        <attribute name="id" type="ID"/>
      </restriction>
    </complexContent>
  </complexType>	

Example 6.  entryDetail content model declaration in the COR schema (gl-cor-content-2006-10-25.xsd) that references the BUS module
  <complexType name="entryDetailComplexType" id="gl-cor_entryDetailComplexType">
    <complexContent>
      <restriction base="anyType">
        <sequence>
          <element minOccurs="0" ref="gl-cor:lineNumber"/>
          <element minOccurs="0" ref="gl-cor:lineNumberCounter"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-cor:account"/>
          <element minOccurs="0" ref="gl-cor:amount"/>
          <element minOccurs="0" ref="gl-cor:signOfAmount"/>
          <element minOccurs="0" ref="gl-cor:debitCreditCode"/>
          <element minOccurs="0" ref="gl-cor:postingDate"/>
          <element minOccurs="0" ref="gl-bus:amountMemo"/>
          <element minOccurs="0" ref="gl-bus:allocationCode"/>
          <element maxOccurs="unbounded" minOccurs="0" 
                          ref="gl-cor:identifierReference"/>
          <element minOccurs="0" ref="gl-cor:documentType"/>
          <element minOccurs="0" ref="gl-cor:invoiceType"/>
          <element minOccurs="0" ref="gl-cor:documentNumber"/>
          <element minOccurs="0" ref="gl-cor:documentApplyToNumber"/>
          <element minOccurs="0" ref="gl-cor:documentReference"/>
          <element minOccurs="0" ref="gl-cor:documentDate"/>
          <element minOccurs="0" ref="gl-bus:documentReceivedDate"/>
          <element minOccurs="0" ref="gl-bus:documentChargeReimb"/>
          <element minOccurs="0" ref="gl-bus:documentLocation"/>
          <element minOccurs="0" ref="gl-bus:paymentMethod"/>
          <element minOccurs="0" ref="gl-cor:postingStatus"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-cor:xbrlInfo"/>
          <element minOccurs="0" ref="gl-cor:detailComment"/>
          <element minOccurs="0" ref="gl-cor:dateAcknowledged"/>
          <element minOccurs="0" ref="gl-cor:confirmedDate"/>
          <element maxOccurs="1" minOccurs="0" ref="gl-cor:shipFrom"/>
          <element minOccurs="0" ref="gl-cor:shipReceivedDate"/>
          <element minOccurs="0" ref="gl-cor:maturityDate"/>
          <element minOccurs="0" ref="gl-cor:terms"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-bus:measurable"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-bus:jobInfo"/>
          <element maxOccurs="unbounded" minOccurs="0" 
                          ref="gl-bus:depreciationMortgage"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-cor:taxes"/>
        </sequence>
        <attribute name="id" type="ID"/>
      </restriction>
    </complexContent>
  </complexType>	

Note the inclusion of references to element declarations in the gl-bus namespace (in bold) in Example 6.

Example 7.  entryDetail content model declaration in the COR schema (gl-cor-content-2006-10-25.xsd) that references the BUS and MUC modules
  <complexType name="entryDetailComplexType" id="gl-cor_entryDetailComplexType">
    <complexContent>
      <restriction base="anyType">
        <sequence>
          <element minOccurs="0" ref="gl-cor:lineNumber"/>
          <element minOccurs="0" ref="gl-cor:lineNumberCounter"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-cor:account"/>
          <element minOccurs="0" ref="gl-cor:amount"/>
          <element minOccurs="0" ref="gl-muc:amountCurrency"/>
          <element minOccurs="0" ref="gl-muc:amountOriginalExchangeRateDate"/>
          <element minOccurs="0" ref="gl-muc:amountOriginalAmount"/>
          <element minOccurs="0" ref="gl-muc:amountOriginalCurrency"/>
          <element minOccurs="0" ref="gl-muc:amountOriginalExchangeRate"/>
          <element minOccurs="0" ref="gl-muc:amountOriginalExchangeRateSource"/>
          <element maxOccurs="unbounded" minOccurs="0" 
                          ref="gl-muc:amountOriginalExchangeRateComment"/>
          <element minOccurs="0" ref="gl-muc:amountOriginalTriangulationAmount"/>
          <element minOccurs="0" ref="gl-muc:amountOriginalTriangulationCurrency"/>
          <element minOccurs="0" 
                          ref="gl-muc:amountOriginalTriangulationExchangeRate"/>
          <element minOccurs="0" 
                          ref="gl-muc:amountOriginalTriangulationExchangeRateSource"/>
          <element minOccurs="0" 
                          ref="gl-muc:amountOriginalTriangulationExchangeRateType"/>
          <element minOccurs="0" ref="gl-muc:originalTriangulationExchangeRate"/>
          <element minOccurs="0" ref="gl-muc:originalExchangeRateTriangulationSource"/>
          <element minOccurs="0" ref="gl-muc:originalExchangeRateTriangulationType"/>
          <element minOccurs="0" ref="gl-cor:signOfAmount"/>
          <element minOccurs="0" ref="gl-cor:debitCreditCode"/>
          <element minOccurs="0" ref="gl-cor:postingDate"/>
          <element minOccurs="0" ref="gl-bus:amountMemo"/>
          <element minOccurs="0" ref="gl-bus:allocationCode"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-muc:multicurrencyDetail"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-cor:identifierReference"/>
          <element minOccurs="0" ref="gl-cor:documentType"/>
          <element minOccurs="0" ref="gl-cor:invoiceType"/>
          <element minOccurs="0" ref="gl-cor:documentNumber"/>
          <element minOccurs="0" ref="gl-cor:documentApplyToNumber"/>
          <element minOccurs="0" ref="gl-cor:documentReference"/>
          <element minOccurs="0" ref="gl-cor:documentDate"/>
          <element minOccurs="0" ref="gl-bus:documentReceivedDate"/>
          <element minOccurs="0" ref="gl-bus:documentChargeReimb"/>
          <element minOccurs="0" ref="gl-bus:documentLocation"/>
          <element minOccurs="0" ref="gl-bus:paymentMethod"/>
          <element minOccurs="0" ref="gl-cor:postingStatus"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-cor:xbrlInfo"/>
          <element minOccurs="0" ref="gl-cor:detailComment"/>
          <element minOccurs="0" ref="gl-cor:dateAcknowledged"/>
          <element minOccurs="0" ref="gl-cor:confirmedDate"/>
          <element maxOccurs="1" minOccurs="0" ref="gl-cor:shipFrom"/>
          <element minOccurs="0" ref="gl-cor:shipReceivedDate"/>
          <element minOccurs="0" ref="gl-cor:maturityDate"/>
          <element minOccurs="0" ref="gl-cor:terms"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-bus:measurable"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-bus:jobInfo"/>
          <element maxOccurs="unbounded" minOccurs="0" 
                          ref="gl-bus:depreciationMortgage"/>
          <element maxOccurs="unbounded" minOccurs="0" ref="gl-cor:taxes"/>
        </sequence>
        <attribute name="id" type="ID"/>
      </restriction>
    </complexContent>
  </complexType>	

Note the inclusion of references to element declarations in both the gl-bus (in bold) and the gl-muc (in bold-italic) namespaces in Example 7.

2.5	Control over the modification of content models
The architecture described here provides different levels of control over the ability of those who may wish to extend the base taxonomy in how they may or may not modify content models. There are three levels of control that naturally result from this architecture as follows:
2.5.1	Modification prohibited at any level
There are a few content models (which are defined as XML Schema types. e.g. documentTypeItemType) of general utility which are unchangeable by anyone who wishes to extend the taxonomy. These are defined in the schema file gl-gen-2006-10-25.xsd in the namespace http://www.xbrl.org/int/gl/gen/2006-10-25. Since they are defined here they MUST NOT be modified by anyone extending the taxonomy. By being included in this namespace these types become available for use unmodified throughout the entire taxonomy. 
2.5.2	Modification permitted only by authors of new modules
Some content models are not of general utility but are specific to particular modules. However, the author of the module may wish to prevent their being altered by anyone further extending the taxonomy or adding a new module. In this case they can be defined in the element definition schema relevant to that module (e.g. gl-xxx-2006-10-25.xsd for the XXX module) rather than in the content module schema (e.g. gl-xxx-content-2006-10-25.xsd for the XXX module). Since they are defined here they MUST NOT be modified by anyone extending the taxonomy. By being included in this namespace these types become available for use unmodified in any extension that references the module in question.
2.5.3	Modification permitted by taxonomy extenders
In many cases the content models of both items and tuples may be such that the taxonomy author anticipates they will need to be modified as part of some taxonomy extension performed by someone else. Typical situations of this kind would be the addition of new possibilities to an enumerated list or modifications of the content model of a tuple such as those exemplified in section 2.2 above. In this case the type declaration that defines the content model will be placed in the relevant gl‑xxx‑content-2006-10-25.xsd file which MAY be modified by anyone extending the taxonomy provided they follow the rules for extending taxonomies defined in section 3 below.
2.6	Directory structure

Figure 3. Folder structure for the GL Taxonomy Framework

Figure 3 shows the folder structure for the GL Taxonomy Framework. It is important to maintain this structure and to follow its pattern when extending the taxonomy so as to be able to resolve relative references to the various components of the taxonomy. The 6 folders (bus, cor, gen, muc, taf and usk) each contain 3 files (except for gen where there is only the schema file) named gl-xxx-2006-10-25.xsd, gl-xxx-2006-10-25-label.xml and gl‑xxx-2006-10-25‑presentation.xml where xxx is the same 3 characters as the name of the folder itself. These files are the element declarations (and unchangeable content model declarations if any) and the label and presentation linkbase for the module XXX.

Under the plt folder are a series of sub-folders each named case followed by a series of single characters separated by a “-”. The single characters are used to identify which modules are brought together to form a complete taxonomy. Which one of these to use (i.e. which combination of modules) will be determined by the functionality that is required by the user of the taxonomy. In each of these sub folders are the file gl-plt-2006-10-25.xsd and a set of content model schema files named gl-xxx-content-2006-10-25.xsd (where xxx is the 3 character code for the module in question). Thus, for example, the files in the case-c-b-m folder are gl-plt-2006-10-25.xsd, gl-cor-content-2006-10-25.xsd, gl-bus-content-2006-10-25.xsd, and gl-muc-content-2006-10-25.xsd.

3.	
How to create extensions within the GL Taxonomy Framework
The mechanism for creating extensions within this framework, while utilising the extensibility features built into the XBRL Specification, requires additional steps from those normally followed when creating extensions to monolithic taxonomies because of the modular nature and compilation based architecture employed. As such, taxonomy building software tools MAY implement assistance for this workflow to assist those seeking to create extensions. If support is not built into such tools then a manual process using XML (or simply text) editing software will be necessary.

As experience is gained with building such extensions and with the use of this taxonomy in general, a set of rules and restrictions related to the building of extensions will become apparent and will be codified either in this document or elsewhere (still to be determined).
3.1	Public extensions
A public extension is a new module that is intended to be incorporated into the published framework and become part of that framework. It will typically be created by XBRL International although, since it is anticipated that other organisations might seek to create such extensions and submit them to XBRL International for inclusion in the framework, the process is documented here. 

The steps involved in creating a public extension are as follows (note that in the following xxx is the 3 character code for the module being created, yyyy-mm-dd is the desired publication date for the module):

1.	Select a palette taxonomy (gl-plt-2006-10-25.xsd) and the all the gl-xxx-content-2006-10-25.xsd content model declaration schemas from one of the provided combinations, choosing the combination that most closely resembles the desired end product of the exercise.
2.	Create a new subdirectory of “plt” (called case-x-y-z where x, y and z, and additional letters if necessary, represent the modules involved) and copy these files into this directory.
3.	Create a new taxonomy representing the module you wish to create, add concept definitions and create linkbases. Note that complexType definitions must be defined as global complexTypes. If the tool has the capability, save the element declarations     and the complexType definitions into separate files in separate directories (i.e., as..\..\xxx\gl-xxx-yyyy-mm-dd.xsd and .\gl-xxx-content=yyyy-mm-dd.xsd), save the linkbase files into the directory ..\..\xxxx and go to step 8, otherwise save them in the same file .\gl-xxx-yyy-mm-dd.xsd and proceed to perform steps 4-7 manually.
4.	Separate the taxonomy into gl-xxx-yyyy-mm-dd.xsd and gl-xxx-content-yyyy-mm-dd.xsd with the former containing the element declarations and the latter the content model declarations that are relevant to the new module.
5.	Create the directory ..\..\xxx and move gl-xxx-yyyy-mm-dd.xsd and the linkbase files into that directory
6.	Add an <include> statement in gl-xxx-content-yyyy.mm-dd.xsd to include gl-xxx-yyyy-mm-dd.xsd
7.	Change all necessary relative paths in the linkbase files and the gl-xxx-yyyy-mm-dd.xsd schema file.
8.	Edit each gl-xxx-content-yyyy-mm-dd.xsd in the palette directory as necessary to incorporate any concepts from the new module into the appropriate content models (this will usually be content models for elements declared in gl-cor-content-yyyy-mm-dd.xsd).
9.	Ensure that presentation links in the newly created presentation linkbase reflect the content model modifications made in step 8.

3.2	Private extensions
A private extension is one that is for use in a closed system and not published generally. Different mechanisms, rules and restrictions apply than for public extensions. Those seeking to create private extensions should follow the usual XBRL extension process with the following points to note:
1.	Changes to XBRL International owned namespaces MUST ADD elements from the private extension taxonomy into the content models defined in the palette taxonomy that is being extended.
2.	Changes to XBRL International owned namespaces MUST NOT remove any elements from the content models defined in the palette taxonomy that is being extended.
3.	Private extensions MUST NOT alter any of the officially supplied palette directories. i.e., any changes to XBRL International namespaces MUST be effected in a palette directory that is newly created for the purpose of the extension. Files from officially supplied palette directories MAY be copied into this new palette directory as necessary.

Appendix A.	References (non‑normative)
[IANA]	IANA country codes.	
	http://www.iana.org/cctld/cctld-whois.htm 	
		
[IEEE]	IEEE Standard 610.12-1990	
	IEEE Standard Glossary of Software Engineering Terminology, IEEE, 1990. 	
	http://www.ieee.org 	
		
[IFRS]	International Financial Reporting Standards (IFRS), 
General Purpose Financial Reporting for Profit-Oriented Entities (GP), 2004‑11‑15, Exposure Draft	
	http://xbrl.iasb.org/int/fr/ifrs/gp/2004-11-15/	
		
[ISO]	International Standards Organisation.	
	ISO 4217 Currency codes, ISO 639 Language codes, ISO 3166 Country codes, ISO 8601 international standard numeric date and time representations.	
	http://www.iso.ch/	
		
[LLLL]	The 'Lectric Law Library.	
	http://www.lectlaw.com/ 	
		
[LRR]	Walter Hamscher (editor), Hugh Wallis	
	XBRL Link Role Registry, Public Working Draft of 2004-11-14	
	http://www.xbrl.org/lrr/ 	
		
[USFR]	US Financial Reporting Taxonomy Framework	
	http://www.xbrl.org/taxonomy/us/TaxonomyFrameworkOverview.htm	
		
[RFC2119]	Scott Bradner	
	Key words for use in RFCs to Indicate Requirement Levels, March 1997	
	http://www.ietf.org/rfc/rfc2119.txt	
		
[RFC2141]	Ryan Moats	
	RFC 2141: URN Syntax	
	http://www.ietf.org/rfc/rfc2141.txt  	
		
[RFC2396]	T. Berners-Lee, R. Fielding, L. Masinter	
	Uniform Resource Identifiers (URI): Generic Syntax	
	http://www.ietf.org/rfc/rfc2396.txt 	
		
[SCHEMA-0]	World Wide Web Consortium. 	
	XML Schema Part 0: Primer.	
	http://www.w3.org/TR/xmlschema-0/	
		
[SCHEMA-1]	World Wide Web Consortium. 	
	XML Schema Part 1: Structures.	
	http://www.w3.org/TR/xmlschema-1/	
		
[SCHEMA‑2]	World Wide Web Consortium.  	
	XML Schema Part 2: Datatypes.	
	http://www.w3.org/TR/xmlschema-2/	
		
[TRP]	Calvert, P. and J. MacDonald	
	XBRL Taxonomy Recognition Process, 28 October 2004	
	http://www.xbrl.org/TaxonomyRecognition/	
		
[XBRL]	Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis.	
	Extensible Business Reporting Language (XBRL) 2.1 Specification with corrected errata dated 2006-12-18.	
	http://www.xbrl.org/SpecRecommendations/ 	
		
[XLINK]	Steve DeRose, Eve Maler, David Orchard	
	XML Linking Language (XLink) Version 1.0.	
	http://www.w3.org/TR/xlink/	
		
[XML]	T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau.	
	Extensible Markup Language (XML) 1.0 (Third Edition)	
	http://www.w3.org/TR/REC-xml/ 	

Appendix B.	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 (http://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 (http://www.xbrl.org/legal).
Appendix C.	Document history and acknowledgments (non‑normative)
This document could not have been written without the contribution of many people. 
2005-05-10	Wallis	First draft of document prepared.	
2005-06-01	Wallis	Added sections, incorporated comments from Cohen	
2005-06-16	Wallis	Updates to deliver Internal Working Draft 	
2005-07-06	Wallis	Added section on creating extensions. Incorporated other updates to prepare for inclusion as part of the XBRL-GL taxonomy submission for “Acknowledged” status	
2006-10-11	Fedor	Updates for Proposed Recommendation version – new dates, namespace updates	
2006-10-25	Wallis/Fedor	Updates for Proposed Recommendation version, updated dates, namespaces, contact information and affiliation for Garbellotto and Mueller and incorporated feedback from Kuo-hua Chou 	
2007-04-17	Wallis	Editorial to reflect RECOMMENDATION status	
Appendix D.	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 GL Working Group (GLWG) up to and including. 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	
Because this is a Recommendation, there are no errata at this time.