Developing a Windows Store Reference Application for Gepsio

The Gepsio codebase is currently undergoing a pretty significant, but exciting, transformation. It is migrating from its current design as a .NET 3.5 assembly to a multi-platform assembly which will support the following platforms:

  • .NET 4.5
  • .NET for Windows Store (also known as “Windows RT”, or simply “WinRT”)
  • Windows Phone 8

This transformation, made possible through Microsoft’s Portable Class Library technology, will allow developers to use Gepsio to build XBRL-enabled applications for the Windows desktop, Windows Store and Windows Phone 8 through the use of a single Gepsio assembly.

To test this technology and ensure that the new Gepsio code base is performing as expected on the various platforms, a reference Windows Store application called the XBRL Document Explorer is being built. This application uses the Portable Class Library implementation of the Gepsio runtime to provide XBRL services to a Windows Store application. The reference application will allow users to open an XBRL document either stored locally or out on the Internet and will allow users to browse through the various aspects of the XBRL data in an easy-to-read format:

Tapping on the “Open Local” button brings up the Windows Store’s OpenFilePicker and allows the user to select a locally stored XBRL document that Gepsio can open and validate:

Once the user selects an XBRL document, the XBRL Document Explorer uses Gepsio’s XbrlDocument.Load() method to open the selected document:

Oops. That looks like an error to me.

As it turns out, the “sandboxed” security model of WinRT means that applications can’t just open any file on the system and read it as it pleases. This means that Gepsio will need some other way to work with XBRL documents if it is to support Windows Store applications. It’s good to know this now, and this is why reference applications are built – to ensure that everything works as intended.

Never fear. There is a resolution to this issue, and the next post will discuss a simple addition to Gepsio’s support for opening locally stored XBRL documents that will support Windows Store applications while retaining its existing support for .NET desktop applications.

A Gepsio user posted the following question to the Gepsio discussion forum:

I want to use Gepsio to download Edgar 10-Q statements. Does anyone know how to construct the URL to properly get a specific XBRL 10-Q by specifying the ticker and the date?

I asked around in search of an answer, and got the following response from the “father of XBRL”, Charles Hoffman:

Regretfully, this is a bit of a hunt to get what you want and there is a little more to this to safely get the right information.

First off, the TICKER is not a REQUIRED piece of information (in some SEC filings, not in others). If it where required, that would be a very wonderful thing for investors or analysts trying to use the information. And so, you have to somehow gather that information yourself.

I got tickers from Wikipedia, that is how I created this:

Basically, you need a CIK number to ticker cross reference.

Second, you need to understand what fiscal year focus (2013, 2012, 2011, etc.) and what fiscal period focus (FY, Q1, Q2, Q3, Q4). This information is now in SEC filings, it is required. Now, some filers where reporting Q4 rather than FY, so there are some mistakes. But, this is getting better. The reason I mention this is that the SEC is requiring information to make what you want possible; if one mentioned this to the SEC (i.e. how about requiring that ticker symbol SEC) then we are a step closer to having what you desire.

Third, you have to make sure that if a filing is amended, that you get the correct filing (i.e. the amended filing, not the filing which was superseded). All the information necessary to do that is there, but you have to figure this out so your software gets the right filing.

Finally, once you put these pieces together, the URL to the XBRL instance is in the SEC RSS feed. You can look it up.

I am using the XBRL Cloud Edgar Report Information Web Service plus some stuff I have been maintaining in Microsoft Access to achieve what you are requesting. But, I only have the tickers for the Dow 30, Fortune 100, and S&P 500. I build those lists and cross references manually. They are just prototypes though, I don’t maintain them for changes to the list. I just use this for prototyping and testing.

So, it is possible. Of course, your XBRL processor would not have this capability. You need a layer on top of XBRL to work through where to get all this information and piece it together. Great functionality. Just another processing layer, specific to the SEC EDGAR XBRL filings.

But this is important to grasp because any other system will need some sort of mechanism to locate filings within that system. Clearly each system will be different because XBRL does not specify any of this.

Additionally, David vun Kannon had this to say:

Ticker symbols are not the ‘property’ of the company, they are assigned by the exchange the company’s stock strades on. For example NASDAQ assigned AAPL to Apple Computer and MSFT to Microsoft. If Microsoft left NASDAQ and started trading on the NYSE, their ticker symbol would change. The rumour is that the NYSE has held the symbol ‘M’ available for years, hoping to attract Microsoft and benefit from all the trading volume if they moved.

There are also multiple ticker symbols if the company has multiple share classes of stock that are traded. Most companies have only the common stock traded, so we identify AAPL with Apple Computer, but that is not accurate. Remeber when GM owned EDS and Hughes? There were GM E and GM H tracking stocks, trading with those symbols.

You also have symbologies invented by quote vendors such as Reuters, different symbols for the same stock traded on multiple exchanges around the world, ADRs, and other things to consider. This is why something that seems straightforward, isn’t.