eu.cdevreeze.tqa.base.model

All model group, so an xs:all element.

Anonymous complex type definition. It is a non-top-level xs:complexType element without any name attribute.

Anonymous simple type definition. It is a non-top-level xs:simpleType element without any name attribute.

Anonymous type definition, so either an anonymous complex type definition or an anonymous simple type definition.

Representation of an element in an xs:appinfo element (as descendant). The ancestor xs:appinfo element may or may not be a child of a top-level xs:annotation element.

Either a global attribute declaration or a local attribute declaration.

Either an attribute declaration or an attribute reference.

Attribute group definition, so a top-level xs:attributeGroup element with a name attribute.

Attribute group definition or attribute group reference.

Attribute group reference, so a non-top-level xs:attributeGroup element with a ref attribute, referring to an attribute group definition.

Attribute reference. It is an xs:attribute element referring to a global attribute declaration. It is not a direct child element of the xs:schema root element.

Super-type of schema components that can be abstract.

Choice model group, so an xs:choice element.

An xs:complexContent element.

Complex type definition, so either a named complex type definition or an anonymous complex type definition.

Concept declaration, wrapping a GlobalElementDeclaration. It must be in substitution group xbrli:item or xbrli:tuple, either directly or indirectly.

There are no sub-classes for domain members, because as global element declarations they are defined in the Dimensions specification in the exact same way that primary items are defined. Therefore primary items and dimension members are indistinguishable.

In order to build a ConceptDeclaration from a GlobalElementDeclaration, the builder needs a SubstitutionGroupMap as context. The created ConceptDeclaration does not retain that used SubstitutionGroupMap. As a consequence, these concept declaration objects only make sense in a context where the used substitution group map is fixed. In taxonomies that know their substitution group map, this is clearly the case. In other words, outside the context of a taxonomy that knows its substitution group map, concept declarations are not "portable" objects, whereas the underlying global element declarations are.

Standard/generic inter-concept relationship path. Subsequent relationships in the path must be "consecutive". For non-dimensional relationships that means that (of course) target concepts match the subsequent source concepts, and that the ELR remain the same.

A relationship path must have at least one relationship.

Either simple content or complex content.

Dimension declaration. It must be an abstract item declaration in the xbrldt:dimensionItem substitution group.

Representation of an element in an xs:documentation element (as descendant). The ancestor xs:documentation element may or may not be a child of a top-level xs:annotation element.

Either a global element declaration or a local element declaration.

Either an element declaration or an element reference.

Element key, for schema content or resources. It must always contain a string ID, but typically contains more data to make it sufficiently unique.

It does not contain any URI, to make the elements having those keys as portable as possible.

It is assumed that only the 2 sub-types SchemaContentElementKey and ResourceKey are needed, that is, that each element (to refer to in a LocatorNode) for which there is no specific LocatorNode sub-type is either schema content or a ResourceNode (or its content).

Element reference, referring to a global element declaration. Like local element declarations it is not a child element of the xs:schema root element, but unlike global and local element declarations it has a ref attribute instead of a name attribute.

Explicit dimension declaration. It must be a dimension declaration without attribute xbrldt:typedDomainRef, among other requirements.

An xs:extension element.

Global attribute declaration. It is an xs:attribute element, and a child element of the xs:schema root element.

Global element declaration. This element in isolation does not know if the element declaration is a concept declaration, because it does not know from which substitution groups its own substitution group, if any, derives.

Example, assuming an xs:schema parent (and document root) element:

<xs:element
 id="businessSegments"
 name="BusinessSegments"
 type="xbrli:monetaryItemType"
 substitutionGroup="xbrli:item"
 xbrli:periodType="duration" />

In this case, we see immediately that the global element declaration is an item concept declaration, but as said above, in general we cannot determine this without looking at the context of all other taxonomy documents in the same "taxonomy".

