DTSContainer
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 collection of the information is automatically done by the API.
The following is a list of the information collected during the DTS discovery process:
All concepts defined
This is all concepts in all taxonomy schemas. 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.
