The discussion threads on a previous post, as well as the discussion attached to a GitHub issue, speak to the fact that Gepsio cannot find facts for XBRL instances that use the Dutch taxonomy. There are a couple of issues here, so this post will discuss the issue as well as an idea that will allow Gepsio to mitigate one of the issues.
A Gepsio user recently wrote to the project and said that they were in possession of an XBRL instance that was successfully parsed by Gepsio but was devoid of facts. The XBRL instance started out as follows:
<?xml version="1.0" encoding="UTF-8"?> <xbrli:xbrl xmlns:xbrli="http://www.xbrl.org/2003/instance" xmlns="http://www.w3.org/1999/xhtml" xmlns:dst="http://xbrl.dcca.dk/dst" xmlns:cmn="http://xbrl.dcca.dk/cmn" xmlns:sob="http://xbrl.dcca.dk/sob" xmlns:link="http://www.xbrl.org/2003/linkbase" xmlns:iso4217="http://www.xbrl.org/2003/iso4217" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ref="http://www.xbrl.org/2006/ref" xmlns:xh11d="http://www.w3.org/1999/xhtml/datatypes/" xmlns:arr="http://xbrl.dcca.dk/arr" xmlns:ixt="http://www.xbrl.org/inlineXBRL/transformation/2010-04-20" xmlns:lnk="http://www.xbrl.org/2003/linkbase" xmlns:xbrldt="http://xbrl.org/2005/xbrldt" xmlns:basis="http://xbrl.dcca.dk/Regnskab%202.0%20Basis" xmlns:ifrs="http://xbrl.iasb.org/taxonomy/2009-04-01/ifrs" xmlns:ix="http://www.xbrl.org/2008/inlineXBRL" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:mrv="http://xbrl.dcca.dk/mrv" xmlns:xl="http://www.xbrl.org/2003/XLink" xmlns:fsa="http://xbrl.dcca.dk/fsa" xmlns:xbrldi="http://xbrl.org/2006/xbrldi" xmlns:gsd="http://xbrl.dcca.dk/gsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink"> <lnk:schemaRef xlink:href="http://archprod.service.eogs.dk/taxonomy/20171001/entryDanishGAAPBalanceSheetAccountFormIncomeStatementByNatureIncludingManagementsReviewStatisticsAndTax20171001.xsd" xlink:type="simple"/>
There is an issue right away, because that schema reference specifies an invalid URL. There is no document, XML schema or otherwise, at the address of http://archprod.service.eogs.dk/taxonomy/20171001. What happens here is that Gepsio loads the document, finds the schema reference, and attempts to load the schema. Since the schema load fails, it logs a validation error and continues on as best it can. Since no schemas are loaded, no element definitions are loaded, and Gepsio can find no facts.
The first question is, “Why does this document reference a taxonomy with an invalid URL?” The answer that came back was this:
But the issue is that there will never be a hosted taxonomy in denmark, since they have chosen to not take the responsibility thereof.
OK, then. Apparently, the URLs for Dutch taxonomies are placeholders, and they are meant to be available locally, in the same location as the XBRL instance.
Gepsio is being modified to assist with this issue. If Gepsio attempts to resolve a schema reference, and gets the equivalent of an HTTP 404 back from the request to retrieve the schema, then Gepsio will look for the schema in the same folder as the XBRL instance which contains the schema reference.
Currently, Gepsio parses an XBRL instance and automatically loads any schemas referenced by a
<schemaRef> element. The facts in the XBRL instance are then automatically validated against the loaded schemas. However, Gepsio does not automatically load any industry-standard schemas not explicitly referenced by the
<schemaRef> element. Since XBRL instances do not typically make an explicit reference to industry-standard schemas (nor should they), facts that reference those schemas cannot be validated.
Consider, for example, the XBRL instance at http://xbrlsite.com/US-GAAP/BasicExample/2010-09-30/abc-20101231.xml. It contains one
<schemaRef> element so that a linkbase can be loaded. However, the facts in this instance reference namespaces such as
http://xbrl.us/us-gaap/2009-01-31. Since there is no schema reference for those namespaces, the facts that use those namespaces fail validation. The trick, though, is that those namespaces reference well-known industry standard namespaces that identify well-known schemas with schema source at well-known locations across the Internet.
The next version of Gepsio will add support for these well-known namespaces and will automatically load schemas referenced by the XBRL instance’s
<xbrl xmlns:...> syntax even though the schema locations for the schemas are not explicitly referenced by a
<schemaRef> element in the instance. Doing this will allow the facts in the instance using those namespaces to validate with full schema fidelity.
As of this writing, Gepsio supports the following industry-standard schemas:
- Document Information and Entity Information 2009
- US-GAAP 2009
Support for many other industry-standard schemas will be added as testing continues. The important note is that the code now has the infrastructure in place to support this notion, and support for other industry-standard schemas can be added relatively easily, and in one place, now that the infrastructure is available.
The Gepsio code base has a new home on GitHub! The latest code base, built for .NET Standard 2.0, is available at https://github.com/JeffFerguson/gepsio. Feel free to clone it and take a look!
Please keep in mind that the Gepsio Git repo is in preview. The solution in the repo is based on .NET Standard 2.0 and requires Visual Studio 2017 Preview 15.3.0 Preview 3.0 or higher, as well as .NET Core 2.0 Preview 2 or higher, to build. If you need code compatible with the current shipping production releases of Visual Studio 2017 and the full .NET Framework, please see Gepsio’s legacy Codeplex repository.
Microsoft recently announced .NET Core 2.0 Preview 2 and, in keeping with the Gepsio development roadmap for 2017, work continued to see how the Gepsio code base would survive the move from the .NET Framework to .NET Core. A previous blog post discussed this same work with .NET Core 2.0 Preview 1.
The unit tests in the .NET Standard-based Gepsio solution have been updated to use the latest available version of the XBRL Conformance Suite (XBRL-CONF-2014-12-10). The solution builds a .NET Standard 2.0 build of Gepsio and a .NET Core 2.0 build of the unit tests, and the tests run to the same point at which the older .NET Framework build of Gepsio runs. The tests seem to run a bit more slowly than they do in the .NET Framework, but, since .NET Standard 2.0 is in preview mode, it can be assumed that some performance tuning has yet to be done.
This is fantastic news! Gepsio is on its way to being able to provide services to a variety of Windows and non-Windows platforms, extending its reach beyond .NET to a variety of operating systems and device platforms.
After doing some final cleanup, the .NET Standard-base Gepsio solution will be moved up to GitHub. A separate blog post will be created when the new repo is ready. The older .NET Framework-based Gepsio solution will remain on Codeplex.
It is important to note that the solution that will be posted to GitHub is based on .NET Standard 2.0 and requires Visual Studio 2017 Preview 15.3.0 Preview 3.0 or higher, as well as .NET Core 2.0 Preview 2 or higher, to build. If you need code compatible with the current shipping production releases of Visual Studio and the .NET Framework, continue to reference Gepsio’s existing Codeplex repository.
Microsoft recently announced .NET Core 2.0 Preview 1 and, in keeping with the Gepsio development roadmap for 2017, work began to see how the Gepsio code base would survive the move from the .NET Framework to .NET Core. Good news and bad news came out of this work:
- Good News: The code compiled with without changing a line of code!
- Bad News: A bug in .NET Core 2.0 Preview 1 will prevent Gepsio from running under that particular preview release.
The Good News
Building Gepsio under .NET Core 2.0 Preview 1 was a breeze (although it needs to be built under a preview version of Visual Studio). Since all of the classes used in the Gepsio code base are available in .NET Standard 2.0, all of the code was able to build with no changes. Excellent!
The Bad News
After Gepsio built under .NET Core 2.0 Preview 1, the time came to run the unit tests. Unfortunately, the tests failed right away (cue the sad trombone). Running the very first test in the XBRL Conformance Suite under .NET Core 2.0 Preview 1 throws the following exception:
System.Xml.Schema.XmlSchemaException occurred HResult=0x80131941 Message=Type 'http://www.xbrl.org/2003/instance:monetaryItemType' is not declared. Source=<Cannot evaluate the exception source> StackTrace: at System.Xml.Schema.XmlSchemaSet.InternalValidationCallback(Object sender, ValidationEventArgs e) at System.Xml.Schema.BaseProcessor.SendValidationEvent(XmlSchemaException e, XmlSeverityType severity) at System.Xml.Schema.BaseProcessor.SendValidationEvent(XmlSchemaException e) at System.Xml.Schema.Compiler.CompileElement(XmlSchemaElement xe) at System.Xml.Schema.Compiler.Compile() at System.Xml.Schema.Compiler.Execute(XmlSchemaSet schemaSet, SchemaInfo schemaCompiledInfo) at System.Xml.Schema.XmlSchemaSet.Compile() at JeffFerguson.Gepsio.Xml.Implementation.SystemXml.SchemaSet.Compile() in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio\Xml\Implementations\SystemXml\SchemaSet.cs:line 83 at JeffFerguson.Gepsio.XbrlSchema..ctor(XbrlFragment ContainingXbrlFragment, String SchemaFilename, String BaseDirectory) in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio\XbrlSchema.cs:line 169 at JeffFerguson.Gepsio.XbrlFragment.ProcessSchemaNamespaceAndLocation(String schemaNamespace, String schemaLocation) in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio\XbrlFragment.cs:line 374 at JeffFerguson.Gepsio.XbrlFragment.ProcessSchemaLocationAttributeValue(String schemaLocationAttributeValue) in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio\XbrlFragment.cs:line 368 at JeffFerguson.Gepsio.XbrlFragment.ReadSchemaLocationAttributes() in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio\XbrlFragment.cs:line 348 at JeffFerguson.Gepsio.XbrlFragment..ctor(XbrlDocument ParentDocument, INamespaceManager namespaceManager, INode XbrlRootNode) in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio\XbrlFragment.cs:line 160 at JeffFerguson.Gepsio.XbrlDocument.Parse(IDocument doc) in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio\XbrlDocument.cs:line 275 at JeffFerguson.Gepsio.XbrlDocument.Load(String Filename) in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio\XbrlDocument.cs:line 179 at JeffFerguson.Test.Gepsio.XbrlConformanceTest.ExecuteVariation(String TestcaseXmlSourceDirectory, XmlNode VariationNode) in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio.Test\XbrlConformanceTest.cs:line 97 at JeffFerguson.Test.Gepsio.XbrlConformanceTest.ExecuteTestcase(String ConformanceXmlSourcePath, XmlNode TestcaseNode) in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio.Test\XbrlConformanceTest.cs:line 76 at JeffFerguson.Test.Gepsio.XbrlConformanceTest.ExecuteXBRLCONF20141210Testcases() in C:\Users\jefff\Source\Repos\gepsio\JeffFerguson.Gepsio.Test\XbrlConformanceTest.cs:line 44
The test uses the following schema:
<!-- edited by Masatomo Goto (Fujitsu) --> <!-- XBRL 2.1 Tests --> <!-- Copyright 2003 XBRL International. See www.xbrl.org/legal. All Rights Reserved. --> <schema targetNamespace="http://example.com/xbrl/taxonomy" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:xbrli="http://www.xbrl.org/2003/instance" xmlns:link="http://www.xbrl.org/2003/linkbase" xmlns:xlink="http://www.w3.org/1999/xlink"> <import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/> <element name="changeInRetainedEarnings" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" id="a1" xbrli:periodType="duration"/> <element name="fixedAssets" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" id="a2" xbrli:balance="debit" xbrli:periodType="instant"/> </schema>
In this schema, the changeInRetainedEarnings element is of type xbrli:monetaryItemType, which is defined in the imported schema. The imported schema’s types were not being picked up by .NET Core 2.0 during the schema set compilation process as they are in the full .NET Framework.
The issue was raised on GitHub and was traced to a bug in the .NET Core 2.0 Preview 1 build. The issue, which has its roots in this bug, has been fixed but was fixed too late to be included in .NET Core 2.0 Preview 1.
The next steps for Gepsio is to wait for .NET Core 2.0 Preview 2 to be released and to retry the compilation and unit testing process. Perhaps Preview 2 will allow Gepsio to get farther along in the .NET Core runtime.