XBRLAPI installation and configuration
This page is relevant to those looking to use XBRLAPI in their own environment. XBRLAPI can appear daunting but the first steps are not difficult and most of the challenges relate to getting the underlying data stores that XBRLAPI relies upon up and running.
Many of the suggestions put forward in this document only cover one way of achieving the desired result, an operational XBRLAPI installation. Please follow the suggestions at your own discretion. None of the contributors to XBRLAPI accept responsibility for adverse results of any kind caused by following these suggestions or using the XBRLAPI.
For those looking for examples showing how to exercise the API provided by XBRLAPI, the best place to look is in the examples module where a very simple data loading example is provided and where a more detailed and realistic XBRL instance rendering example is also provided. You can also investigate the unit-testing code. This is distributed in the source code archive available as a file release from Sourceforge.
JAR file-naming conventions
All XBRLAPI modules are released as compiled binaries in the form of JAR files. Each JAR file has a name that identifies the module and the date on which it was generated. The source code for each module is also made available for download in a ZIP archive. ZIP archives follow an identical naming convention to the JAR files.
The XBRLAPI is now configured in a modular fashion to minimise the number of third party JAR dependencies for a particular installation. Thus, if you are setting up the XBRLAPI to use the in memory XML DOM representation of the data store, then you do not have to install the JAR files for the eXist, or the Oracle Berkeley Database XML data stores. This considerably simplifies setup and limits the potential for conflicts between the JAR files required as dependencies by different data store implementations.
Modularisation has also split out the code for the handling of the XML Base, the XML Pointer and the XLink specifications. The modules for these specifications will always need to be installed, along with the core XBRLAPI module and the XBRLAPI utilities module if you are intending to using XBRLAPI. They have been split out to ensure that those with an interest in their functionality alone can avoid the rest of the XBRLAPI.
The modules and their dependencies are as follows:
|module-utilities||Provides common functionality acrFree Open-Source Software all other modules||all other XBRLAPI modules|
|module-api||Provides the XBRLAPI API and implementation.||all XBRLAPI data store modules|
|module-xmlbase||Provides an XML Base implementation||xbrlapi-api module|
|module-xlink||Provides an XLink 1.1 implementation||xbrlapi-api module|
|module-xpointer||Provides an XML Pointer implementation||xbrlapi-api module|
|module-bdb-xml||Provides the Oracle Berkeley Database XML persistent data store implementation.||no modules|
|module-exist||Provides the stand-alone eXist persistent data store implementation.||no modules|
|module-exist-embedded||Provides the embedded eXist persistent data store implementation.||no modules|
|module-examples||Provides examples of data loading and XBRL instance rendering.||no modules|
|module-xdt||Provides an extension to the XBRLAPI to deal with the XBRL Dimensions specification. This module remains experimental and unstable.||no modules|
If you are the kind of person that dislikes too many JARs then you might also like to instead work with the xbrlapi-X.X.jar (X.X is the version) file that combines all of the modularised XBRLAPI JAR file contents into the one JAR. This Jar file is downloadable from the Sourceforge website. That approach can lead to unnecessary dependencies but it is simple to make sure you have everything that is part of the XBRLAPI.