Instance Documents, Schemas, and Linkbase Documents

A Gepsio user writes:

So reading through your blog and the discussions, I’ve come to realize one big thing that I’ve probably been missing so far — the other documents (Calculations, Schema, Definitions, Label, Presentation) that are listed on the EDGAR site are valuable to the comprehension of the XBRL document, correct? Is there some tutorial on how to load all of the documents into one session and use the corresponding references between them to produce a more robust result?

The short answer is that Gepsio detects and reads all of those ancillary files (called linkbase documents) for you, without you having to do anything but load the XBRL instance. Gepsio does the rest.

Let’s take some time and explore the longer answer. First, we will take a look at how XBRL defines the relationship between instance documents, schemas, and linkbase documents. That will be followed up with a look at how Gepsio uses and exposes the data from the various linkbase documents.

XBRL Relationship Between Instance Documents, Schemas, and Linkbase Documents

An XBRL document instance contains a reference to a schema document:

<xbrl
    xmlns="http://www.xbrl.org/2003/instance"
    xmlns:link="http://www.xbrl.org/2003/linkbase"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:dei="http://xbrl.us/dei/2009-01-31"
    xmlns:xbrli="http://www.xbrl.org/2003/instance"
    xmlns:fds="http://www.factset.com/2010-11-30"
    xmlns:iso4217="http://www.xbrl.org/2003/iso4217"
    xmlns:us-gaap="http://xbrl.us/us-gaap/2009-01-31"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
  <link:schemaRef xlink:type="simple" xlink:href="fds-20101130.xsd" />

The schema, in turn, contains references the various linkbase documents:

<schema
  xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:xbrli="http://www.xbrl.org/2003/instance"
  xmlns:link="http://www.xbrl.org/2003/linkbase"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  targetNamespace="http://www.factset.com/2010-11-30"
  xmlns:fds="http://www.factset.com/2010-11-30"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified"
  xmlns:us-types="http://xbrl.us/us-types/2009-01-31"
>
  <annotation>
    <appinfo>
      <!-- snip -->
      <link:linkbaseRef
          xlink:type="simple"
          xlink:href="fds-20101130_pre.xml"
          xlink:role="http://www.xbrl.org/2003/role/presentationLinkbaseRef"
          xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"
          xlink:title="Presentation Links, all"
      />
      <link:linkbaseRef
          xlink:type="simple"
          xlink:href="fds-20101130_cal.xml"
          xlink:role="http://www.xbrl.org/2003/role/calculationLinkbaseRef"
          xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"
          xlink:title="Calculation Links, all" 
      />
      <link:linkbaseRef
          xlink:type="simple"
          xlink:href="fds-20101130_lab.xml"
          xlink:role="http://www.xbrl.org/2003/role/labelLinkbaseRef"
          xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"
          xlink:title="Label Links, all"
      />
    </appinfo>
  </annotation>

The XBRL instance document is the “starting point” of this chain. The XBRL instance document references the schema, and the schema references the linkbase documents.

Gepsio Loading Instance Documents, Schemas, and Linkbase Documents

Because the XBRL instance document is the “starting point” of the document relationship chain, Gepsio can figure out all of the references when the XBRL instance document is loaded. Gepsio users load an XBRL instance document with the following code:

var MyXbrlDoc = new XbrlDocument();
MyXbrlDoc.Load("MyXbrlDoc.xml");

Gepsio does all of the work to load any referenced schemas and linkbase documents during the loading process automatically. (This is part of the appeal of Gepsio: freeing developers from having to chase down all of these references manually.)

Gepsio Exposing Data from Instance Documents and Schemas

Gepsio’s automatic loading of referenced schemas and linkbase documents is fine, but the real key is to be able to see the loaded reference data.

Referenced schemas are available as a collection in the loaded document’s fragments:

var MyXbrlDoc = new XbrlDocument();
MyXbrlDoc.Load("MyXbrlDoc.xml");
foreach(var currentFragment in MyXbrlDoc.XbrlFragments)
{
    foreach(var currentSchema in currentFragment.Schemas)
    {
        // schema information is available in the
        // "currentSchema" object
    }
}