Once we have a SubstitutionGroupMap as context, we can turn the global element declaration into a ConceptDeclaration, if the global element declaration is indeed an item or tuple declaration according to the SubstitutionGroupMap.

The "other child elements" passed below, if any, are xs:unique, xs:key and xs:keyref elements.

Hypercube declaration. It must be an abstract item declaration in the xbrldt:hypercubeItem substitution group.

Common super-trait for relationships (whether standard or generic) between global element declarations. Typically they are relationships between concepts. An element declaration relationship is either a eu.cdevreeze.tqa.base.model.StandardInterConceptRelationship or a eu.cdevreeze.tqa.base.model.NonStandardInterElementDeclarationRelationship.

This trait is rich enough to model both standard inter-concept relationships and potentially generic inter-concept relationships that make up concept relationship trees that are allowed according to XBRL table and formula specifications.

Item declaration. It must be in the xbrli:item substitution group, directly or indirectly.

Local attribute declaration. It is an xs:attribute element, but not a direct child element of the xs:schema root element.

Local element declaration. Like a global element declaration, it is an xs:element XML element with a name attribute. Unlike a global element declaration, it is not a child element of the xs:schema root element, but it is nested inside a type definition, for example. Unlike a global element declaration, it cannot have any substitution group, and therefore cannot be a concept declaration.

In an XBRL taxonomy, local element declarations are rare, if they occur at all. After all, most element declarations are global element declarations declaring item or tuple concepts, and tuple concept content models refer to other (item or tuple) concept declarations.

Locator node. It holds a unique key to a taxonomy element. It is an abstraction of what in the XML representation is an XLink locator, but then resolved as a key to a taxonomy element.

Model group, so either a sequence, choice or all model group.

Model group definition, so a top-level xs:group element with a name attribute.

Model group definition or model group reference.

Model group reference, so a non-top-level xs:group element with a ref attribute, referring to a model group definition.

Named complex type definition. It is a top-level xs:complexType element with a name attribute.

Super-type of schema components that have a name attribute.

Named simple type definition. It is a top-level xs:simpleType element with a name attribute.

Named type definition, so either a named complex type definition or a named simple type definition.

Any node that can be a relationship source or target in the model. There are 2 immediate sub-types: LocatorNode and ResourceNode (abstractions of XLink locators and XLink resources, respectively).

A LocatorNode is a unique key to a taxonomy element, and not the taxonomy element itself. This decoupling respects the fact that it is not known beforehand how relationships in taxonomies are traversed. ResourceNodes, on the other hand, are the taxonomy elements themselves.

Note that Nodes are easy to create on the fly, which is by design.

Any AppinfoContentElement not recognized as an instance of one of the other concrete AppinfoContentElement sub-types. This means that either this is valid schema content not modeled in the AppinfoContentElement sub-type hierarchy, or it is syntactically incorrect.

Any DocumentationContentElement not recognized as an instance of one of the other concrete DocumentationContentElement sub-types. This means that either this is valid schema content not modeled in the DocumentationContentElement sub-type hierarchy, or it is syntactically incorrect.

Any schema content element that is not even any standard schema content, any appinfo content element or any documentation content element. Probably this category refers to schema-invalid content.

Any StandardSchemaContentElement not recognized as an instance of one of the other concrete StandardSchemaContentElement sub-types. This means that either this is valid schema content not modeled in the StandardSchemaContentElement sub-type hierarchy, or it is syntactically incorrect. As an example of the latter, an xs:element XML element with both a name and a ref attribute is clearly invalid.

Particle (in the context of XML Schema), having optional minOccurs and maxOccurs attributes.

Primary item declaration. It must be in the xbrli:item substitution group but neither in the xbrldt:hypercubeItem nor in the xbrldt:dimensionItem substitution groups.

A primary item may be used as explicit dimension member.

Note that in the Dimensions specification, primary item declarations and domain-member declarations have exactly the same definition! Although in a taxonomy the dimensional relationships make clear whether an item plays the role of primary item or of domain-member, here we call each such item declaration a primary item declaration.

