DTSContainer: Difference between revisions

From XBRLWiki
Jump to navigationJump to search
m (Reverted edits by Waexu (Talk) to last revision by Ihr)
 
(20 intermediate revisions by the same user not shown)
Line 1: Line 1:
==DTSContainer wiki page==
===Javadoc page===
[[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html  DTSContainer javadoc page]]
[[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html  DTSContainer javadoc page]]


===Notes===
==Description==


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


===How to create an instance of a DTSContainer===
==How to create an instance of a DTSContainer==


There are four ways:
There are four ways:
Line 18: Line 13:
* By a call to <tt>DTSContainer.newEmptyContainer(java.util.Properties)</tt> method [[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html#newEmptyContainer(java.util.Properties) 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 <tt>DTSContainer.newEmptyContainer(java.util.Properties)</tt> method [[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html#newEmptyContainer(java.util.Properties) 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 <tt>DTSContainer.newCompatibleContainer(net.sf.saxon.s9api.Processor, java.util.Properties)</tt> method [[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html#newCompatibleContainer(net.sf.saxon.s9api.Processor,+java.util.Properties) 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 <tt>null</tt> or may by the properties of another DTSContainer.
* By a call to <tt>DTSContainer.newCompatibleContainer(net.sf.saxon.s9api.Processor, java.util.Properties)</tt> method [[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html#newCompatibleContainer(net.sf.saxon.s9api.Processor,_java.util.Properties) 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 <tt>null</tt> or may by the properties of another DTSContainer.
 
* By a call to <tt>mergeDTSs(com.ihr.xbrl.om.DTSContainer[])</tt> method [[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html#mergeDTSs(com.ihr.xbrl.om.DTSContainer%5b%5d) 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 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 [[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html#getConcept(javax.xml.namespace.QName) 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 [[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html#getConcepts() getConcepts()]]
 
The user can also access individual items only iterators [[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html#getItemDeclarations() getItemDeclarations()]] and tuples only iterators [[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html#getTupleDeclarations() getTupleDeclarations()]].
 
===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.
 
===All Resources===
 
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.
 
===Registered processors===
 
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.


* By a call to <tt>mergeDTSs(com.ihr.xbrl.om.DTSContainer[])</tt> method [[http://www.reportingstandard.com/apidoc/com/ihr/xbrl/om/DTSContainer.html#mergeDTSs(com.ihr.xbrl.om.DTSContainer[]) 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.
===Etc...===


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


Inside an application the user is free to create as many DTSContainer objects as necessary. The content of each one of the DTSContainers will be separated. Changes in one DTSContainer will not affect the others. 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).
==Navigation==
[[Main Page]] | [[XBRL API related discussions]]

Latest revision as of 20:17, 8 November 2010

[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 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()]

The user can also access individual items only iterators [getItemDeclarations()] and tuples only iterators [getTupleDeclarations()].

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.

All Resources

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.

Registered processors

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.

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