XBRL is the acronym used for the eXtensible Business Reporting Language. XBRL allows software vendors, programmers and end users who adopt it as a specification to enhance the creation, exchange, and comparison of business reporting information. Business reporting includes, but is not limited to, financial statements, financial information, non-financial information, general ledger transactions, and regulatory filings such as annual and quarterly financial statements.

XBRL defines XML elements and attributes that can be used to express information used in the creation, exchange, and comparison tasks of financial reporting. This is of particular value in the context of financial reporting where existing electronic documents reporting financial statements are full of numbers and text and only the creators of those documents are sure of what each number really refers to.

XBRL is an acronym for the eXtensible Business Reporting Language. XBRL is not extensible in the way that XML is extensible. XML is extensible in that new tags can be defined. XBRL gives users a fixed set of tags, effectively defining an XML grammar, to construct definitions and to mark up specific facts, but users can extend the universe of XBRL concept definitions by marking up their own dictionaries (taxonomies in the jargon of XBRL) of facts to use themselves and, with luck, for others to use as well.

XBRL is also extensible in that concept definitions can be related to other concept definitions. As a creator of definitions, if I want to set up some definitions of very specific asset classes (eg: "ham sandwiches" and "salad sandwiches", I can relate the definitions of those concepts in my own dictionary (taxonomy) to the definitions provided in another already existing dictionary (taxonomy). For example, "ham sandwiches" and "salad sandwiches" can be related to the "sandwiches" class, as defined by the Earl of Sandwich, should he ever care to do so.

To understand the value of XBRL, one only needs to examine the current state of affairs with electronic reporting by businesses. Perhaps an example is warranted.

My last name is Shuetrim. How do I convey to a computer, or someone with language difficulties, that the text string "Shuetrim" is my name? People can only determine that information given an understanding of English and the words providing context to the text string "Shuetrim".

Most business reports are filled with such facts, distinguishable from each other and recognisable to users only when they have sufficient knowledge and background to interpret information given its context. This kind of context is extremely difficult to work with for computers and it is relatively difficult to work with for people. To assist computers and people, XBRL standardises the way in which context is provided for each fact.

Instead of relying on neighbouring facts for context, XBRL uses an auxiliary document, referred to as a taxonomy. This taxonomy contains concept definitions and the relationships between concepts as the source of context for facts reported using XBRL tags. To understand a fact, users, need only use the XBRL tags for that fact to locate the appropriate definition in a taxonomy.

With facts being able to stand alone and with facts being so recognisable, XBRL facilitates the processes of data extraction from business reports and it facilitates the process of data collation, putting similarly defined facts together for comparison and analysis.

XBRL is not going to solve all of the world's problems. However, it will save you a considerable amount of time and uncertainty if you are trying to extract information from the electronic reports produced by a business in which you do or might have an interest. It can be of benefit whenever a definition needs to be associated with a fact.

More specifically, XBRL requires users to provide a range of attributes along with a specific fact to place that fact in time and to associate it with a specific reporting. These particular pieces of associated information or fact attributes are generally useful when using business reports.

Take a look at the official XBRL web site where a considerable amount of information is provided.

Briefly, following a lot of work by Charlie Hoffman and others, developing a number of prototype specifications through 1999, the American Institute of Chartered Practicing Accountants placed the XBRL 1.0 specification within the public domain on July 31, 2000. This has facilitated the development of business reports using the XBRL standard by people across the globe. A new international organisation, XBRL.org, has now been established to ensure that this specification remains in the public domain (www.xbrl.org), available for adoption by all organisations involved in the financial reporting supply chain.

XBRL.org now has the backing of more than 90 major corporations and regulatory agencies around the globe. These backers have become paid-up members of the organisation. They include the 5 major accounting firms, accounting standards bodies in the US, Europe and Asia, the major software vendors including Microsoft, Oracle, SAP, Sage and Hyperion.

The registered organisation, XBRL.org owns the XBRL specification copyright.

XBRL is in the public domain. People can use the specification to create taxonomies and instance documents and they can use ideas in the specification to come up with different specifications of their own, if they wish.

An unending series of mailing lists have been established to discuss various aspects of XBRL. Most lists are housed on the site groups.yahoo.com. The key lists include:

Additional lists also exist for specific types of discussions, SPEC for specification, STRAT for strategy, DOM for domain - ie development of definitions etc.

Many of these lists can be joined by invitation only. If you wish to join an email list, contact one of the individuals listed on the official XBRL website.

Some limited documentation is available on the official XBRL web site. This FAQ is probably the most detailed set of assistance for general questions about XBRL. The documentation of the XBRL 2.0 specification, available on the XBRL web site, is also fairly handy (read with a strong sense of irony here) if you actually want to create documents that comply with the XBRL specification.

A book called "XBRL Essentials" can be obtained from Amazon.com.

See the Simple examples of XBRL are available at the official XBRL website

Additional examples of XBRL are available at the official Australian XBRL website

Edgar online provides a range of XBRL examples and resources at their XBRL Express site.

XSI have examples available on their web-site, demonstrating the multilingual nature of XBRL.

XBRL is also used by the Australian Prudential Regulation Authority for their statistical data collection from financial institutions.

Each concept definition in XBRL includes one or more human readable labels that can be attached to facts when appropriate (say when producing a report for others to read). The label has a language attribute. By having multiple labels, in different languages, with the appropriate language attributes set, the one report can be presented in a multiplicity of languages, with the XBRL taxonomy of concept definitions effectively acting as a translator.

See the press room and the briefing room on the official XBRL web site.

The best place to find slide presentations and talks on XBRL is to join one of the mailing lists and then browse the various files that have been uploaded over the months and years since those mailing lists were established. There are a number of PowerPoint presentation available from the briefing room on the XBRL web site and also on the XBRL Educational website.

One of the more generic tools for working with XBRL is the text editor. Being XML, is always viewable in a text editor (if you have the right key mapping - recall that XML is based on Unicode mappings, some of which may not work so well on your machine). However, while a text editor can be useful to illustrate concepts, a commercial application should be run through a specialist XBRL tool to create, validate and interpret the XBRL.

Also as XML, XBRL can be worked with using all of the tools available for manipulating XML, such as web browsers and XML parsers and XML Document Object Models etc. This can be very handy when using JavaScript and XSLT to present XBRL data in an attractive fashion on the Internet.

Finally, recalling that XBRL is XML plus some extra extensibility, there is specialist software being developed by many organisations to manipulate and work with the networks of relationships between concept definitions that XBRL allows users to create. See the official XBRL website for more information about tools that can be used with XBRL.

You can join the XBRL community by becoming a member of XBRL.org. More information about joining XBRL can be obtained at the official XBRL web site. Note that membership can be obtained at an international level or within the context of the XBRL jurisdiction that you operate within.

For example, KPMG, a global audit and advisory services firm, is a member of XBRL.org at the international level (and is a member of at least one national jurisdiction). In contrast, an Australian academic is a member of XBRL.org via the the Australian jurisdiction only. Naturally the annual membership fees are a function of resources available to individual members.

XBRL is currently being used in Australia with APRA and similar regulatory filings are expected around the world in 2002. Key applications include financial statement reporting to regulators and the public and collection of financial data from financial institutions for regulatory purposes.

See the official XBRL web site for an up to date list. However, as of the writing of this FAQ, taxonomies have only been developed for the core accounting standards in the US. Germany, Canada, the International Accounting Standards Board, the UK, New Zealand and Australia are not far off.

See the official XBRL web site for an up to date list of XBRL.org members. Over and above those core institutions, an increasingly wide number of institutions are being required to report using XBRL by government regulatory agencies.

See the official XBRL web site for an up to date list of XBRL.org members. All member software organisations have made a commitment to incorporate XBRL capabilities into their products. Moreover, as XBRL leverages XML standards, all software written to work on XML documents will operate on XBRL. This means XBRL can be worked with NOW!

The Australian Prudential Regulation Authority has implemented their entire data collection and distribution system using XBRL standards.

XBRL has, for some time, been evolving rapidly in line with the rate of developments in XML standards more generally. Version 1.0 of the XBRL specification was released to the public for use and comment in the middle of 2000. Subsequent to that release, the adoption of XML Schema and Xlink as recommended standards by the W3C, and feedback by those involved in working with XBRL Specification 1.0, have led to the development of XBRL Specification 2.0. This reworking of XBRL to make better usage of other XML standards and to accommodate more sophisticated XBRL applications is an official recommendation from XBRL.org. XBRL 2.0 was made a recommendation by XBRL.org in December 2001.

Going forward, any changes to the specification will be backward compatible. This backward compatibility will be facilitated by introducing new capabilities in a modular fashion, using X Link linkbases to provide the new markup.

XBRL documents look dramatically different under XBRL 2.0, compared to their appearance under XBRL 1.0. However, conversion of XBRL documents from version 1.0 to version 2.0 can be fully automated using a series of XSLT based transformations.

With the release and recommendation of the XBRL Specification 2.0, the specification of XBRL, the focus of developments has turned to the creation of XBRL taxonomies. Particular effort is being directed toward the formation of the taxonomies for the International Accounting Standards.

XBRL is in the early stages of development and adoption. Widespread adoption for financial and regulatory reporting is anticipated to occur over the next 2 to 5 years. See the official XBRL web site for more details on the current number of XBRL.org members and for more information about the accounting standards that can now be reported for using XBRL.

Yes, in a word.

Yes, in a word. As new XML standards get bedded down by the W3C, XBRL moves to leverage those standards as well. Thus, XML, XML Schema, Xpath, XSLT, and Xlink are standards that XBRL leverages.

The Boston question is perhaps the most commonly asked question about XBRL, especially by those familiar with more traditional uses of XML. At its most succinct, the Boston question is why XBRL does not make greater use of the XML content model. Traditional XML, by enabling users to place data in tree structures, gives tree traversal and manipulation algorithms a data structure that is relatively computationally efficient. Because of the extensibility required of XBRL and because of the requirement that XBRL facts can be reported on their own or in any order, this deep nesting of content in a tree structure is not feasible.

XBRL does, however, facilitate the representation of relationships among concepts. Instead of using the XML tree structure, XBRL uses linkbases to express relationships between concepts. The relationships expressed in these linkbases are slower to process using the current generation of XML tools than are data structures that leverage XML's tree-based data structure.

Thus, XBRL sacrifices performance efficiency, with traditional XML tools to achieve its extreme flexibility. This suggests that XBRL is an effective means of marking up data but for processing and reporting, some intermediate transformations of the data structure may be more effective, depending on the application. It also suggests that XBRL might benefit from the development of tools tailored to XBRL rather than relying on standard XML tools alone that are honed to exploit efficiencies in processing tree data structures.

XML is extensible in the sense that you are free to specify your own mark-up grammar using XML Schema or Document Type Definitions. However, once the grammar has been defined, it is not expected to be extended by others. XBRL however is also extensible in the sense that users can work with the XML grammar for XBRL to add new concepts as required.

Specifically, it is possible for XBRL users to define new XBRL taxonomies. New taxonomies make it possible to report a new set of facts, based on the newly defined concepts.

Note that these additions do not change the syntax of XBRL, ensuring that XBRL compliant processors can work with instance documents independent of the emergence of new XBRL taxonomies.

Given that XBRL is XML compliant, you can get a whole lot done using XML tools for data collation, analysis, and distribution. However, for creation of XBRL taxonomies and XBRL instance documents, manually or from existing accounting systems, XBRL specific applications help a lot. A variety of organisations, listed on the XBRL.org website, are in this space.

No. XML is platform independent (XML documents can be used on all operating systems that support the Unicode system) and thus XBRL is platform independent.

Some are and some are not. Language dependency will in general be inherited from the language used to implement the XBRL tools.

For example, Java, Python and Perl are XML capable languages that can be used on a very wide variety of platforms. On the other hand, Visual Basic is an XML capable language that has a more limited range of supporting operating systems.

The XBRL 2.0 specification is a set of normative rules for how valid XBRL documents (taxonomies and instance documents) are to be written.

The XBRL 2.0 specification was officially recommended by XBRL.org in January 2002.

No. XBRL is based on XML Schema validation. No DTD is flexible enough to describe and circumscribe XBRL.

The appropriate way to validate XBRL is to use XML Schema Validation.

Yes, and no.

More informatively, XBRL is made up of a large number of different types of XML documents: ... more required here ... The XML grammar for XBRL taxonomies is XML Schema. Thus, XBRL instance documents can be validated against their supporting XBRL taxonomies using XML Schema validation. The linkbases supporting XBRL taxonomy schema documents can be validated using two XML Schema documents that define XLink elements for use with XBRL. ... more required here ...

Use XML Schema validation.

XBRL is based on a high level model of the data that it is intended to represent. At a high level, the data model for XBRL is elegantly simple.

The following is somewhat simplified - but it does capture the essence of XBRL. There are two kinds of data, data (also known as facts) and data about data (also known as concepts). All facts are instances of concepts. Concepts can be related, in a wide variety of ways, to other concepts. Facts can be related, using tuples, to other facts, generally indicating that sets of facts are the content of other "higher" level facts. This model is illustrated in ...

The XBRL data model

No. However, there are many individuals and organisations in the XBRL community that perceive a value in using object modelling methods to improve XBRL taxonomy design and representation to improve reusability.

There is no standard, official, free or open source XBRL DOM. However, at least one software vendor has a software library providing an interface to XBRL taxonomy and instance documents at a higher level of abstraction than is provided using standard XML tools.

Down the line, similar interfaces to XBRL documents (taxonomies and instance documents) are likely to be developed for a wide variety of programming environments. No standards are yet in place for the functionality or syntax to be used by these interfaces.

No, unless you are keen to ensure that nobody, other than yourself and those lucky few that know about and implement your extensions, will be able to work with your non-XBRL "taxonomies" and "instance" documents.

To influence the development of the XBRL specification, get your organisation to join the international XBRL.org organisation - see the official XBRL web site for details on how - and then participate actively in the international specification working group.

An XBRL taxonomy is a document or set of documents defining and describing the concepts that can be reported using that taxonomy, according to the XBRL specification. In effect, an XBRL taxonomy contains the data about the data provided in XBRL business reports. The usual terminology for data about data in this age is "Metadata". Thus, XBRL taxonomies are where you should go to find the metadata required to interpret an XBRL business report.

The metadata in XBRL taxonomies has a modular stucture. At the core of the meta data is a list of unique concept identifiers. Various pieces of information are then attached to these identifiers; for example, definitions, labels, derivation rules using other concepts defined in this or other XBRL taxonomies etc.

XBRL was originally developed to facilitate the recording of accounting-based financial statement information in XML. However, it is capable of facilitating XML mark-up of almost any type of fact that does not require additional mark-up to specify its specific value.

That said, it is important not to regard everything as a nail once you have the XBRL hammer in hand. This is because the XBRL flexibility comes at a cost. That cost is the processing work required to manipulate the relatively unstructured XBRL data, relative to XML information that has made greater use of the tree-based XML content model.

An XBRL taxonomy document is a valid instance of an XML Schema document. The XML Schema grammar is used to define various elements, attributes and datatypes required by the XBRL taxonomy.

Each element defined in the XML Schema document corresponds to an XBRL concept.

The data type definitions are required in situations where taxonomy creators find that the standard data types available in the core XML schema document are not sufficient for their purposes.

Attribute definitions are less commonly required in XBRL taxonomies. However, they can be required when taxonomy developers want to define a set of markup that can be validly used within the segment and/or scenario elements in the context elements in instance documents based on the taxonomy.

In addition to these XML Schema definitions, a taxonomy may include definitions of the relations between concepts. The relationships can be between concepts in the same taxonomy or between concepts in different taxonomies. The relationships are expressed using elements that have been defined in special XBRL Schema documents that implement a set of Xlink-compliant linkbases.

An Xlink linkbase is a set of resources, locators and arcs that for unidirectional links between the various resources and locators.

An Xlink linkbase resource is a fragment of XML markup contained within the Xlink linkbase. In the context of XBRL, labels are contained in an Xlink linkbase. Each label is a separate linkbase resource.

<label xlink:type="resource" 
       xlink:label="ias_bs_en"
       xlink:title="ias_bs_en"
       xlink:role="http://www.xbrl.org/linkprops/label/standard"
       xml:lang="en"> 
balance sheet 
</label>

Note that the resource is an element called label. The label element is defined in the XML schema document with namespace "http://www.xbrl.org/2001/XLink/xbrllinkbase". This XML Schema document defines all of the various elements used in the construction of the linkbases required by XBRL.

The label resources has a number of attributes, all in the xlink namespace "http://www.w3.org/1999/xlink". The type attribute is what makes the label element a resource in the linkbase.

The role attribute is equal to a URI that is specific to XBRL. All resources with role attributes that take this value have the same role. For labels, that role is as a standard XBRL concept label.

The title attribute is used to specify a title for the label resource. The use of this title is up to the processing application.

Confusingly, the label element also has a label attribute. The label attribute is in the Xlink namespace and has a completely different purpose to the XBRL label element that contains it. The label attribute is the ID of the label resource that it is used within. All Xlink resources and locators have their own labels. These are used by the arc elements in the linkbase to identify the resources, or the locators, to which they refer.

It is important to make sure that no two XBRL labels, that you do not want to be treated identically by arcs in the linkbase, have the same Xlink label attribute.

The last attribute of the label resource is an attribute in the XML namespace, "http://www.w3.org/XML/1998/namespace". This attribute is used to specify the language of the label resource. It can take on any of the valid xml language values. In the example above, the "en" value indicates that the label is in English.

A linkbase is a fragment of XML markup that relates a number of XML markup fragments. Some of the markup fragments being related are part of the linkbase itself. These are linkbase resources. Some of the fragments being related by the linkbase are external to the linkbase, in other parts of the same XML document or even in other XML documents altogether.

In the context of XBRL, the linkbases are used to define relationships between XBRL concepts and to associate pieces of information (labels and reference information) to those concepts.

To embellish the XBRL concepts (XML Schema element definitions used by XBRL) the linkbases need to references those concepts and they do so using locators. These are simply particular types of elements, defined within the XBRL XML schema document with namespace "http://www.xbrl.org/2001/XLink/xbrllinkbase".

<loc xlink:type="locator" 
     xlink:href="ias.xsd##xpointer(//element[@balanceSheet])"
     xlink:label="ias_balanceSheet"
     xlink:title="bs" />

The "loc" element is used by XBRL to define a locator. It can be recognised as a locator because of the giveaway that the Xlink "type" attribute takes the value "locator".

It identifies the XML Schema element that it locates using the Xlink "href" attribute. That attribute must be given a valid XML Pointer value that identifies the exact XML element that defines the concept being located.

The Xlink "title" attribute is used to specify a title for the locator. The use of this title is up to the processing application.

The Xlink "label" attribute is the ID of the locator. These are used by the arc elements in the linkbase to identify the locators, to which they refer.

At the heart of any XBRL taxonomy is an XML Schema document, This document defines an XML element for each concept in the taxonomy using XML Schema syntax. An example element definition is given below.

<element name="Assets" 
	 type="xbrli:monetaryItemType" 
	 substitutionGroup="xbrli:item" /> 

This element definition defines the element using the XML Schema element tag. That element tag must always have the three attributes shown.

The name attribute defines the name for the element. In the example, this name is "Assets". A human might guess that the concept is associated with facts describing the amount of assets owned by some entity at some point in time.

The rules of XML Schema require that no other concept in this taxonomy can be given the same name. This restriction makes the element name an excellent unique identifier for the concept. As such, you will see it turning up in all sorts of places, much like a foreign key in database tables.

Another part of defining an element in XML Schema involves specifying the data types that are allowed for that element. In other words, what attributes can that element be given, and what PC data values or other tags can it contain? This data type is specified in the "type" attribute of the element tag.

In the example, the data type is specified as "xbrli:monetaryItemType". While you might be willing to take a guess at what this type is (perhaps non-negative real numbers?), to be really confident, you would need to take a look at the XML Schema document defining the monetaryItemType. That XML Schema document can be found using the usual XML namespace rules.

Finally, the element definition includes the less common "substitutionGroup" XML Schema attribute. All elements used to identify concepts in XBRL taxonomies must include this attribute. It can take one of two values:

The item substitution group is used for all concepts where the values associated with the concept are atomistic. For example, assets can take a value of $100. The tuple substitution group is used for all concepts where the values associated with the concept must be represented as a number of other atomistic concept values. For example an address concept might be given a value made up from the values for a street concept, a suburb concept, a post/zip code concept, a state concept and a nation concept.

The XML Schema element definitions for taxonomy concepts can also contain documentation and annotations to assist humans (but not computers) in interpreting the concepts defined therein. These annotations for each concept are generally nested within the element tags defining the concepts.

The XML Schema document at the heart of an XBRL taxonomy can contain a number of "simple" XLink references to supporting XLink linkbase documents.

The linkbase documents, supporting the core XML Schema document provide a flexible and extensible means of hooking a broad range of auxiliary and information onto each of the concepts defined (named and typed) in the core XML Schema document.

For example, linkbases can be created to:

You should definitely take a long look at the XBRL Specification document at the official XBRL web site to fully understand the syntax and power of these supporting linkbases.

Note that linkbases can reference concepts defined in multiple XML Schema documents. This facilitates the kind of taxonomy extension process that allows users to tailor XBRL reporting to their exact requirements without giving up the use of common concept definitions to identify areas of comparability between their XBRL reports and the XBRL reports of others.

Also note that core XBRL taxonomy documents need to define their own XBRL specific markup to express the various Xlink elements and to define the XBRL data types etc. This XBRL grammar is defined in an XML Schema document with the namespace "http://www.xbrl.org/2001/instance". This namespace needs to be declared in any core XML Schema XBRL documents and in XML documents that mark up XBRL facts. It is not, however required by the XBRL linkbase documents. They have their own grammar, defined in another XML Schema document with the namespace "http://www.xbrl.org/2001/XLink/xbrllinkbase".

No. While some prefer the maintainability benefits of separation, there is no reason not to build a single monolithic file representing all information that the taxonomy is intended to convey. really boils down

Note however, that linkbases can be very large files. Moreover, many uses for taxonomies do not draw on all linkbases. For performance reasons, this would suggest that forcing a transfer, parse and analysis of all linkbases by building them into a monolithic taxonomy document is not an optimal approach. However, the choice is yours as a taxonomy builder.

If you are a software vendor, looking to support taxonomy processing, you had better not rely on either monolithic or modular taxonomies. Instead rely on the simple XLinks contained in the core XML Schema taxonomy document to locate the relevant linkbases.

No. However, the more information is provided to assist in interpretation of the concepts defined in a taxonomy, the more useful that taxonomy will be.

Of particular value in this regard are the label and reference linkbases. Some taxonomy creators do leave out the references. However, without the references in place it is difficult to communicate how facts should be constructed for each concept in the taxonomy. Without this communication, it becomes more of a stretch to believe that each report creator using the taxonomy is producing the facts in a way that is consistent with the other report creators using the taxonomy.

At risk of sounding overly enthusiastic, the use of XML Schema for the core XBRL taxonomy document gives XBRL users considerable power to validate their XBRL instance documents, checking that only defined concepts are reported and checking that facts reported have the correct data type etc. By leveraging XML standards like XML Schema, XBRL buys users a whole lot of validation power built into any XML Schema compliant validator.

Note however that XML Schema validation does not guarantee XBRL validation. In the words of David vun Kannon,

XBRL validity is a superset of XML Schema validity. There are some things that the XML Schema language does not have the power to enforce, even if the implementations were perfect. For instance, if XBRL's item and context elements had a simple ID/IDREF relationship, XML Schema could enforce it. Since we use substitution groups and the item element is abstract, XML Schema cannot enforce it.

This limitation means that there is room for new tools to provide the range of checks, beyond XML Schema validation that are necessary to ensure XBRL compliancy.

An XBRL taxonomy is made up from a set of XML documents. The core taxonomy document provides simple XLinks to the supporting linkbases. Thus the core XML Schema taxonomy document and the supporting linkbases can be regarded as a single unit - you get the core document and you can expect to find the supporting linkbases.

Instance documents then only need to identify the core XML Schema taxonomy document or documents that defined the concepts that they report. They do this identification using using XML namespaces. Each core XML Schema taxonomy is given a unique target namespace via its "targetNamespace" attribute.

A namespace is insufficient information for an instance document processor to locate the supporting taxonomy documents. A typical means of providing hints to processors about the location of the supporting taxonomy documents is to use the standard XML Schema Instance attribute:

xsi:schemaLocation="namespace1 URL1 namespace2 URL2 ..."

To use this attribute in an XBRL instance document, it is necessary to declare the XML Schema instance namespace in the instance document using the "xsi" alias to that namespace. This can be done as:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

Note that the value of any schemaLocation attribute will depend upon the accuracy of the URL/s specified. This accuracy can be easily compromised, motivating the use of the schemaLocation attribute as a hint on the taxonomy location rather than as an ironclad guarantee. In general, to be sure that the taxonomy is found, the user's program must recognize its namespace and have the associated taxonomy to hand.

XBRL users can define a concept in a taxonomy to have any simple datatype that can be defined using XML Schema. The XML Schema defining the syntax to be used in defining XBRL taxonomies (this schema is associated with the namespace "http://www.xbrl.org/2001/instance") does some of the leg work required to use these simple XML Schema data types for you. Specifically it defines the following data types for you:

Note that each XBRL fact must have a simple data type (as opposed to a complex data type that involves using XML markup). In other words, you cannot use XML markup to provide structure to the value of a specific fact.

In cases where the value attributable to a given concept can only be a combination of the values attributed to a collection of other concepts, then the concept is given an tupleType. In an instance document tuple-type concepts can only take values that are the combined values of zero or more other XBRL facts.

XML Schema allows new simple data types to be defined as a derivation of built in data types. Such user defined data types can be used to restrict the values that can validly be taken by facts in XBRL instance documents.

Using the same approach as is used in the "http://www.xbrl.org/2001/instance" XML Schema document to define other XBRL item types, it is possible to produce a very wide range of simple types that can be used to validate the content of facts. These can be based on the built in XBRL item types or they can be based on the XML Schema data types directly.

Relationships between concept definitions are defined using XLink relationships. These XLink relationships are always contained in XLink linkbases.

In the XBRL specification 1.0, there was only one type of markup that could be used to express relationships between concepts defined in a taxonomy. These relationships were referred to as rollups.

A rollup was used to express a relationship between the concept definition containing the rollup element and another concept definition in the same or in a related XBRL taxonomy. Most fundamentally, the relationships were from a child concept to a parent concept. The concept definition that contains the rollup was implicitly the child concept in the relationship. The rollup element was required to contain a "to" attribute, whose value took the value of the "name" attribute in the parent concept definition.

Rollups were also described by two other mandatory attributes: the "order" attribute which, by convention only, can be used by processing applications to decide on the order in which the relationships to a given parent concept are to be processed; and the "weight" attribute which, again by convention only, can be used to determine the weight to apply to the values taken by children concepts in instance documents, when attempting to aggregate children concepts to obtain the value of the parent concept.

While mandatory, these two rollup attributes often did not make sense when there was no specific order in which children concepts should be processed or when the children concepts had string types values and thus, parent concept values could not sensibly be derived using addition and subtraction.

These and other problems with rollups were one of the major drivers behind the creation of the XBRL specification 2.0.

With the emergence of the XBRL specification 2.0, rollups have been replaced with the more flexible XLink linkbases. These overcome many of the problems arising with rollups because they do not try to incorporate too much information in a single component of the taxonomy markup. Instead different markup is used to express each different type of relationship. A presentation relationship can be tailored to contain only information relevant to presentation, a calculation relationship can be tailored to the needs involved in expressing addition/subtraction derivation rules between concepts.

The flexibility of linkbase structure eventually led, in the XBRL specification 2.0 to the replacement of the specific label and reference markup in XBRL specification 1.0 with linkbases tailored to labelling and referencing requirements.

Many tools that have been designed to build XBRL taxonomies represent the relationships built into taxonomies using a tree representation. This tree representation restricts the way in which relationships between taxonomy concepts can be used. For example, cycles in the relationships are ruled out by this design limitation in the early XBRL software. If concept A was a parent of concept B then B could not be defined to be a parent of concept A. More interestingly perhaps concept B could not be associated with multiple parents.

This caused early taxonomy developers much anguish because, to work with the XBRL taxonomy development tools they had to define the same concept many times in a taxonomy. This was more work and it reduced the comparability benefits of using XBRL in the first place.

To produce taxonomies where elements have multiple parents, it has been necessary to work outside of the current generation of XBRL software tools for XBRL taxonomy creation. Note however that these kind of complex, non-tree, relationship structures are not ruled out by the XBRL specification. Indeed, with the emergence of linkbases as part of the XBRL specification 2.0, very sophisticated relationship structures between concepts are being encouraged.

You can use any unique XML element name as the XBRL concept name, when defining XBRL taxonomy concepts. The name must only be unique within the namespace of the taxonomy that the concept is defined within. As an interesting aside, note that multiple taxonomies, each with their own namespace can validly be defined in the one document.

Note that there are no restrictions on the length allowed for a concept name string.

One of the earliest conventions adopted for concept names was to build the concept name as a prefix, inherited from the parent element and a suffix, intrinsic to the concept being defined. The prefix and suffix were separated by a full stop. Elements without parents did not have a prefix for their name.

balanceSheet.assets
assets.currentAssets
assets.nonCurrentAssets
currentAssets.cashAndCashEquivalents
etc.

Unfortunately, using this naming convention, elements with more than one parent could not be handled with this naming convention. This did not mean that we could not use define concepts with more than one parent concept. It just meant that a more flexible naming convention was required for taxonomies where some concepts were related to multiple parent concepts.

Yes. Any kind of XLink linkbase relationship between concepts can be used to relate any pair of concepts in one or more taxonomies. Whether this makes sense is another matter.

This questions deserves clarification. Using letters in place of concept identifiers, consider two linkbases, 1 and 2:

Linkbase 1 defines the values of B and C as contributing to the value of A, while linkbase 2 defines the values of D and E as contributing to the value of A.

If both linkbases are available to an XBRL instance document processor, nothing in the specification prevents A from being derived as B+C+D+E. To ensure that A is derived as either B+C or D+E, some additional XBRL infrastructure is required.

Specifically, B and C require calculation links indicating that they contribute to the value of some new concept, say BC and D and E require calculation links indicating that they contribute to the value of some new concept, say DE. By then defining equivalency relationships, BC is-a A and DE is a A, then XBRL processors stand a reasonable chance of avoiding the doublecounting trap.

For those defining such processors, however, note that there are many ways for taxonomy designers to express the relationships above. The DE concept could be omitted and the calculation links for D and E could continue to connect to A. Symmetry suggests yet a third option. Moreover, an is-a relationship could also be defined between concept BC and concept DE, if the taxonomy designer was feeling enthusiastic at the time. Traversing these arcs with consistency and completeness will require a fair amount of concentration, to say the least.

A reasonable starting point is provided by XFront.com.

A reasonable starting point is provided by Roger Costello at XFront.com.

Yes. Tuples are defined as elements in taxonomy schema documents and can be referenced from within linkbases in a manner identical to that used for items.

Note that tuples do not make sense in all taxonomy linkbases. In particular, they do not make sense in calculation linkbases. However, it is most appropriate, to attach labels and reference information defining the information that tuples are intended to convey using taxonomy linkbases.

An XBRL instance document is an XML data structure, meeting the XBRL specification and reporting a set of facts. At a more basic level, an XBRL instance document contains the actual facts of a business report, where each fact is marked up in a manner that associated it with a given XBRL taxonomy concept.

The markup for each fact also references a variety of contextual information that indicate how each fact is to be interpreted. The context describes the key features of the fact (who reported it, the period to which the information pertains, etc.).

Context information is provided for XBRL facts using context elements. There are two types of context elements, "numericContext" and "nonNumericContext". Which type of context is used depends on the datatype of the fact being reported.

Both context types, require facts to be given context about:

In addition, the numericContext must provide contextual information specifying:

The "closed world assumption", is a part of the context associated with numeric facts in instance documents. An example of the markup for the closed world assumption is shown below.

<numericContext id="context123" cwa="true" precision="7">
...
</numericContext>

Note that the "cwa" attribute is defined as part of the numericContext element data type in the XML Schema document with namespace "http://www.xbrl.org/2001/instance". As such, it cannot be used in, and does not make sense in, non numeric context elements.

If the cwa attribute is equal to "true", then users of an instance document are being informed that it is safe to assume that the instance document contains all of the facts necessary to perform all of the calculations that are defined by the calculation linkbases in the taxonomies referenced by the instance document.

If the cwa attribute is equal to "false", the only other acceptable value that it can take, then users of an instance document are being informed that it is not safe to assume that the instance document contains all of the facts necessary to perform all of the calculations that are defined by the calculation linkbases in the taxonomies referenced by the instance document.

For example, if the calculation linkbase indicates that total assets can be derived by adding current and non current assets but the instance document only contains current assets, then users cannot just assume that non-current assets is equal to zero. This assumption would be declared safe if the cwa attribute was equal to "true".

It is important to note that the cwa assumption only applies to those facts that reference the same exact context element. This limitation on the application of the "cwa" attribute prevents users from wrongly performing calculations that mix facts that do not have a common entity and time period and scenario.

Unfortunately, this restriction on the application of the "cwa" attribute limits the confidence that instance document users can be given in situations where it is sensible to perform calculations defined by the supporting taxonomies but the facts to be used in the calculations do not share a common context because of differences in their units or their precision.

The "precision" of a fact is a part of the numeric context used to describe the accuracy with which fact has been reported. An example of the markup for fact precision is shown below.

<numericContext id="context123" cwa="false" precision="7">
...
</numericContext>

In this example, the precision is specified as 7, indicating that the facts referencing this context, "context123", all have been measured accurately to 7 significant figures. This means that the first seven digits in the number can be used with confidence in calculations.

As an example, if a fact with value 123.456789 is declared to have a precision of 7, then users of that fact can rely on the fact being accurate up to the digit 7. However, the 8 and 9 cannot be relied upon.

The result of a calculation should be attributed with a precision equal to the minimum precision of the values used as inputs to the calculation.

The entity context of an XBRL fact is the description of the entity that is being measured or described by the fact.

Entities can be very different: individuals, organisations, parts of organisations, or even countries. Given the broad range of entities that can be reported on using XBRL, the markup allowed by the XBRL specification for the description of the entity is very flexible.

An example of an entity context XML fragment is shown below.

<numericContext ... >
  <entity>
    <identifier scheme="http://www.Dun-and-Bradstreet.com/">
      1234567890
    </identifier>
    <segment />
  </entity>
  ...
</numericContext>

The entity context of an XBRL fact is required to be marked up using the "entity" element nested within the associated context element.

The entity element must contain an "identifier" element, optionally followed by zero or more "segment" elements.

The identifier element must have a "scheme" attribute. The scheme attribute must be given a value that is a valid Uniform Resource Indicator ("URI").

In general the URI is intended to identify the entity identification scheme. In the example above, the identification scheme is identified, for want of a better word, by the URI, "http://www.Dun-and-Bradstreet.com/".

The text value of the identifier element is the ID of the entity being reported on, as specified by the chosen identification scheme. In the above fabricated example above, the entity is identified by "1234567890".

The entity ID contained in XBRL context elements is not, in general, useful if you want to use the full name of the entity when presenting data about the entity described in the instance document.

Sometimes the full name of the entity is reported in the instance document and if you know the name of the taxonomy concept defined as the full name of the entity, then you can use that data. Otherwise, users of instance documents will need to draw on other resources associated with the entity identification scheme specified in the entity component of the context elements.

Sometimes the entity identifier is not sufficient to fully describe the entity being described by the facts associated with the context. For example, some reports are generated for individual lines of business rather than for a whole institution. When the entity identification scheme does not cover the lines of business, additional entity identification markup is required. This markup is always placed in the "segment" element.

The specific markup used in the "segment" elements is up to the creator of the instance documents containing the multi-dimensional tables. The particular markup used can be adopted by convention. Preferably, however, it is described and can be validated, using an XML Schema definition of the markup for the various dimensions.

Additional customised contextual information (what may be thought of as customised attributes or dimensions required to interpret facts reported using XBRL) can be provided using either the segment context element or the scenario context element.

The segment context element should be used if the additional contextual information fleshes out the nature of the entity to which the fact pertains. The scenario context element should be used if the additional contextual information fleshes out the situation under which the fact pertains to the reporting entity.

Multi-dimensional tables of data generally consist of one or more concepts, reported for different entities, time frames and/or scenarios. In other words, the different dimensions in the tables correspond to context information. Where the standard constituents of numeric and non-numeric context elements are not sufficient to capture the dimensionality of the facts being reported, additional markup will need to be used in either the scenario element or the segment element of the fact contexts.

The specific markup used in these elements is up to the creator of the instance documents containing the multi-dimensional tables. The particular markup used can be adopted by convention. Preferably, however, it is described and can be validated, using an XML Schema definition of the markup for the various dimensions.

Let me emphasise up front that you DO NOT need to create taxonomies that are the cartesian product of every data axis (dimension). For example, if we wished to report assets for line of business A and line of business B, in country X and country Y, do not define four different assets concepts in your taxonomy:

Instead use XML schema to define the business lines and the countries of operation that can be used in the segment element of the fact contexts.

<schema targetNamespace="http://my.com.au/ReportingSegments/2002-01-31"
        xmlns="http://www.w3.org/2001/XMLSchema" 
	xmlns:self="http://my.com.au/ReportingSegments/2002-01-31"
	elementFormDefault="qualified">

  <!-- _____________ Line of Business enumeration           -->
  <simpleType name="lineOfBusinessType">
    <restriction base="string">
      <enumeration value="A"/>
      <enumeration value="B"/>
    </restriction>
  </simpleType>

  <!-- _____________ Country enumeration           -->
  <simpleType name="countryType">
    <restriction base="string">
      <enumeration value="X"/>
      <enumeration value="Y"/>
    </restriction>
  </simpleType>

  <!--    Segment content definition --> 	
  <element name="reportingUnit"> 		
    <complexType> 			
      <attribute name="lob" 
	         type="self:lineOfBusinessType" 
	         minOccurs="1" 
		 maxOccurs="1"/>
      <attribute name="country" 
	         type="self:countryType" 
	         minOccurs="1" 
		 maxOccurs="1"/>
    </complexType> 	
  </element> 	

</schema>	

Instance documents that use this markup to define the contexts for their facts then need to include a namespace declaration to the "http://my.com.au/ReportingSegments/2002-01-31" URI.

<?xml version="1.0"?>
<group xmlns="http://www.xbrl.org/2001/instance" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xmlns:mysegment="http://my.com.au/ReportingSegments/2002-01-31"
       xmlns:mytaxonomy="http://my.com.au/xbrl/taxonomy/2001-08-16/" 
       xmlns:iso4217="http://www.iso.org/4217" 
       xsi:schemaLocation="http://www.iasb.org.uk/xbrl/2001-08-16/ mytaxonomy.xsd
                           http://my.com.au/ReportingSegments/2002-01-31 mysegment.xsd">

  <mytaxonomy:asset numericContext="c1">100</mytaxonomy:asset>
  <mytaxonomy:asset numericContext="c2">200</mytaxonomy:asset>
  <mytaxonomy:asset numericContext="c3">300</mytaxonomy:asset>
  <mytaxonomy:asset numericContext="c4">400</mytaxonomy:asset>

  <numericContext id="c1" precision="18" cwa="false">
    <entity>
      <identifier
        scheme="http://my.com.au/xbrl/entity/identifiers/2002-01-31">
	My Co Limited
      </identifier>
      <segment mysegment:lob="A" mysegment:country="X" />
    </entity>
    <period>
      <instant>2002-09-30</instant>
    </period>
    <unit><measure>iso4217:AU</measure></unit>
  </numericContext>

  <numericContext id="c2" precision="18" cwa="false">
    <entity>
      <identifier
        scheme="http://my.com.au/xbrl/entity/identifiers/2002-01-31">
	My Co Limited
      </identifier>
      <segment mysegment:lob="A" mysegment:country="Y" />
    </entity>
    <period>
      <instant>2002-09-30</instant>
    </period>
    <unit><measure>iso4217:AU</measure></unit>
  </numericContext>

  <numericContext id="c3" precision="18" cwa="false">
    <entity>
      <identifier
        scheme="http://my.com.au/xbrl/entity/identifiers/2002-01-31">
	My Co Limited
      </identifier>
      <segment mysegment:lob="B" mysegment:country="X" />
    </entity>
    <period>
      <instant>2002-09-30</instant>
    </period>
    <unit><measure>iso4217:AU</measure></unit>
  </numericContext>

  <numericContext id="c4" precision="18" cwa="false">
    <entity>
      <identifier
        scheme="http://my.com.au/xbrl/entity/identifiers/2002-01-31">
	My Co Limited
      </identifier>
      <segment mysegment:lob="B" mysegment:country="Y" />
    </entity>
    <period>
      <instant>2002-09-30</instant>
    </period>
    <unit><measure>iso4217:AU</measure></unit>
  </numericContext>

</group>

Note that this keeps the taxonomy small and allows XBRL to identify comparability across the various lines of business/countries in ways that could not be achieved if each permutation and combination of the line of business and country dimensions were represented in the taxonomy. This benefit does come at the cost that processors of the data need to understand the dimensions to be able to generate aggregates and summary information across one or more dimensions. XBRL does not provide this understanding.

No. While XBRL enables the dimensionality to be described, it does not provide information about how the dimensions relate to each other. Thus, unless users of instance documents build an understanding of the data dimensions into their processing applications, operations like aggregation through time or across entity divisions will be risky, to say the least.

For example, just equipped with an instance document, how do I know that I have facts for all possible values in a given dimension. More concretely, say I wish to calculate a fact total for the entire business when I only have facts by line of business, as described in the segment elements of XBRL contexts for those facts? How do I know that I am not missing facts for some of the lines of business? That requires information beyond that available in the XBRL markup.

No. The values taken by XBRL facts must always be PCDATA. Note that this requirement excludes tuples.

Some taxonomy concepts have a value that can be specified using PCDATA alone. In other words, their value can be constructed without requiring additional XML markup. These concepts can be thought of as "simple concepts" and they are identified in taxonomies by classifying them as being substitution elements for the item element as defined in the XBRL instance schema "http://www.xbrl.org/2001/instance".

Other concepts have values that can only be described using a combination of simple concept values. These concepts can be thought of as "compound concepts". Compound concepts are identified in taxonomies by classifying them as being substitution elements for the tuple element as defined in the XBRL instance schema "http://www.xbrl.org/2001/instance".

Thus, in the context of an instance document, a tuple is any XBRL element used to report the value of a compound concept.

An important distinction needs to be made between thinking about tuples as named containers for facts, and concepts with complex content, as suggested by the preceding paragraphs.

Historically, tuples began life in the XBRL specification as groups - anonymous containers for other facts. Then the tuple idea was broken out from the group idea, but they remained anonymous. What does this mean, anonymous?

It means tuples were not marked as "abstract" in the XBRL schema. So you could write <tuple/> in an XBRL instance document and it would validate. You were also free to create your own, named element that substituted for tuple and use that instead.

Next in history came the decision to make tuple abstract, so that if you wanted to use tuples, you had to create a named tuple element in your own schema. However, for all the semantics of tuples in the XBRL specification, named tuples are unecessary. A single <tuple/> element is sufficient.

Once tuples had to be constructed from named elements in taxonomy schemas, their role in marking up the values of compound concepts (with complex content) became more obvious. Items have names, items appear in instance documents, items document concepts. Likewise, tuples have names, tuples appear in instance documents.

Note that tuples are not like items in all respects. Items are required to have a context specified for them in the instance document and they have a datatype that is specified in the taxonomy definition of the concept that they are reporting. Tuples only have context and datatype information inherited from the items that they contain.

Because any item, with any context can be placed within any tuple and still result in an instance document that validates against the taxonomy or taxonomies supporting the instance document, this inheritance of context and datatypes means that tuples are much less strongly validated by taxonomy schema validation of instance documents than are items.

Without datatypes to validate against, the only constraint on the items that can be contained within tuples is the definition given to the tuple concept by resources in reference linkbases.

Expanding on this idea, under the XBRL specification, we cannot use schema validation to ensure that when someone reports the simple concept, "assets", the value reported is actually the value of their assets - it could be the value of inventory, liabilities, or any other quantity with the same datatype as assets. We run up against exactly the same limitations with tuples. Users of XBRL instance documents need to rely on adherence to definitions of concepts (simple and compound) contained in the supporting taxonomy or taxonomies.

In conclusion, with a tuple, we do not need to specify exactly which elements can be contained in a tuple. It is enough to indicate with references what the tuple must convey, as we do with items. This has the benefit that reporters are not constrained to a given element set when creating tuples in reports. An Australian address tuple could contain a valid address using different fields (eg: postcode) to a US address tuple with the zipcode etc.

This approach implies that it would be an abuse of tuples to use them to store items that do not constitute a value of the concept associated with the tuple. Thus, if the "property" tuple is defined as the name and value of a real estate property then the following usage would be an abuse of the tuple because two property values are specified:

<property>
  <propertyName nonNumericContext="c1">Property A</propertyName>
  <propertyValue nonNumericContext="c2">30</propertyValue>
  <propertyValue nonNumericContext="c3">20</propertyValue>
</property>

<property>
  <propertyName nonNumericContext="c1">Property B</propertyName>
  <propertyValue nonNumericContext="c2">50</propertyValue>
  <propertyValue nonNumericContext="c3">40</propertyValue>
</property>

However, the following usage would be quite acceptable:

<property>
  <propertyName nonNumericContext="c1">Property A</propertyName>
  <propertyValue nonNumericContext="c2">30</propertyValue>
</property>

<property>
  <propertyName nonNumericContext="c1">Property A</propertyName>
  <propertyValue nonNumericContext="c3">20</propertyValue>
</property>

<property>
  <propertyName nonNumericContext="c1">Property B</propertyName>
  <propertyValue nonNumericContext="c2">50</propertyValue>
</property>

<property>
  <propertyName nonNumericContext="c1">Property B</propertyName>
  <propertyValue nonNumericContext="c3">40</propertyValue>
</property>

A tuple can be represented by the element defined for the tuple concept containing zero or more other XBRL concept elements, either individual items or other tuples.

For example, a street address concept can be defined as a tuple that takes on values described by the houseNumber and streetName facts.

  <my:streetAddress>
    <my:houseNumber nonNumericContext="context_A">
      30A
    </my:houseNumber>
    <my:streetName nonNumericContext="context_A">
      Marlborough Place
    </my:streetName>
  </my:streetAddress>

If you are from Australia, and perhaps elsewhere, you should pronounce tuple like you would pronounce "dupe". If you are from North America, you pronounce it in a similar way to "up".

There is nothing in the XBRL specification preventing a tuple from containing facts with different contexts.

Tuples can, at times have values specified by a combination of numeric type facts and non-numeric type facts. Given that numeric type facts need to have numeric contexts and non-numeric facts need to have non-numeric contexts, such tuples will, by necessity, have values specified by facts that are supported by different contexts. The XBRL specification is silent on whether the various contexts need to have identical values for common attributes and element values.

Even within the class of numeric type facts, tuples may contain facts with different contexts if the units or precision of the facts making up the tuple value are different.

It is possible, even common for tuples to contain tuples. These can be represented in the expected manner.

<my:address> 
  <my:streetAddress>
    <my:houseNumber nonNumericContext="context_A">
      30A
    </my:houseNumber>
    <my:streetName nonNumericContext="context_A">
      Marlborough Place
    </my:streetName>
  </my:streetAddress>
  <my:city nonNumericContext="context_A">St Ives</my:city>
  <my:postcode numericContext="context_B">2075</my:postcode>
  <my:state nonNumericContext="context_A">New South Wales</my:state>
  <my:country nonNumericContext="context_A">Australia</my:country>
</my:address>

Considerable flexibility is available to users of tuples because there are no requirements imposed by XBRL that any particular set of facts must be contained by a tuple. This is helpful in situations where different combinations of concepts are appropriate in specifying the value of a tuple. For example, in some countries addresses include a postcode with a numeric datatype while in other countries addresses include an areacode, with a string datatype. By choosing to include the appropriate fact, instance documents can cover both situations without difficulty.

No. In a non-normative example, the XBRL specification does link tuple content concepts to tuple concepts using definition links. However, this is not mandated by the specification. Any item or tuple concept defined in an XBRL taxonomy can be used to provide content for an XBRL tuple.

No. A concept is identified as a tuple or a item fact in the taxonomy that defines the concept. Once a concept has been identified as a tuple, it cannot take on a value that is not specified by a combination of other XBRL items or tuples. Importantly, this also means that tuples cannot contain markup that is not XBRL tuples or items.

Yes. Simple as that. Empty items, and tuples can be handy ways to express the facts that should be reported but are not.

It was replaced with references to context elements that have complex markup describing the full set of contextual information required to interpret a given fact.

Yes. An incomplete context means that processing applications will be unable to properly interpret XBRL facts.

Drawing heavily on the XBRL specification 2.0: the group element is the generic container element of the XBRL vocabulary. One of its most useful roles is as the root element of XBRL instance documents.

No. All XML documents need to have a root element. XBRL can be included in an XML document that also contains XML that is not XBRL markup. In these cases, that non-XBRL XML markup can be the root element of the XBRL document. In such cases, no XBRL group element is required at all.

Group elements must only contain child elements. Moreover, these elements must all be defined in XBRL related XML Schema documents, as provided for in the XBRL instance schema document "http://www.xbrl.org/2001/instance".

<element name="group">
  <complexType>
    <choice minOccurs="0" maxOccurs="unbounded">
      <element ref="xbrli:group" minOccurs="0" maxOccurs="unbounded" /> 
      <element ref="xbrli:item" minOccurs="0" maxOccurs="unbounded" /> 
      <element ref="xbrli:tuple" minOccurs="0" maxOccurs="unbounded" /> 
      <element ref="xbrli:nonNumericContext" minOccurs="0" maxOccurs="unbounded" /> 
      <element ref="xbrli:numericContext" minOccurs="0" maxOccurs="unbounded" /> 
      <element ref="link:linkbaseRef" minOccurs="0" maxOccurs="unbounded" /> 
      <element ref="link:footnoteLink" minOccurs="0" maxOccurs="unbounded" /> 
    </choice>
  </complexType>
</element>

This example indicates that groups can contain zero or more of any of the following elements in any order:

No. Both the scenario and the segment elements are defined by XBRL's instance document XML Schema, with namespace "http://www.xbrl.org/2001/instance", to be able to contain any markup whatsoever. As an instance document creator, you may using an XML Schema document of your own to define what kind of content is allowed in an XBRL scenario element. XML Schema validation will not be able to prevent that user defined markup from being used as content for the segment element. Such validation will have to go beyond XML Schema validation.

Yes. However, such instance documents are more verbose than they need to be and they limit the ability of users of those instance documents to conduct inference using calculation relationships and the "closed world assumption".

No. The closed world assumption only tells the user of the instance document that it is sensible to use calculation relationships that operate on the facts that reference the specific context that contains the cwa="true" attribute value.

First, identify the existing taxonomy that defines the concepts that you wish to report. A limited list of available taxonomies is available from XBRL.ORG.

Next, you have to map the values that you have in your own computer systems, for each fact that you wish to report, to the taxonomy concept that defines that fact. Currently this is a manual process in most cases. It involves creating a list of pairs (the fact value and the name of the XBRL element in the taxonomy you are using that corresponds to the fact value).

Finally, mark up your facts using the XBRL instance document markup, creating a context for each different context required by your report, and linking each fact in the report to the appropriate context.

The syntax of the schemaLocation attribute is defined in the XML Schema with namespace xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance".