ChoiceDefMixin
Related Doc:
package dsom
Define this for schema components that have back-references to ref objects.
Define this for schema components that have back-references to ref objects. So group def to group ref, globalelementdecl to element ref, type to element, base type to derived type.
Not for format annotations however. We don't backpoint those to other format annotations that ref them.
Anything annotated must be able to construct the appropriate DFDLAnnotation object from the xml.
Anything annotated must be able to construct the appropriate DFDLAnnotation object from the xml.
The DFDL annotations on the component, as objects that are subtypes of DFDLAnnotation.
The DFDL annotations on the component, as objects that are subtypes of DFDLAnnotation.
Override to perform necessary checks that require information about the concrete Term.
Override to perform necessary checks that require information about the concrete Term.
This avoids the need for the checking code to have a backpointer to the Term.
check for overlap.
check for overlap.
Perform checking of an object against the supplied Term arg.
Perform checking of an object against the supplied Term arg.
Abbreviation.
Abbreviation. We use this very often.
Here we establish an invariant which is that every annotatable schema component has, definitely, has an annotation object.
Here we establish an invariant which is that every annotatable schema component has, definitely, has an annotation object. It may have no properties on it, but it will be there. Hence, we can delegate various property-related attribute calculations to it.
To realize this, every concrete class must implement (or inherit) an implementation of emptyFormatFactory, which constructs an empty format annotation, and isMyFormatAnnotation which tests if an annotation is the corresponding kind.
Given that, formatAnnotation then either finds the right annotation, or constructs one, but our invariant is imposed. There *is* a formatAnnotation.
The enclosing component, and follows back-references from types to their elements, from globalElementDef to elementRefs, from simpleType defs to derived simpletype defs, from global group defs to group refs
The enclosing component, and follows back-references from types to their elements, from globalElementDef to elementRefs, from simpleType defs to derived simpletype defs, from global group defs to group refs
Note: the enclosing component of a global element or global group referenced from a element ref or group ref, is NOT the ref object, but the component that contains the ref object
All schema components except the root have an enclosing element.
All schema components except the root have an enclosing element.
Elements that enclose this.
Elements that enclose this.
If this is already an element, this still walks outward to find the next tier out.
The terms that can enclose this.
The terms that can enclose this.
Even if this is already a term, this walks outward to find those enclosing this.
Returns the group members that are elements or model groups.
Returns the group members that are elements or model groups.
Whether the component is hidden.
Whether the component is hidden.
Override this in the components that can hide - SequenceGroupRef and ChoiceGroupRef
Annotations can contain expressions, so we need to be able to compile them.
Annotations can contain expressions, so we need to be able to compile them.
We need our own instance so that the expression compiler has this schema component as its context.
Namespace scope for resolving QNames.
Namespace scope for resolving QNames.
We insist that the prefix "xsi" is properly defined for use in xsi:nil attributes, which is how we represent nilled elements when we convert to XML.
Used as factory for the XML Node with the right namespace and prefix etc.
Used as factory for the XML Node with the right namespace and prefix etc.
Given "element" it creates <dfdl:element /> with the namespace definitions based on this schema component's corresponding XSD construct.
Makes sure to inherit the scope so we have all the namespace bindings.
Combine our statements with those of what we reference.
Combine our statements with those of what we reference. Elements reference types ElementRefs reference elements, etc.
The order here is important. The statements from type come first, then from declaration, then from reference.
path is used in diagnostic messages and code debug messages; hence, it is very important that it be very dependable.
path is used in diagnostic messages and code debug messages; hence, it is very important that it be very dependable.
For property combining only.
For property combining only. E.g., doesn't refer from an element to its complex type because we don't combine properties with that in DFDL v1.0. (I consider that a language design bug in DFDL v1.0, but that is the way it's defined.)
All non-terms get runtimeData from this definition.
All non-terms get runtimeData from this definition. All Terms which are elements and model-groups) override this.
The Term class has a generic termRuntimeData => TermRuntimeData function (useful since all Terms share things like having charset encoding) The Element classes all inherit an elementRuntimeData => ElementRuntimeData and the model groups all have modelGroupRuntimeData => ModelGroupRuntimeData.
There is also VariableRuntimeData and SchemaSetRuntimeData.
Elements only e.g., /foo/ex:bar
Elements only e.g., /foo/ex:bar
This is the root, or basic target namespace.
This is the root, or basic target namespace. Every schema component gets its target namespace from its xmlSchemaDocument.
Used in diagnostic messages; hence, valueOrElse to avoid problems when this can't get a value due to an error.
Used in diagnostic messages; hence, valueOrElse to avoid problems when this can't get a value due to an error.
Captures concepts common to all choice definitions, which includes both local and global choice definitions, but not choice group references.
Choices are a bit complicated.
They can have initiators and terminators. This is most easily thought of as wrapping each choice inside a sequence having only the choice inside it, and moving the initiator and terminator specification to that sequence.
That sequence is then the term replacing the choice wherever the choice is.
Choices can have children which are scalar elements. In this case, that scalar element behaves as if it were a child of the enclosing sequence (which could be the one we just injected above the choice.
Choices can have children which are recurring elements. In this case, the behavior is as if the recurring child was placed inside a sequence which has no initiator nor terminator, but repeats the separator specification from the sequence context that encloses the choice.
All that, and the complexities of separator suppression too.
There's also issues like this:
<choice> <element .../> <sequence/> </choice>
in the above, one alternative is an empty sequence. So this choice may produce an element which takes up a child position, and potentially requires separation, or it may produce nothing at all.