Adding Local Search Support For Schemas With Invalid URLs

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="" xmlns="" xmlns:dst="" xmlns:cmn="" xmlns:sob="" xmlns:link="" xmlns:iso4217="" xmlns:xsi="" xmlns:ref="" xmlns:xh11d="" xmlns:arr="" xmlns:ixt="" xmlns:lnk="" xmlns:xbrldt="" xmlns:basis="" xmlns:ifrs="" xmlns:ix="" xmlns:xhtml="" xmlns:mrv="" xmlns:xl="" xmlns:fsa="" xmlns:xbrldi="" xmlns:gsd="" xmlns:xs="" xmlns:xlink="">
   <lnk:schemaRef xlink:href="" 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 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.


Next Release to Support Automatic Loading of Industry Standard Schemas

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 It contains one <schemaRef> element so that a linkbase can be loaded. However, the facts in this instance reference namespaces such as and 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.

This change is in the develop branch in GitHub. The changes are available in this commit and will be available in the next update to Gepsio’s NuGet package.

Gepsio Repository Now Available on GitHub

The Gepsio code base has a new home on GitHub! The latest code base, built for .NET Standard 2.0, is available at 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.

Gepsio and .NET Core 2.0 Preview 2

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.

Spoiler alert.

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.

Next Steps

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.

Gepsio and .NET Core 2.0 Preview 1

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
Message=Type '' is not declared.
Source=<Cannot evaluate the exception source>
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 All Rights Reserved. -->
<schema targetNamespace="" xmlns="" xmlns:xhtml="" xmlns:xbrli="" xmlns:link="" xmlns:xlink="">
<import namespace="" schemaLocation=""/>
<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"/>

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.

Next Steps

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.

Codeplex Shutting Down, But Gepsio Continuing on GitHub

Microsoft has announced that the Codeplex site will be retired this year. This news does not affect Gepsio in any way. As noted in the original roadmap plan for Gepsio, as well as the March 2017 update to that plan, Gepsio will be moving from Codeplex to GitHub in 2017.

The anticipated shutdown date for Codeplex is December 15, 2017. Gepsio’s 2017 development plan notes that Gepsio will move over to GitHub when .NET Standard 2.0 is released. Since the move to GitHub is planned during the first public preview release of .NET Standard 2.0, and since Microsoft’s current roadmap for .NET Standard lists a public preview release of .NET Standard 2.0 in the second quarter of 2017, Gepsio’s code base and related materials should be moved over to GitHub well before the December 15 shutdown date for Codeplex. If there is a need to do so, Gepsio could be moved over to GitHub earlier than that; however, with all of the other migration activities going on as well as Gepsio’s move from .NET Framework to .NET Standard, it made the most sense to make a “clean cut” over to GitHub once the code’s migration to .NET Standard is complete.

The Gepsio project thanks the Codeplex team at Microsoft for offering a home to the Gepsio source since 2008.

March Update on Development Roadmap for 2017

Microsoft has released Visual Studio 2017, which is the development environment used for Gepsio development. Gepsio’s development roadmap for 2017, published in December 2016 and outlined here, noted that Gepsio would be moving to .NET Standard 2.0 once Visual Studio 2017 was released, as .NET Standard 2.0 would allow Gepsio to support a variety of environments, including the full .NET Framework, .NET Core, Xamarin.iOS, Xamarin.Android, and Linux.

The original roadmap was written on the assumption that .NET Standard 2.0 would be shipping “out of the box” with Visual Studio 2017. According to Microsoft’s .NET Core Roadmap, .NET Standard 2.0 and .NET Core 2.0 will not be released until Q3 2017, with public preview builds arriving in Q2 2017. Therefore, the project will remain in Codeplex and Visual Studio 2015 until the public previews of .NET Standard 2.0 are available.

To recap, once .NET Standard 2.0 becomes available, the project will move forward as follows:

  • the solution will migrate from Visual Studio 2015 to Visual Studio 2017
  • the Gepsio assembly will migrate from a .NET Framework target to a .NET Standard 2.0 target
  • the Gepsio unit tests will migrate from a .NET Framework target to a .NET Core 2.0 target
  • the repository will migrate from Codeplex over to Github
  • the repository access will migrate from TFS to git

For now, the work will remain at Codeplex and built by Visual Studio 2015. There have been several improvements made lately, with changeset history visible here, and it’s high time for a new release. Perhaps a new build can be pushed out to NuGet in April.