ModelGroupGrammarMixin
Related Doc:
package grammar
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.
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.
For unit testing, we want to create GrammarMixin objects that are not schema components.
For unit testing, we want to create GrammarMixin objects that are not schema components. So we can't use a self-type here. Instead we define this abstract grammarContext.
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.
True if this term has initiator, terminator, or separator that are either statically present, or there is an expression.
True if this term has initiator, terminator, or separator that are either statically present, or there is an expression. (Such expressions are not allowed to evaluate to "" - you can't turn off a delimiter by providing "" at runtime. Minimum length is 1 for these at runtime.
Override in SequenceTermBase to also check for separator.
true if we can statically determine that the start of this will be properly aligned by where the prior thing left us positioned.
true if we can statically determine that the start of this will be properly aligned by where the prior thing left us positioned. Hence we are guaranteed to be properly aligned.
Use when we might or might not need the outputNewLine property
Use when we might or might not need the outputNewLine property
Changed to use findProperty, and to resolve the namespace properly.
Changed to use findProperty, and to resolve the namespace properly.
We lookup a property like escapeSchemeRef, and that actual property binding can be local, in scope, by way of a format reference, etc.
It's value is a QName, and the definition of the prefix is from the location where we found the property, and NOT where we consume the property.
Hence, we resolve w.r.t. the location that provided the property.
The point of findProperty vs. getProperty is just that the former returns both the value, and the object that contained it. That object is what we resolve QNames with respect to.
Note: Same is needed for properties that have expressions as their values. E.g., consider "{ ../foo:bar/.. }". That foo prefix must be resolved relative to the object where this property was written, not where it is evaluated. (JIRA issue DFDL-77)
Use when production has no guard, but you want to name the production anyway (for debug visibility perhaps).
Use when production has no guard, but you want to name the production anyway (for debug visibility perhaps).
Use when production has a guard predicate
Use when production has a guard predicate
Convenience method to make gathering up all elements referenced in expressions easier.
Convenience method to make gathering up all elements referenced in expressions easier.