The contract here supports the semantics of "." in paths.
The contract here supports the semantics of "." in paths.
If this is an element we're done. If not we move outward until we reach an enclosing element.
The contract here supports the semantics of ".." in paths.
The contract here supports the semantics of ".." in paths.
First we establish the invariant of being on an element. If the schema component is an element we're there. Otherwise we move outward until we are an element. If there isn't one we return None
Then we move outward to the enclosing element - and if there isn't one we return None. (Which most likely will lead to an SDE.)
Finds a child ERD that matches a StepQName.
Finds a child ERD that matches a StepQName. This is for matching up path steps (for example) to their corresponding ERD.
TODO: Must eventually change to support query-style expressions where there can be more than one such child.
The immediate containing parent.
The immediate containing parent.
Stores whether or not this element is used in any path step expressions during schema compilation.
Stores whether or not this element is used in any path step expressions during schema compilation. Note that this needs to be a var since its value is determined during DPath compilation, which requires that the DPathElementCompileInfo already exists. So this must be a mutable value that can be flipped during schema compilation.
Note that in the case of multiple child element decls with the same name, we must make sure ALL of them get this var set.
This is done on the Seq returned when findNameMatches is called.
Issues a good diagnostic with suggestions about near-misses on names like missing prefixes.
relative path - relative to enclosing element's path which by definition must be a prefix of this object's path.
relative path - relative to enclosing element's path which by definition must be a prefix of this object's path.
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.