Once the schema is available, information from the various linkbase documents is available in various collections found on the schema object.

Gepsio Exposing Data from Calculation Linkbases

Information from referenced calculation linkbases are available as a collection in the schema:

var MyXbrlDoc = new XbrlDocument();
MyXbrlDoc.Load("MyXbrlDoc.xml");
foreach(var currentFragment in MyXbrlDoc.XbrlFragments)
{
    foreach(var currentSchema in currentFragment.Schemas)
    {
        var currentCalculationLinkbase = currentSchema.CalculationLinkbase;
        if(currentCalculationLinkbase != null)
        {
            foreach(var currentCalculationLink in currentCalculationLinkbase.CalculationLinks)
            {
                // calculation link information is available in the
                // "currentCalculationLink" object
            }
        }
    }
}

Each calculation link in the calculation linkbase document is available from this collection.

Gepsio Exposing Data from Definition Linkbases

Information from referenced definition linkbases are available as a collection in the schema:

var MyXbrlDoc = new XbrlDocument();
MyXbrlDoc.Load("MyXbrlDoc.xml");
foreach(var currentFragment in MyXbrlDoc.XbrlFragments)
{
    foreach(var currentSchema in currentFragment.Schemas)
    {
        var currentDefinitionLinkbase = currentSchema.DefinitionLinkbase;
        if(currentDefinitionLinkbase != null)
        {
            foreach(var currentDefinitionLink in currentDefinitionLinkbase.DefinitionLinks)
            {
                // definition link information is available in the
                // "currentDefinitionLink" object
            }
        }
    }
}

Each definition link in the definition linkbase document is available from this collection.

Gepsio Exposing Data from Label Linkbases

Information from referenced label linkbases are available as a collection in the schema:

var MyXbrlDoc = new XbrlDocument();
MyXbrlDoc.Load("MyXbrlDoc.xml");
foreach(var currentFragment in MyXbrlDoc.XbrlFragments)
{
    foreach(var currentSchema in currentFragment.Schemas)
    {
        var currentLabelLinkbase = currentSchema.LabelLinkbase;
        if(currentLabelLinkbase != null)
        {
            foreach(var currentLabelLink in currentLabelLinkbase.LabelLinks)
            {
                // label link information is available in the
                // "currentLabelLink" object
            }
        }
    }
}

Each label link in the label linkbase document is available from this collection.

Gepsio Exposing Data from Presentation Linkbases

Information from referenced presentation linkbases are available as a collection in the schema:

var MyXbrlDoc = new XbrlDocument();
MyXbrlDoc.Load("MyXbrlDoc.xml");
foreach(var currentFragment in MyXbrlDoc.XbrlFragments)
{
    foreach(var currentSchema in currentFragment.Schemas)
    {
        var currentPresentationLinkbase = currentSchema.PresentationLinkbase;
        if(currentPresentationLinkbase != null)
        {
            foreach(var currentPresentationLink in currentLabelLinkbase.PresentationLinks)
            {
                // presentation link information is available in the
                // "currentPresentationLink" object
            }
        }
    }
}

Each presentation link in the presentation linkbase document is available from this collection.

Advertisements

Schema Errors Cause XBRL Facts To Not Be Created

A Gepsio user recently emailed in with an interesting problem: the XBRL document being loaded contained an dei:EntityRegistrantName element, but Gepsio did not have a fact with that name in the Facts collection of the XBRL fragment. What was going on?

The XBRL instance looked good. It defined the dei namespace and pulled in a schema:

