Inherited from SubtypeAwareElemLike
Inherited from SubtypeAwareElemApi
Inherited from ScopedElemLike
Inherited from ClarkElemLike
Inherited from HasText
Inherited from HasEName
Inherited from IsNavigable
Inherited from ElemLike
Inherited from Elem
Inherited from ScopedElemApi
Inherited from HasScopeApi
Inherited from HasQNameApi
Inherited from Elem
Inherited from HasChildNodesApi
Inherited from AnyElemNodeApi
Inherited from ClarkElemApi
Inherited from HasTextApi
Inherited from HasENameApi
Inherited from IsNavigableApi
Inherited from ElemApi
Inherited from AnyElemApi
Inherited from Elem
Inherited from CanBeDocumentChild
Inherited from CanBeDocumentChild
Inherited from CanBeDocumentChild
Inherited from Node
Inherited from Node
Inherited from Node
Inherited from AnyRef
Inherited from Any
XML element inside XBRL instance (or the entire XBRL instance itself). This API is immutable, provided the backing element is immutable.
The yaidom
SubtypeAwareElemApi
andScopedElemApi
query API is offered.Also note that the package-private constructor contains redundant data, in order to speed up (yaidom-based) querying, at the expense of (expensive recursive element) creation.
These XBRL instance elements are just an XBRL instance view on the underlying "backing element" tree, and therefore do not know about the taxonomy describing the XBRL instance (other than the href to the DTS entry point). It is not even required that the XBRL instance is schema-valid. Construction of an instance is indeed quite lenient.
As a consequence, this model must recognize facts by only looking at the elements and their ancestry, without knowing anything about the substitution groups of the corresponding concept declarations. Fortunately, the XBRL instance schema (xbrl-instance-2003-12-31.xsd) and the specification of allowed XBRL tuple content are (almost) restrictive enough in order to recognize facts.
It is even possible to easily distinguish between item facts and tuple facts, based on the presence or absence of the contextRef attribute. There is one complication, though, and that is nil item and tuple facts. Unfortunately, concept declarations in taxonomy schemas may have the nillable attribute set to true. This led to some clutter in the inheritance hierarchy for numeric item facts.
Hence, regarding nil facts, the user of the API is responsible for keeping in mind that facts can indeed be nil facts (which facts are easy to filter away).
Another limitation is that without the taxonomy, default dimensions are unknown. Finally, the lack of typing information is a limitation.
Note that the backing element implementation can be any implementation of yaidom query API trait
BackingNodes.Elem
.This class hierarchy depends on Java 8 or later, due to the use of Java 8 time API.
Creation of
XbrliElem
objects is designed not to fail, even if the XML element is not an XBRL instance or part thereof. Of course, after creation many query methods may fail in such cases. It is also possible to use these data classes for XBRL instances embedded in other XML elements, or only for parts of XBRL instances. As an example of the latter, table layout models may contain pieces of XBRL context data, such as periods. Their parent elements can be parsed into anXbrliElem
, thus offering the XBRL instance query API on such XBRL context data.