DTSContainer

[DTSContainer javadoc page]

Description

A DTSContainer object is the placeholder for all other objects in the DTS.

How to create an instance of a DTSContainer

There are four ways:

• By a call to DTSContainer.newEmptyContainer() method [javadoc link]. This is the most commonly used way.

• By a call to DTSContainer.newEmptyContainer(java.util.Properties) method [javadoc link]. This is used in special cases were the processor requires special initialization. Two properties exists and are documented as constants in the DTSContainer object. Documentation in this wiki will come later.

• By a call to DTSContainer.newCompatibleContainer(net.sf.saxon.s9api.Processor, java.util.Properties) method [javadoc link]. This is a special case that allows the creation of a DTSContainer reusing the Saxon processor from the application or from another DTSContainer object. The properties parameter may be null or may by the properties of another DTSContainer.

• By a call to mergeDTSs(com.ihr.xbrl.om.DTSContainer[]) method [javadoc link]. This is another special case that allow the user to merge the result of an array of DTSContainers into a single DTSContainer. Note: the resulting DTSContainer may not be valid in the DTSs to merge contains not compatible elements like a duplicate definition of the same role type.

Usage

Inside an application the user is free to create as many DTSContainer objects he needs. The content of each DTSContainer is completely isolated from the others. Changes in one DTSContainer will not other instances of a DTSContainer.

Each DTSContainer object contains a new instance of the Saxonica processor. It may be interesting in some applications that all DTSContainers created inside the application were compatible among them (this is, for example, the case when there are multiple different DTSs for which XhBtRmL templates exists inside the same Transformation Processor).

What's inside a DTSContainer object

The DTSContainer object contains useful information required to work with the DTS. All the information is collected during the DTS Discovery Process (implemented in any of the four overloaded load methods) or during the different validation processes. The API automatically collects the information for you.

The following is a list of the information collected during the DTS discovery process:

All concepts defined

This is all XBRL concepts in all discovered XBRL Taxonomies. The user can access a concept using the concept QName and setting the namespace to the namespace of the XBRLTaxonomy and the local part to the element name as it is defined in the taxonomy.

Concepts in the DTS can be accessed sequentially by retrieving a concepts iterator.

All role types

This includes static role types defined in the XBRL 2.1 specification and that does not require any definition in a taxonomy and all other role types defined in taxonomy schemas in the DTS.

The roles can be accessed by the role URI or sequentially by retrieving a role type iterator.

All arcrole types

This includes static arcrole types defined in the XBRL 2.1 specification and that does not require any definition in a taxonomy and all other role types defined in taxonomy schemas in the DTS.

All relationships

They are organized by DTSBase

All resources defined on any extended link container

Resources can be accessed sequentially or by providing the elements that makes the resource unique

The root URLs

They are the URLs used to start the DTS discovery process

All XBRL Documents added to the DTS

This includes all taxonomy schemas, linkbases, extended links and external documents in case there were generic linkbases pointing to any external documents.

All languages

During the process of reading labels in label extended link containers the DTSContainer object updates a list of different languages used.

Etc...

There is much more information than can be obtained from the DTSContainer object. We will continue including more information about that content later.

Navigation

Main Page | XBRL API related discussions