What is new for the XBRLAPI?

28 July 2009: Version 5.0 released.

Version 5.0 has been released. The query language is now XQuery 1.0 rather than XPath 2.0. This change has meant that the Xindice data store is no longer supported. The new release also provides mature relationship persistence features, enabling XLink relationships to be documented in the persisted database to dramatically improve the performance of operations relying on the analysis of XLink relationship networks. A number of significant changes have also been made to function signatures in the API, reflecting the fact that data stores now contain considerably more information than just fragments of XBRL documents.

8 July 2009: Planning for new file release

A new file release is planned for July 31, 2009. This will be version 5.0 of the XBRLAPI. It is not going to be fully backward compatible.

8 July 2009: Data store query changes

XPath 1.0 has been replaced with XQuery 1.0 as the data store query language. To handle differences in data stores between how all of the document root elements can be identified, all queries are now preprocessed to replace occurrences of the string '#roots#' with the data store specific expression needed to select the root elements of the full set of XML Resources in the data store.

8 July 2009: More examples

A new set of examples have been provided showing ways in which the XBRLAPI data store can be maintained. These are available in the org.xbrlapi.data.bdbxml.examples.utilities package. They are documented by their Javadoc. Existing examples have been repackaged to reflect their data store dependencies. Examples have also be adapted to make them easier to unit test.

8 July 2009: Method signature changes

In preparation for the release of XBRLAPI 5.0, a number of API changes have been made. These largely relate to a broadening of the kinds of data that can be stored in the data store and to an increased level of consistency in using the java.net.URI for URIs.

8 July 2009: Relationship persistence

In some situations the query cost involved in real-time XLink relationship analysis can be problematic. In those situations, XLink relationship analysis can be done in advance with relationship information being persisted to the data store. This relationship persistence enables substantial improvements in the performance of relationship network analysis. Usage of persisted relationships is also largely hidden from the end user.