<XBRL
    xmlns="http://www.xbrl.org/2003/instance"
    xmlns:us-gaap="http://fasb.org/us-gaap/2014-01-31"
    xmlns:xl="http://www.xbrl.org/2003/XLink"
    xmlns:us-types="http://fasb.org/us-types/2014-01-31"
    xmlns:iso4217="http://www.xbrl.org/2003/iso4217"
    xmlns:currency="http://xbrl.sec.gov/currency/2014-01-31"
    xmlns:country="http://xbrl.sec.gov/country/2013-01-31"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:xbrli="http://www.xbrl.org/2003/instance"
    xmlns:xbrldi="http://xbrl.org/2006/xbrldi"
    xmlns:dei="http://xbrl.sec.gov/dei/2014-01-31"
    xmlns:link="http://www.xbrl.org/2003/linkbase"
    xmlns:utr="http://www.xbrl.org/2009/utr"
    xmlns:compsci="http://compsciresources.com"
    xmlns:fds="http://investor.factset.com/20140831"
    xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
>
    <link:schemaRef xlink:type="simple" xlink:href="fds-20140831.xsd"/>

    <!-- snip -->
    <dei:EntityRegistrantName contextRef="c0_From1Sep2013To31Aug2014">
        FACTSET RESEARCH SYSTEMS INC
    </dei:EntityRegistrantName>

The problem was that the referenced schema never actually imported a schema that defined the DEI namespace:

<xs:schema
    xmlns:xbrli="http://www.xbrl.org/2003/instance"
    xmlns:num="http://www.xbrl.org/dtr/type/numeric"
    targetNamespace="http://investor.factset.com/20140831"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:nonnum="http://www.xbrl.org/dtr/type/non-numeric"
    xmlns:us-types="http://fasb.org/us-types/2014-01-31"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:link="http://www.xbrl.org/2003/linkbase"
    xmlns:fds="http://investor.factset.com/20140831"
    elementFormDefault="qualified"
    xmlns:xbrldt="http://xbrl.org/2005/xbrldt"
>
<!-- snip -->
<xs:import
    namespace="http://www.xbrl.org/2003/instance"
    schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"
/>
<xs:import
    namespace="http://www.xbrl.org/2003/linkbase"
    schemaLocation="http://www.xbrl.org/2003/xbrl-linkbase-2003-12-31.xsd"
/>
<xs:import
    namespace="http://fasb.org/us-types/2014-01-31"
    schemaLocation="http://xbrl.fasb.org/us-gaap/2014/elts/us-types-2014-01-31.xsd"
/>
<xs:import
    namespace="http://www.xbrl.org/dtr/type/numeric"
    schemaLocation="http://www.xbrl.org/dtr/type/numeric-2009-12-16.xsd"
/>
<xs:import
    namespace="http://www.xbrl.org/dtr/type/non-numeric"
    schemaLocation="http://www.xbrl.org/dtr/type/nonNumeric-2009-12-16.xsd"
/>
<xs:import
    namespace="http://xbrl.org/2005/xbrldt"
    schemaLocation="http://www.xbrl.org/2005/xbrldt-2005.xsd"
/>

<!-- where is the import for http://xbrl.sec.gov/dei/2014-01-31? -->

When Gepsio started building facts for this instance, it found the dei:EntityRegistrantName element and attempted to build a Fact object. When Gepsio creates a Fact object, it begins by searching through the schemas, looking for the element definition. In this case, Gepsio could not find a schema element definition for dei:EntityRegistrantName, so it didn’t build a Fact object and didn’t put a fact in the Facts collection for dei:EntityRegistantName.

Gepsio did the right thing — it can’t build a Fact object if there is no definition for the element — but it could have done more to report the issue. Today, Gepsio is silent regarding uncreatable Fact objects. Perhaps a new validation error is needed to report this condition. Hopefully, a future CTP can address this need.

Finding Facts

It’s high time that Gepsio had a method to find a fact in a fragment. People are writing code to find facts by iterating through a fragment’s Facts collection, which is both inefficient and slow. If fact finding was built into Gepsio, Gepsio could keep internal structures like fact name dictionaries or hashtables in memory so that finding facts can be much more efficient at runtime.

Something like the following is needed:

Fact GetFact(string factName);

