provided by ElementBase for array considerations, and GlobalElementDecl - scalar only
provided by ElementBase for array considerations, and GlobalElementDecl - scalar only
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.
Means the infoset element could have varying length.
Means the infoset element could have varying length.
And that means if there is a specified length box to fit it into that we have to check if it is too big/small for the box.
So that means hexBinary, or representation text (for simple types) or any complex type unless everything in it is fixedLengthInfoset.
So for example, a complex type containing only fixed length binary integers is itself fixed length.
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 padding will be inserted for this delimited element when unparsing.
true if padding will be inserted for this delimited element when unparsing.
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.
Fixed length, or variable length with explicit length expression.
Fixed length, or variable length with explicit length expression.
Only strings can be truncated, only if they are specified length, and only if truncateSpecifiedLengthString is 'yes'.
Only strings can be truncated, only if they are specified length, and only if truncateSpecifiedLengthString is 'yes'.
Note that specified length might mean fixed length or variable (but specified) length.
parsingPadChar is the pad character for parsing unparsingPadChar is the pad character for unparsing These are always carried as MaybeChar.
parsingPadChar is the pad character for parsing unparsingPadChar is the pad character for unparsing These are always carried as MaybeChar.
We need both, because in the same schema you can have textPadKind="padChar" but textTrimKind="none", so there can't be just one pad char object if it is to carry information about both whether or not a pad character is to be used, and the value.
Use when we might or might not need the outputNewLine property
Use when we might or might not need the outputNewLine property
Means the specified length must, necessarily, be big enough to hold the representation so long as the value in the infoset is legal for the type.
Means the specified length must, necessarily, be big enough to hold the representation so long as the value in the infoset is legal for the type.
This does not include numeric range checking. So for example if you have an xs:unsignedInt but length is 3 bits, this will be true even though an integer value of greater than 7 cannot fit.
Another way to think of this is that legal infoset values will have fixed length representations.
This is a conservative analysis, meaning if true the property definitely holds, but if false it may mean we just couldn't tell if it holds or not.
If this is true, then we never need to check how many bits were written when unparsing, because we know a legal value has to fit. If the value is illegal then we'll get an unparse error anyway.
If this is false, then it's possible that the value, even a legal value, might not fit if the length is specified. We're unable to prove that all legal values WILL fit.
A critical case is that fixed length binary integers should always return true here so that we're not doing excess length checks on them Or computing their value length unnecessarily.
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)
parsingPadChar is the pad character for parsing unparsingPadChar is the pad character for unparsing These are always carried as MaybeChar.
parsingPadChar is the pad character for parsing unparsingPadChar is the pad character for unparsing These are always carried as MaybeChar.
We need both, because in the same schema you can have textPadKind="padChar" but textTrimKind="none", so there can't be just one pad char object if it is to carry information about both whether or not a pad character is to be used, and the value.
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.
We add fill to complex types of specified length so long as length units are bytes/bits.
We add fill to complex types of specified length so long as length units are bytes/bits. If characters then "pad" puts the characters on.
We also add it to text elements of variable specified length again, unless length units are in characters.
Quite tricky when we add padding or fill
Quite tricky when we add padding or fill
For complex types, there has to be a length defined. That's it.
For simple types, we need the fill region processors to detect excess length
Check for excess length if it's variable length and we cannot truncate it.
Mandatory text alignment or mta
Mandatory text alignment or mta
mta can only apply to things with encodings. No encoding, no MTA.
In addition, it has to be textual data. Just because there's an encoding in the property environment shouldn't get you an MTA region. It has to be textual.