- 1 Description
- 2 How to create an instance of a DTSContainer
- 3 Usage
- 4 What's inside a DTSContainer object
- 4.1 All concepts defined
- 4.2 All role types
- 4.3 All arcrole types
- 4.4 All relationships
- 4.5 All resources defined on any extended link container
- 4.6 The root URLs
- 4.7 All XBRL Documents added to the DTS
- 4.8 All languages
- 4.9 All Resources
- 4.10 All XBRL Documents loaded in the DTS
- 4.11 Registered processors
- 4.12 Etc...
- 5 Navigation
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.
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 by setting the QName namespace to the namespace of the XBRLTaxonomy and the QName local part to the element name as it is defined in the taxonomy and then calling the [getConcept(QName)] method. The returned object is an XMLFragment that can be casted to an XBRLItem or an XBRLTuple.
Concepts in the DTS can be accessed sequentially by retrieving a concepts iterator [getConcepts()]
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.
They are organized by DTSBase
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.
During the process of reading labels in label extended link containers the DTSContainer object updates a list of different languages used.
They are all resources defined in all XBRL Linkbases in the DTS. This is includes but is not limited to Label resources and Reference resources.
Starting with release 2.6.8 some Formula resources are recognized and transformed into specific formula related resources. The implementation of the XBRL Formula specification is planed to be finished fot the 2.7 release.
All specific object resources (Label resources, Reference resources, Formula resources, etc) are derived classes of the XBRLResource class. This means that all properties of a generic resource like attributes, value and children elements are always available for a resource. Specific resource objects facilitate validation and integration with other objects in the API.
All XBRL Documents loaded in the DTS
They are all XBRL Taxonomies and XBRL Linkbases indexed by the document absolute URI. The user can access any of the documents by its key value or he can retrieve an iterator over all objects of a specific type.
This is the set of registered processors that performs XBRL Validation. Once a processor is instantiated for a DTS it is registered for that DTS so it is always used and not created again. A processor can be obtained by its name. The Processor name is a static proprerty of all XBRLPlugInProcessors.
There is much more information than can be obtained from the DTSContainer object. We will continue including more information about that content later.