tqa
BigDecimal value or XPath expression.
EName value or XPath expression.
EName value or XPath expression. If it is an ENameExpr, the XPath expression is expected to resolve to schema type xs:QName. Hence, a very simple ENameExpr would syntactically look like a lexical QName literal (and not like an EName in James Clark notation).
An XPath expression in a Scope.
An XPath expression in a Scope. Typically this object originates from an XPath expression in an XBRL formula or table linkbase, where the Scope is taken from the XML element scope.
It is likely that the real Scope used to evaluate the XPath expression is not exactly the same Scope as stored in this object. For example, the default namespace for evaluating the XPath expression should probably not be the one stored in this object, if any.
This class is in the "tqa" root package and not in the "xpath" sub-package. The reason is that this class represents data that requires no XPath evaluator whatsoever, whereas the "xpath" sub-package offers an XPath evaluator abstraction. As a consequence a dependency on the "xpath" sub-package is only needed where XPath evaluation is done.
String value or XPath expression.
A collection of substitution groups, typically extracted from a taxonomy.
A collection of substitution groups, typically extracted from a taxonomy. It maps substitution groups to their own substitution groups, if any. Well-known substitution groups such as xbrli:item, xbrli:tuple, xbrldt:hypercubeItem and xbrldt:dimensionItem must not occur as keys in the mapping, but typically do occur as mapped values.
This class is essential for providing the necessary context in order to determine whether a global element declaration is a concept declaration, and, if so, what kind of concept declaration.
Cycles are not allowed when following mappings, but this is not checked.
Value of some type or XPath expression that must evaluate to the same type.
A unique identifier of an XML fragment in a Taxonomy.
A unique identifier of an XML fragment in a Taxonomy. It is made up by the document URI and the Path within that document.
A parsed xsi:schemaLocation attribute value, as a mapping from namespace names to document URIs.
A parsed xsi:schemaLocation attribute value, as a mapping from namespace names to document URIs.
It can not contain any duplicate namespace names, or else an exception is thrown during construction.
Well-known ENames.
Well-known Namespaces.
Parsing of xsd:boolean into Boolean.
Parsing of xsd:boolean into Boolean. This is functionality offered by the JAXB DatatypeConverter, but in Scala.js we cannot use that.
Aspects and aspect models.
Some console programs.
Document builders for yaidom BackingNodes.Elem implementations that can be used as underlying element
implementation in the TQA taxonomy DOM.
Document builders for yaidom BackingNodes.Elem implementations that can be used as underlying element
implementation in the TQA taxonomy DOM.
The document builder abstraction must be useful both in the JVM and in JavaScript runtimes.
Model of XBRL instances, as "yaidom dialect".
Instance validators, wrapping some taxonomy object.
Instance validators, wrapping some taxonomy object. These validators are aware of XBRL instances and how to (dimensionally) validate them.
Purely abstract API of XLink content, as used in XBRL.
Purely abstract API of XLink content, as used in XBRL. Different type-safe DOM abstractions share this API for XLink content.
See the schema xl-2003-12-31.xsd (and the imported xlink-2003-12-31.xsd). For the relevant part of the Core XBRL Specification, see http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02-20.html#_3.5.
Note that this package contains no linkbase type. Linkbases are only supported by the "taxonomy DOM" package.
XPath-aware taxonomy querying support.
XPath-aware taxonomy querying support. In TQA no taxonomy XPath awareness is anywhere outside of this namespace. This implies that all of TQA outside of this namespace (and the xpath namespace) can be used without the need for any XPath processor. Everything inside this namespace does need an XPath processor, though.
Dependency on XPath processing for taxonomy querying and processing is not without its costs:
Root package of the Taxonomy Query API. This package itself contains commonly used data classes and many constants for namespaces and expanded names.
There are 3 layers in TQA. The lowest layer is the type-safe taxonomy DOM model. It uses yaidom (https://github.com/dvreeze/yaidom) for its "XML dialect support", where the XML dialect is XBRL taxonomy data. It knows only about individual DOM trees.
On top of the type-safe DOM layer is the relationship layer. It resolves the arcs of the DOM layer as relationships. Of course, to resolve arcs we need other documents as context.
On top of the relationship layer is the taxonomy query API layer. It uses the underlying layers to offer a query API in which taxonomy elements (such as concept declarations) and relationships can easily be queried.
It is important to note that higher layers do not abstract away lower layers. Think of the layering more in terms of dependencies. The "taxonomy DOM" layer depends only on yaidom, the relationship layer only depends on the taxonomy DOM layer, and the query API layer depends on both the taxonomy DOM and relationship layers. On the other hand, relationships are indeed abstractions of the underlying XLink arcs and locators/resources.
These 3 layers are as follows in terms of packages, from low to high:
Usage
How do we query XBRL taxonomies with TQA? For some examples, see package eu.cdevreeze.tqa.base.queryapi.
It should be noted that typical queries involve all 3 packages eu.cdevreeze.tqa.base.queryapi, eu.cdevreeze.tqa.base.relationship and eu.cdevreeze.tqa.base.dom.
It should also be noted that TQA is deeply rooted in the yaidom XML query API (https://github.com/dvreeze/yaidom). This is true internally and externally. Internally TQA has been built in a bottom-up manner on top of yaidom, and this is in particular visible in the internals of the TQA DOM package. Externally many TQA query methods remind of yaidom query methods, but taking and returning type-safe TQA DOM taxonomy content instead of arbitrary XML content. In other words, knowing yaidom helps in getting to know TQA. Of course, knowing the basics of XBRL taxonomies and XBRL dimensions also helps in getting to know TQA.
For all TQA queries, it is possible to write an equivalent lower level query, possibly even a low level yaidom query. Doing so may be time-consuming, but it can also be a good learning experience if one intends to use TQA extensively.
TQA tries to follow the XBRL Core and Dimensions specifications. For example, TQA knows about networks of relationships, XPointer in an XBRL context, embedded linkbases etc.
TQA feels like an API designed in a bottom-up manner on top of yaidom, and that is indeed what it is. So, although TQA can help in learning more about XBRL taxonomies, it is not an API for users who have no knowledge about XBRL. From the lower level DOM-like operations to the higher level dimensional bulk query methods, TQA is useful only for users who know what data they are looking for in a taxonomy.
See package eu.cdevreeze.tqa.base.queryapi for some examples, and navigate to the eu.cdevreeze.tqa.base.relationship and eu.cdevreeze.tqa.base.dom packages for specific relationships and type-safe taxonomy DOM content, respectively.
Backing XML DOM implementations
TQA is flexible in the DOM implementation used. It is pluggable, as long as it offers a yaidom
BackingNodes.Elemfacade and we have aeu.cdevreeze.tqa.backingelem.DocumentBuilderfor it.Out of the box, 2 backing DOM implementations are available:
BackingNodes.Elemimplementation wrapping SaxonNodeInfoobjects, and typically implemented using Saxon tiny treesBackingNodes.Elemnative implementation using yaidom "indexed" elementsThe Saxon (9.7) wrapper implementation, especially when tiny trees are used under the hood, is efficient in space and time, so it should be preferred for production code. The native yaidom implementation is less efficient, in particular in memory footprint, but it is easy to debug and therefore a nice choice in test code. Whichever the choice of underlying DOM implementation, most code using TQA is completely unaffected by it.