As it turns out, that signature won’t be quite enough, as fact names are scoped into a namespace. For example, it’s probably not enough to say, “Find me the fact named EntityRegistrantName”. It would be more accurate to say, “Find me the fact named EntityRegistrantName as defined by the Document and Entity Information [DEI] taxonomy”.

The problem is exacerbated by the fact that there are multiple versions of a namespace, so it would be more accurate to say, “Find me the fact named EntityRegistrantName as defined by the 2009 version of the DEI taxonomy”.

Is that good enough? Not really. The XBRL document instance loaded into Gepsio could be using the 2009 version of the DEI taxonomy, the 2011 version of the DEI taxonomy, the 2012 version of the DEI taxonomy, the 2013 version of the DEI taxonomy, or the 2014 version of the DEI taxonomy.

The problem here is that Gepsio does such a good job of hiding XML/XBRL internals from the user that namespace URIs and prefixes are generally hidden from the user. Gepsio has enough internal information to be able to expose namespace URIs and prefixes to the user so, if that namespace information were actually exposed and made public, the user could figure all of this out, with code like this:

if(document references 2009 version of DEI taxonomy)
    GetFact("EntityRegistrantName" as defined by the 2009 version of the DEI namespace);
else if(document references 2011 version of DEI taxonomy)
    GetFact("EntityRegistrantName" as defined by the 2011 version of the DEI namespace);
else if(document references 2012 version of DEI taxonomy)
    GetFact("EntityRegistrantName" as defined by the 2012 version of the DEI namespace);
else if(document references 2013 version of DEI taxonomy)
    GetFact("EntityRegistrantName" as defined by the 2013 version of the DEI namespace);
else if(document references 2014 version of DEI taxonomy)
    GetFact("EntityRegistrantName" as defined by the 2014 version of the DEI namespace);

Ish.

Not only would that code have to be modified every time a new version of the DEI taxonomy is released, that’s just … too much code. Gepsio, in keeping with its philosophy of keeping XML/XBRL internals abstracted from the user, should handle more of this from the user. What would be nice would be something like this:

if(document references any version of DEI taxonomy)
    GetFact("EntityRegistrantName" as defined by whatever version of the DEI namespace is used in the document);

Gepsio is being enhanced to support two taxonomy concepts:

  • Taxonomy Version Identifiers: An identifier that would describe a version specific taxonomy. For example, the phrase “the 2009 version of the DEI taxonomy” would be associated with one Taxonomy Version Identifier, while the phrase the phrase “the 2011 version of the DEI taxonomy” would be associated with a separate Taxonomy Version Identifier. Each version of each taxonomy known to Gepsio would get its own Taxonomy Version Identifier.
  • Taxonomy Family Identifiers: An identifier that would describe a taxonomy without taking a specific version into account. Two taxonomies authored by the same authority would be noted as being in the same taxonomy family.

In this design, Gepsio would expose these as public enumerations, with something like the following:

public enum TaxonomyVersion
{
    Unknown,
    DEI2009,
    DEI2011,
    DEI2012,
    DEI2013,
    DEI2014,
    // others, such as US-GAAP
}

public enum TaxonomyFamily
{
    Unknown,
    DEI,
    // others, such as US-GAAP
}

It would be Gepsio’s job to detect as much taxonomy information as possible so that these enumerations could be automatically set when schemas are read in and compiled. The user would not have to set any of these values; instead, Gepsio should be able to set them automatically.

Given all this, three overloads of the proposed GetFact() method are envisioned:

 Fact GetFact(string factName);

This overload finds the named fact without regards to namespaces. The first fact found with the given fact name is returned. A NULL is return if no such fact can be found.

 Fact GetFact(string factName, TaxonomyVersion taxonomyVersion);

This overload finds the named fact defined by the given taxonomy version. The first fact found with the given fact name defined by the taxonomy version is returned. A NULL is return if no such fact can be found, even if the fact name is available from other namespace versions.

 Fact GetFact(string factName, TaxonomyFamily taxonomyFamily);

