XBRL documents that use facts originating from multiple namespaces can be loaded into Gepsio, but not all of the facts will appear in the object model in the Jan 2011 CTP.
Consider, for example, an XBRL document whose schema declares the following namespaces:
The target namespace in this example is http://www.fujitsu.com/xbrl/taxeditor/default, and the prefix for this namespace is cmi. Using the Gepsio Jan 2011 CTP, only facts in the cmi namespace will be loaded and available in the Facts collection. Facts in other namespaces will not appear in the collection.
Why is this happening?
When looking for facts in an XBRL document, Gepsio must determine which XML elements are indeed facts and which are elements defined in the XBRL specification (such as <context> and <period>). In the Jan 2011 CTP (and, indeed, all of the CTPs to this point), this determination is made by examining the current XML element’s namespace. If the namespace of the element matches the target namespace of the document’s schema, then the element is assumed to be a fact. Elements that are not a part of the target namespace are assumed to be something other than an XBRL fact, so they are not read in as a fact and not available in the Fact collection.
To continue the example using the sample XBRL schema shown above, only facts in the cmi namespace will be read in as an XBRL fact. Other elements in other namespaces, though they are facts, will not be read in as a fact and will not appear in the Fact collection. Facts using the us-gaap namespace, for example, will not appear in the Fact collection, even though they are indeed valid XBRL facts.
How will this be fixed in the future?
Gepsio’s fact loader will change in the future. Rather than looking at an XML element’s namespace to see if it matches the schema’s target namespace, the namespace URI for the XML element will be examined. If the namespace of the element lists the www.xbrl.org or www.w3.org domain, then the element will assumed to be something other than an XBRL fact. Elements using any other namespace domain will be assumed to be an XBRL fact. This rework should allow for a more complete population of a XbrlFragment object’s Fact collection.
When will this be fixed?
I am working on this bug now and am hoping to have this issue resolved in the Feb 2011 CTP.