Java XBRL API implementation / News: Recent posts

Version 6.1 has been released, making an important bug fix affecting methods that perform fact retrieval from the data store.

Major change relates to move from java.net.URI data types for XML Schema namespaces and XLink roles to using Strings.

Note the change to the signature of the loader constructors. Note also the shift to TestNG instead of JUnit 3. Finally biggie for this release is the first version of the embedded eXist database module allowing the XBRLAPI to be run with the eXist database as part of the same application. Feedback on flaws, speed issues or new bugs is very welcome as always.

It has been a long-time-coming but the unit testing system has been bought up to scratch with migration from JUnit 3.8.1 to the latest version of TestNG. That should make the unit testing a lot faster. It has also required a fair bit of work on test fixtures to ensure that tests can be run in parallel without inadvertent interactions, especially with the persistent data stores.

Work has begun on getting the eXist data store implementation up to speed. Many thanks to Roland Oldenburg for the bump and the great suggestions. A key part of the upgrade is the introduction of a new eXist data store implementation that is set up to use eXist in embedded mode. This should be simpler to configure and have better performance, at least in some circumstances.

The 5.3 file release has finally gone live. It includes extensive improvements to the API, including a complete rewrite of the org.xbrlapi.aspects package. It also include a jump forward to the eXist 1.4 database from version 1.2.6. The improvements are substantial.
The new release also includes a small number of bug-fixes so upgrading to the new release is recommended.

Version 5.2 makes some significant improvements to fragmentation of XML Schemas, allowing for more intelligent analysis of data type derivations. It also includes new support for fraction item types. The treatment of aspects has also been overhauled, with a new location aspect being introduced and with a new level of consistency in treatment of missing aspect values being achieved.

Version 5.0 of the XBRLAPI has been released. It is not backward compatible. The XBRLAPI now uses XQuery 1.0 rather than XPath 1.0 for database querying. It also provides mature XLink relationship persistence to significantly enhance performance. The range of examples has also been extended. Support for the Xindice data store has been dropped because of the lack of support for XQuery in Xindice.

A new file release has been issued. It involves some small but inportant backward compatibility issues relating to the new usage of java.net.URI rather than java.net.URL wherever possible. This change has been driven by the need for improved conformance with various URI schemes. The new release also involves a range of significant performance improvements, especially in relation to network analysis.

The Jar files were not created properly for the 3.3 file release, resulting in the examples not working as described. This has been corrected by this 3.4 file release.

The 3.4 file release also adds aspects to the XDT support, allowing aspect models to be created from XDT dimensions.

A 3.3 file release has been issued for all packages, including two new ones: one for a pair of quite detailed examples and one for some experimental XBRL Dimensions support. Both new packages are not mandatory downloads.

The new release of the XBRLAPI has some minor backward incompatibilities relating to the org.xbrlapi.Unit interface and relating to the operation of the methods to retrieve root nodes of networks.... read more

A new package of methods has been created to simplify dimensional analysis of collections of facts. The org.xbrlapi.aspects package provides a
basic implementation of dimensional analysis for the XBRL 2.1 specification (not the XDT specification yet) to support simple slicing and dicing of fact collections based upon the information about the definition of those facts and their contextual and unit information.

The new release features:
1. A small number of bug fixes
2. Significant improvements in the stability of the data store based on the Oracle Berkeley XML database
3. A simplification of the API to enhance the processing of relationship networks
4. Removal of non-functioning placeholder set methods.
5. A new indexing system for fragments
6. A method of ensuring that duplicate documents with different URLs are identified and treated as the same document.

The XBRLAPI now optionally allows users to store just a single document in the data store, even when that document is loaded into the data store from more than one URL. See the new org.xbrlapi.data.resource package for details.

The default behaviour remains as before where each URL gets stored in the data store.

Users can define their own document signatures to customise the level of confidence that they have in identifying identical documents that have been loaded into the data store from different URLs.

Source control has now moved to Subversion. The history of code changes has not been migrated from CVS. CVS remains available.

This release involves a range of important bug fixes as well as improved support of both the BDB-XML data store and the Xindice data store. A range of new methods are also available for various fragment interfaces.

The new 3.0 release features new classes that drastically simplify interactions with relationships and networks of relationships. It also includes a new persistent data store based upon the Oracle Berkeley Database. The project structure has also been reorganised to support the use of Maven for building the XBRLAPI source. The documentation on the www.xbrlapi.org website has also been significantly expanded and updated.
A significant number of bug fixes have also been provided as part of

An implementation of the data store based on the Oracle Berkeley Database XML distribution (http://www.oracle.com/technology/documentation/berkeley-db/xml/index.html) is now in the CVS repository. Early assessment indicates that it has performance that is orders of magnitude better than than those of the other persistent data stores that have been implemented to date. A considerable part of this performance gain is likely to be attributable to the fact that it is implemented as an embedded database in the XBRLAPI's new bdbxml module.

The new 2.0 release of the XBRL API is available. Most of the functionality remains unchanged. However, the library has been repackaged to simplify the dependencies of the library on various data store implementations such as the eXist and Xindice databases.

To use the new release, you will at least need to download the binary jar files for the api, XLink, XML Base and XPointer packages.

Download the eXist binary jar file if you want to use the eXist data store and download the Xindice binary jar file if you want ot use the Xindice data store.

The XBRLAPI code base is now organised along the lines recommended for Maven projects. The code is organised into a variety of modules, each with its own project object model (pom.xml). The dependencies are clearly documented and minimised (eg: if you do not want to use eXist or Xindice as an underlying data store you do not need to use those modules). Overall, the changes should significantly improve the ease of setting up the XBRLAPI code base on your own system.

The XBRLAPI now also works with eXist running as an embedded database within the XBRLAPI itself. This means that the eXist database is running in the same Java instance as the XBRLAPI implementation, dramatically improving performance.

The DTS discovery process has been streamlined by eliminating all XLink extended link and locator post discovery processing. This cuts the standard discovery time by more than 50 % when using the Exist data store.

Version 1.0 of the read-only features of XBRLAPI 1.0 are completed. No data modification functionality is provided by this implementation, meaning that it is "only" suitable for usage with applications that analyse or organise existing XBRL data.

A new XBRLAPI file release has been issued to fix critical problems in Exist data store indexing and to fix problems relating to the manifest file for the XBRLAPI jar.

A major overhaul of the underlying data store has been finalised this week. The split of information about the information stored into one collection for actual data and one for metadata has been eliminated, improving data store interaction efficiencies and bringing a new ability to simultaneously query the data store on the basis of both the data and the metadata.