This overload finds the named fact defined by the given taxonomy family. The first fact found with the given fact name defined in any of the namespaces in the given namespace family is returned. A NULL is return if no such fact can be found, even if the fact name is available from other namespace families.

The Path Forward

Gepsio needs some enhancements to make all of this work:

  1. Examine the target namespaces of all of the schemas read in on behalf of a loaded XBRL instance and, if possible, detect their namespace versions and families.
  2. Add read-only properties to the XbrlSchema class (which probably needs to be renamed XbrlTaxonomy at some point, for consistency’s sake) to expose detected namespace versions and families.
  3. Add the public GetFact() methods to the XbrlFragment class.

Change Log for May 2015 CTP

Design

  • The XLINK specification is now implemented in a specific class, and XBRL linkbase nodes now leverage Gepsio’s implementation of XLINK. The following classes have been refactored to leverage Gepsio’s internal support for the XLINK specification added in version 2.1.0.8:
    • Locator
  • The XbrlSchema’s LinkbaseDocuments collection has been replaced with specific objects that represent specific linkbase documents. See the “New Classes” and “New Properties Available on Previously Existing Classes” sections. This design change is described here and announced here. This is a breaking change from previous releases.

New Classes

  • The PresentationLink class is an encapsulation of the XBRL element “presentationLink” as defined in the http://www.xbrl.org/2003/linkbase namespace.
  • The PresentationArc class is an encapsulation of the XBRL element “presentationArc” as defined in the http://www.xbrl.org/2003/linkbase namespace.
  • The CalculationLinkbaseDocument is an encapsulation of a calculation linkbase document.
  • The DefinitionLinkbaseDocument is an encapsulation of a definition linkbase document.
  • The LabelLinkbaseDocument is an encapsulation of a label linkbase document.
  • The PresentationLinkbaseDocument is an encapsulation of a presentation linkbase document.

New Properties Available on Previously Existing Classes

  • XbrlSchema
    • CalculationLinkbaseDocument CalculationLinkbase
    • DefinitionLinkbaseDocument DefinitionLinkbase
    • LabelLinkbaseDocument LabelLinkbase
    • PresentationLinkbaseDocument PresentationLinkbase

New Methods Available on Previously Existing Classes

  • XbrlDocument
    • Load(System.IO.Stream streamedDocument): Load an XBRL instance from a stream. Schema references used in stream-based XBRL documents must use absolute, not relative, paths. See here for more information.

Previously Existing Properties Removed from Previously Existing Classes

  • XbrlSchema
    • List LinkbaseDocuments

Changes to Conformance

  • none

Conformance Tests in XBRL-CONF-CR5-2012-01-24 Passed by Gepsio

Identifier Scope [Section 4.3 The Item Element]

  • 301-01-IdScopeValid.xml [301.01 Valid example of id attribute.]
  • 301-03-IdScopePeriodDiff.xml [301.03 Mismatch of periodType attribute and referenced context’s period type.]
  • 301-04-IdScopeContextRefToUnit.xml [301.04 contextRef has IDREF to unit element.]
  • 301-05-IdScopeUnitRefToContext.xml [301.05 unitRef has IDREF to context element.]
  • 301-06-FootnoteScopeValid.xml [301.06 Valid example of footnote link href attribute.]
  • 301-08-FootnoteToContext.xml [301.08 href attribute is referencing to context element.]
  • 301-09-FootnoteToUnit.xml [301.09 href attribute is referencing to unit element.]
  • 301-10-FootnoteFromOutOfScope.xml [301.10 The instance contains two footnote links. The second one contains an arc with a from value that does not have a corresponding loc in the same extended link.]
  • 301-11-FootnoteToOutOfScope.xml [301.11 The instance contains two footnote links. The second one contains an arc with a to value that does not have a corresponding footnote resource in the same extended link.]
  • 301-12-FootnoteLocOutOfScope.xml [301.12 The instance contains a footnote link. In the footnote link there is a loc element that has an href that points to a fact in another instance document.]
  • 301-13-FootnoteLocInScope.xml [301.13 The instance contains a footnote link. In the footnote link there is a loc element that has an href that points to a fact in the instance document using the instance document file name with a fragment identifier.]
  • 301-14-FootnoteFromResource.xml [301.14 The instance contains a footnote link. The arc in the footnote link has a from value that matches a footnote resource. This is not valid for the fact-footnote arc role on the arc. The from must point to a loc which in turns points to a fact in the same instance document.]
  • 301-15-FootnoteToLoc.xml [301.15 The instance contains a footnote link. The arc in the footnote link has a from value that matches a footnote resource. This is not valid for the fact-footnote arc role on the arc. The from must point to a loc which in turns points to a fact in the same instance document.]
  • 301-16-FootnoteWithoutLang.xml [301.16 The xml:lang attribute is missing on the footnote resource.]
  • 301-17-FootnoteCustomArcRole.xml [301.17 The footnote custom arc role can relate two footnotes to each other instead of just fact to footnote. (Only the standard footnote arc role is restricted to being from item or tuple locators.) Maybe this might be used to indicate how some footnote is “footnoting” another footnote.]

