dsom
For the DFDL path/expression language, this provides the place to type check the expression (SDE if not properly typed) and provides the opportunity to compile it for efficient evaluation.
This class is to contain only things that are needed to do DPath Expression Compilation.
This class is to contain only things that are needed to do DPath Expression Compilation. Nothing else.
This exists because some things have to be compiled (e.g., DPath expressions) which then become part of the runtime data for elements or other.
It becomes circular if all the information is bundled together on the RuntimeData or ElementRuntimeData objects. So we split out everything needed to compile expressions will get computed separately (first), and kept on this object, and then subsequently ERD data structures are created which reference these.
In other words, it's just necessary layering of the different phases of computation.
Some of this dependency is artificial. If every individual attribute was computed separately, none bundled together in common data structures, AND everything was computed lazily, then this would probably all just sort itself out and not be circular. What makes the circularity is that the runtime data structures (ElementRuntimeData in particular), are not lazy. Everything part of them is forced to be evaluated when those are constructed. So anything that needs even one member of an ERD is artificially dependent on *everything* in the ERD.
Similarly these DPath compiler data structures.... anything that depends on them is artificially dependent on ALL of their members's values.
So the separation of DPath compiler info from runtime data structures is really as close as we get in Daffodil to organizing the compilation of schemas into "passes".
This class is to contain only things that are needed to do DPath Expression Compilation.
This class is to contain only things that are needed to do DPath Expression Compilation. Nothing else.
This exists because some things have to be compiled (e.g., DPath expressions) which then become part of the runtime data for elements or other.
It becomes circular if all the information is bundled together on the RuntimeData or ElementRuntimeData objects. So we split out everything needed to compile expressions will get computed separately (first), and kept on this object, and then subsequently ERD data structures are created which reference these.
Technique for analyzing and combining charset encoding information uses a lattice.
Technique for analyzing and combining charset encoding information uses a lattice. Top of lattice means "conflicting" information. Bottom of lattice is "no information" and points in between have specific amounts of information. Basic operation is combine two values of the lattice to move up the lattice toward the Top.
Means we have a named encoding.
Specific class used for this specific error, because we need to pick this off in the debugger for special handling.
Contains binary data (only)
This is the Top value for the lattice of knowledge about encodings.
This is the Top value for the lattice of knowledge about encodings. Mixed as in multiple different encodings or a mixture of binary and text data, or some things not known until runtime.
NoText is the bottom of the lattice.
NoText is the bottom of the lattice. We have no information here. Means the item could have text, but just so happens to not have any, so regardless of what it's encoding is, it doesn't interfere with contained children and parents having a common encoding. Example: A sequence with no alignment region, and no delimiters. It's not binary, it has no text. It's nothing really.
Means the encoding is determined via a runtime expression.
For the DFDL path/expression language, this provides the place to type check the expression (SDE if not properly typed) and provides the opportunity to compile it for efficient evaluation.
The schemaNode is the schema component where the path is being evaluated which due to scoping, may not be the same one where it is defined. It is the combination of a property valued expression with a schema node that defines an evaluation of an expression.
TODO: Consider - that an expression could be constant in some contexts, not others. E.g., if a DFDL schema defines a format where the delimiters are in a header record, then those are constant once you are parsing the body records. This does imply keeping around the xpath compiler at runtime, which may not be desirable from a code size perspective. Whether it's worth it to compile or not is also a question of how often each xpath will be repeated.
TODO: provide enough scope information for this to optimize.