[The next release of Gepsio will feature an internal change to its XML service layer. Fortunately, this change is entirely internal and will not affect how Gepsio is used by consumers, so, if you’re not interested in Gepsio’s internal design, you can stop reading now.]
It has long been a stated desire of the project to get Gepsio to run on .NET, Windows RT (for use in Windows Store applications), iOS via Xamarin, and Android via Xamarin. Microsoft’s Portable Class Library (PCL) technology will take the Gepsio code base much of the way there, and Xamarin will take it the rest of the way.
The big wrinkle in this strategy is that, until now, Gepsio has been heavily reliant on the classes in the System.Xml namespace that shipped with .NET 3.5. Many of these classes differ in the XML support found in the LINQ-to-XML implementation supported by the PCL. Some classes have changed names; for example, System.Xml.XmlDocument is now System.Xml.Linq.XDocument. Other classes have disappeared altogether; for example, System.Xml.Schema.XmlSchema has no analog in LINQ-to-XML, which is tough news for a specification such as XBRL which leverages XML schemas to a great degree.
The other complication is that the Gepsio code base uses the System.Xml classes “inline” with the rest of the XBRL processing. There is no architectural notion of a separate logical “XML service layer” which separates the lower-level XML services from the higher-level XBRL processing. Everything is inline, making the code base more difficult to manage when the XML service layer needs to change, as it will when the LINQ-to-XML support is added to the Gepsio code base.
The next CTP will change that picture significantly. All XML services are now implemented behind a set of implementation-agnostic internal interfaces that separate the XML service layer from the rest of the code. For example, instead of using System.Xml.XmlDocument inline, Gepsio now uses a generic interface called IDocument. This interface supports all operations that need to take place on an XML document, but does not mandate a specific implementation. Gepsio also includes an implementation of IDocument that leverages the System.Xml.XmlDocument class in its implementation. The next CTP of Gepsio will contain several such internal implementation-agnostic interfaces in its logical XML service layer:
Additionally, the next CTP of Gepsio will use these interfaces exclusively when XML services are needed, thereby cleanly separating its XML service concerns from its XBRL processing concerns.
When the LINQ-to-XML work begins on Gepsio in earnest, the work will involve re-implementing the interfaces using LINQ-to-XML and PCL compatible services and will leave the rest of the Gepsio code base intact. This work will be significant, especially since LINQ-to-XML does not natively support XML schemas, which will require that XML schema services be written from scratch. The saving grace is that the work will be segregated into a specific portion of the code base that will not affect Gepsio’s XBRL processing layer.
The interfaces, the System.Xml-based implementation of the interface, and the simple IoC container used to resolve interfaces into an implementation is all stored within the single Gepsio assembly, so there will be no additional DLLs to deploy when Gepsio is consumed.
To recap, the roadmap to Gepsio’s support of iOS, Android, Windows Phone, and Windows Store is as follows:
- Define interfaces to XML service layer (done; available in next CTP)
- Implement interfaces using System.Xml classes (done; available in next CTP)
- Migrate Gepsio’s XBRL processing layer to use interfaces (done; available in next CTP)
- Implement interfaces using PCL compatible LINQ-to-XML classes
That last step will be a bit of work, but the first three steps put Gepsio’s code base in a good position for that last step.