Context Segments and Scenarios [Section 4.4 The Context Element]

  • 302-01-SegmentValid.xml [302.01 Valid segment in a context]
  • 302-02-SegmentNamespaceInvalid.xml [302.02 Invalid segment in a context; contains an element defined in xbrli namespace]
  • 302-03-ScenarioValid.xml [302.03 Valid scenario in a context]
  • 302-04-ScenarioNamespaceInvalid.xml [302.04 Invalid scenario in a context; contains an element defined in xbrli namespace]
  • 302-05-SegmentSubstitutionInvalid.xml [302.05 Invalid segment in a context; contains an element in substitution group of xbrli:item]
  • 302-06-ScenarioSubstitutionInvalid.xml [302.06 Invalid scenario in a context; contains an element in substitution group of xbrli:item]
  • 302-07-SegmentEmptyContent.xml [302.07 Segment in a context contains an element with empty content]
  • 302-08-ScenarioEmptyContent.xml [302.08 Scenario in a context contains an element with empty content]
  • 302-09-PeriodDateTimeValid.xml [302.09 Valid duration context with start date earlier than end date]
  • 302-10-PeriodDateTimeInvalid.xml [302.10 Invalid duration context with start date later than end date]
  • 302-11-DecimalAttributeOnSegmentInconsistent.xbrl [302.11 Two contexts are S-Equal even though a decimal-valued attribute in their segment elements have different lexical representations. The contexts are S-equal, so a calculation inconsistency MUST be signaled.]
  • 302-12-DecimalAttributeOnScenarioInconsistent.xbrl [302.12 Two contexts are S-Equal even though a decimal-valued attribute in their scenario elements have different lexical representations. The contexts are S-equal, so a calculation inconsistency MUST be signaled.]

Period Type Consistency [Section 4.3 The Item Element]

  • 303-01-PeriodInstantValid.xml [303.01 instant context and item defined with PeriodType=”instant”]
  • 303-02-PeriodDurationValid.xml [303.02 duration context and item defined with PeriodType=”duration”]
  • 303-03-PeriodInstantInvalid.xml [303.03 duration context and item defined with PeriodType=”instant”]
  • 303-04-PeriodDurationInvalid.xml [303.04 instant context and item defined with PeriodType=”duration”]
  • 303-05-ForeverElementewithInstancePeriodTypeReportedasForever.xbrl [ForeverConcept with Instant Period Type is not allowed]

