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 ScopedElemApi
Inherited from HasScopeApi
Inherited from HasQNameApi
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 Node
Inherited from AnyRef
Inherited from Any
Any element in a taxonomy schema or linkbase document. The classes in this class hierarchy offer the yaidom query API, in particular the
ScopedElemApi
andSubtypeAwareElemApi
query API.Usage
Suppose we have an eu.cdevreeze.tqa.dom.XsdSchema called
schema
. Then we can find all global element declarations in this schema as follows:Leniency
The classes in this type hierarchy have been designed to be very lenient when instantiating them, even for schema-invalid content. The few builder methods that may throw exceptions have been clearly documented to potentially do so. For schema-invalid taxonomy content, the resulting object may be something like
OtherXsdElem
,OtherLinkElem
orOtherNonXLinkElem
. For example, an element named xs:element with both a name and ref attribute cannot be both an element declaration and element reference, and will be instantiated as anOtherXsdElem
. A non-standard XLink arc, whether a known generic arc or some unknown and potentially erroneous arc, becomes aNonStandardArc
, etc.Some instance methods may fail, however, if taxonomy content is invalid, and if it is schema-invalid in particular. All instance methods must not fail on schema-valid content, unless mentioned otherwise.
Typical instance methods that may fail on schema-invalid content are:
It is important to keep this in mind. Schema-invalid taxonomies will be instantiated successfully, but after instantiation the API user should fall back to (defensive) yaidom level query methods when needed. This is indeed the responsibility of the API user.
Other remarks
The type hierarchy for taxonomy elements is not a strict hierarchy. There are mixin traits for XLink content, "root elements", elements in the xs and link namespaces, etc. Some element types mix in more than one of these traits.
See http://www.datypic.com/sc/xsd/s-xmlschema.xsd.html for schema content in general (as opposed to taxonomy schema content in particular).
It is perfectly fine to embed linkbase content in schema content, and such an element tree will be instantiated correctly.
The underlying backing elements can be any backing element implementation, including
BackingElemApi
wrappers around Saxon tiny trees! Hence, this taxonomy DOM API is flexible in that it is not bound to one specific backing element implementation.