Super-type of schema components that are references.

Any '''relationship''' in the model.

This relationship type hierarchy knows about standard relationships, including dimensional relationships. It also knows about a few specific generic relationships. It does not know about table and formula relationships, which are only seen as non-standard relationships.

Each relationship is either a eu.cdevreeze.tqa.base.model.StandardRelationship or a eu.cdevreeze.tqa.base.model.NonStandardRelationship. There is no such thing as an UnknownRelationship in the model (such relationships would not be created, but just ignored, unlike their counterparts in the XML-backed relationship API).

Note that Relationship instances are easy to create on the fly, which is by design.

Relationship path. Subsequent relationships in the path must match in target/source node. Typically this is not restrictive enough, because normally the ELR must remain the same among the relationships (except for dimensional relationships).

A relationship path must have at least one relationship.

API for factories of relationships. This object does not depend on the Relationship types and companion objects.

Content (other than text) of a Resource, so not the Resource itself. It has no knowledge about its context, other than the ELR (for element key determination), so it should not be used in isolation from the containing Resource (with which it must share the same ELR).

This resource content model offers the yaidom ElemApi API.

Element key of a ResourceNode, or its content! It contains the ID, along with the ELR and element name. It is assumed that this combination is unique across resource content. Given that most label linkbase content uses the default ELR, this means that labels for the same concept/element but differing in language and resource role must all have unique IDs in the taxonomy.

Resource node. It is an abstraction of what in the XML representation is a taxonomy element that is an XLink resource. Note that each resource node that locators can point to is expected to have an ID.

An xs:restriction element.

Either a restriction or an extension.

Any '''taxonomy schema content element''' in the model. It is either standard schema content, which is a representation of an element in the XML Schema namespace, or it is appinfo content. The schema root element, and imports and linkbaseRefs are not represented in this model. Neither are the topmost annotation and their child appinfo or documentation elements.

This schema content model offers the yaidom SubtypeAwareElemApi API. Note, however, that most schema content elements have no child elements, but type definitions typically do have descendant elements.

Due to the fact that this schema model hardly contains any URI references, it plays no role in DTS discovery. Also note that this schema model has no knowledge about XLink.

Schema content in this model needs as little context as possible, although substitution group "knowledge" must be provided in order to determine in general whether a global element declaration is a concept (item or tuple) declaration.

Several kinds of schema content elements in this model are easy to refer to from relationships, as source or target. Note that these "links" are semantically meaningful, and need no URIs to point to them.

Schema content elements are relatively easy to create on the fly, and could be part of the basis for easy programmatic taxonomy creation. Note, however, that the taxonomy creation algorithm must at some point worry about closure with respect to DTS discovery, and about containing the needed substitution group ancestry.

When creating schema content elements on the fly, keep in mind that the element and its descendants should agree on the optional target namespace. This is not checked!

See http://www.datypic.com/sc/xsd for the XML Schema model (unaware of XBRL).

TODO Remove linkbaseRefs from model.

Element key of a SchemaContentElement. It contains the ID, along with the optional target namespace and the element name. It is assumed that this combination is unique across schema content elements.

API for factories of schema content elements. This object does not depend on the schema content types and companion objects.

Sequence model group, so an xs:sequence element.

An xs:simpleContent element.

Simple type definition, so either a named simple type definition or an anonymous simple type definition.

Representation of an element in the XML Schema namespace, but excluding the schema root element. More precisely, any child element of the schema root element that is not an xs:annotation and that is in the XML Schema namespace, or any of its desdendants in the XML Schema namespace (even xs:annotation).

Tuple declaration. It must be in the xbrli:tuple substitution group, directly or indirectly.

Type definition. It is either a complex or simple type definition, and it is also either a named or anonymous type definition.

Typed dimension declaration. It must be a dimension declaration with an attribute xbrldt:typedDomainRef, among other requirements.