Unit of Measure Consistency [Section 4.4 The Context Element]

  • 304-01-monetaryItemTypeUnitsRestrictions.xml [304.01 An element with a monetary item type has an ISO currency code for its units (using the standard ISO namespace prefix).]
  • 304-02-monetaryItemTypeUnitsRestrictions.xml [304.02 An element with a monetary item type has an ISO currency code for its units (using a non-standard ISO namespace prefix).]
  • 304-03-monetaryItemTypeUnitsRestrictions.xml [304.03 An element with a type derived by restriction from the monetary item type has an ISO currency code for its units.]
  • 304-04-monetaryItemTypeUnitsRestrictions.xml [304.04 An element with a type derived by restriction from monetary item type has an ISO currency code for its units (using a non-standard ISO namespace prefix).]
  • 304-05-monetaryItemTypeUnitsRestrictions.xml [304.05 An element with a non-monetary item type has an ISO currency code for its units (using the standard ISO namespace prefix).]
  • 304-06-monetaryItemTypeUnitsRestrictions.xml [304.06 An element with a monetary item type does not have an ISO currency code for its units – the namespace is wrong.]
  • 304-07-monetaryItemTypeUnitsRestrictions.xml [304.07 An element with a monetaryItemType does not have an ISO currency code for its units – the local name is wrong.]
  • 304-08-monetaryItemTypeUnitsRestrictions.xml [304.08 An element with a type derived by restriction from monetaryItemType does not have an ISO currency code for its units – the namespace is wrong.]
  • 304-09-monetaryItemTypeUnitsRestrictions.xml [304.09 An element with a type derived by restriction from monetaryItemType does not have an ISO currency code for its units – the local name is wrong.]
  • 304-10-pureItemTypeUnitsRestrictions.xml [304.10 An item with a pureItemType data type MUST have a unit element and the local part of the measure MUST be “pure” with a namespace prefix that resolves to a namespace of “http://www.xbrl.org/2003/instance&#8221;.]
  • 304-11-pureItemTypeUnitsRestrictions.xml [A measure element with a namespace prefix that resolves to the “http://www.xbrl.org/2003/instance&#8221; namespace MUST have a local part of either “pure” or “shares”. The value ‘impure’ is not a valid measure in the XBRL instance namespace.]
  • 304-12-pureItemTypeUnitsRestrictions.xml [Unlike for monetaryItemType and sharesItemType, there is no constraint (in 4.8.2 or elsewhere) requiring an item with a pureItemType data type to have a particular kind of unit.]
  • 304-12a-pureItemTypeUnitsRestrictions.xml [Same as V-12, but the pure measure has no prefix and the default namespace is undefined.]
  • 304-13-sharesItemTypeUnitsRestrictions.xml [304.13 For facts that are of the sharesItemType, units MUST have A single measure element. The local part of the measure MUST be “shares” and the namespace prefix that MUST resolve to http://www.xbrl.org/2003/instance%5D
  • 304-14-sharesItemTypeUnitsRestrictions.xml [304.14 For facts that are DERIVED BY RESTRICTION from the sharesItemType, units MUST have A single measure element. The local part of the measure MUST be “shares” and the namespace prefix that MUST resolve to http://www.xbrl.org/2003/instance%5D
  • 304-15-pureItemTypeUnitsRestrictions.xml [304.15 For facts that are of shares item type, units MUST have A single measure element. The local part of the measure MUST be “shares” and the namespace prefix that MUST resolve to http://www.xbrl.org/2003/instance. In this case the unit has two measure elements, both of which are pure.]
  • 304-15a-sharesItemTypeUnitsRestrictions.xml [Same as V-15 but in this case the unit has has shares but no prefix and the default namespace is undefined.]
  • 304-16-unitsInSimplestForm.xml [304.16 The units must not have numerator and denominator measures that cancel.]
  • 304-17-sameOrderMeasuresValid.xml [304.17 The units equality test which two units have same order measures.]
  • 304-18-sameOrderDivisionMeasuresValid.xml [304.18 The units equality test which two units have same order divisions.]
  • 304-19-differentOrderMeasuresValid.xml [304.19 The units equality test which two units have different order measures.]
  • 304-20-differentOrderDivisionMeasuresValid.xml [304.20 The units equality test which two units have division elements which their order of child measures are different.]
  • 304-21-measuresInvalid.xml [304.21 it tries to essence-alias equality of two elements with different units : where one is pure-feet and the second is pure-pounds. so the alias essence check is invalid and it should throw an error in xbrl validation]
  • 304-22-divisionMeasuresInvalid.xml [304.22 The test tried to essense-alias equality check of two elements with different units : where one is unit between “pure-inch / pound-feet” and other “pure-feet / pound-inch”. The tests is invalid as it should throw an error during xbrl validation.]
  • 304-23-Calculation-item-does-not-match-unit.xml [Variation of 304-15 where the type of the fact value does not match that of the type of the reported element. Shares type versus Monetary unit]
  • 304-24-valid-ISO-unit-of-measue.xml [Valid ISO unit of measurement example]
  • 304-25-measure-reported-with-prefix-undefined-instance.xbrl [Measure reported with prefix undefined is considered XBRL invalid]
  • 304-26-monetaryItemTypeUnitsRestrictions.xml [Monetary item reported with unit having a denominator.]

Decimal and Precision Mutual Exclusion and prohibition on nil items [Section 4.4 Items]

  • 305-01-DecimalOnlySpecified.xml [305.01 item has only Decimals specified]
  • 305-02-PrecisionOnlySpecified.xml [305.02 item has only Precision specified]
  • 305-03-NoDecimalOrPrecisionSpecified.xml [305.03 item has neither Decimals nor Precision specified]
  • 305-04-BothDecimalAndPrecisionSpecified.xml [305.04 item has both Decimals and Precision specified]
  • 305-05-DecimalSpecifiedOnNilItem.xml [305.05 nil item has Decimals specified]
  • 305-06-PrecisionSpecifiedOnNilItem.xml [305.06 nil item has Precision specified]
  • 305_07_invalid_instance.xbrl [305.07 a genuine inconsistency due to roll up of child values]
  • 305-08-UnitsSpecifiedOnNilItem.xml [305.08 nil items have no decimals or precision, with unitref, but the type specifies fixed values for decimals and precision.]

Required Arc in Definition Linkbase [Section 5.5.6.4.1.5]

  • 306-01-RequiredInstanceValid.xml [306.01 The instance contains two elements in the same context. The presence of one element forces the presence of the other.]
  • 306-02-RequiredInstanceTupleValid.xml [306.02 The instance contains an item and a tuple. The presence of the tuple forces the presence of the item.]
  • 306-03-RequiredInstanceInvalid.xml [306.03 The instance contains an item and a tuple. The presence of the tuple forces the presence of the item.]

Schema References [Section 5 Taxonomies]

  • 307-01-SchemaRefExample.xml [307.01 A schemaRef element MUST hold the URI of a schema. In this case it does.]
  • 307-02-SchemaRefCounterExample.xml [307.01 A schemaRef element MUST hold the URI of a schema. In this case it does not because the second reference to a schema actually points to an XML document that is a label linkbase. ]
  • 307-03-SchemaRefXMLBase.xml [307.03 schemaRef elements MUST hold the URI of Schemas. In this case the requirement is not satisfied because the schema reference has to be resolved using the XML base attribute that ensures the schemaRef URI resolves to the XML document in the base directory. This document, however, is a label linkbase, not a schema. If the XML base attribute value is not used then the schema in the same directory as the instance is discovered and no issues are noticed.]

Duplicate instance roleRef and duplicate arcroleRefs [3.5.2.4.5 and 3.5.2.5.5 duplicate instance roleRef and arcroleRef elements.]

  • 308-01-instance.xml [Instance contains two role references to the same URI, INVALID]
  • 308-02-instance.xml [Instance contains two arcrole references to the same URI, INVALID]

LAX validation tests [Test that LAX validation is performed]

  • 314-lax-validation-01.xml [Segment has an element for which there is no definition, so it is allowed; item has an attribute with no definition, so it is allowed. The definitions are imported to the discovered taxonomy.]
  • 314-lax-validation-02.xml [Segment has an element for which there is no definition, so it is allowed; item has an attribute with no definition, so it is allowed. The definitions are found by schemaLocation from the instance document.]
  • 314-lax-validation-03.xml [Same as v-01 but segment has an element defined as integer with string contents]