NodeInfo
Related Doc:
package dpath
Combines the constraint of Exists with AnySimpleType.
Combines the constraint of Exists with AnySimpleType. I.e, must be an element that exists and is of simple type.
This is intended to express the type that must be a path to a simple type element. That is, /foo/bar where bar is an element of simple type, but not "foobar" which is a string literal of simple type. The path /foo/bar might be to an element bar with string value "foobar", but we want to distinguish between a string like "foobar" the value and /foo/bar a path to an element of type string.
Intended for use in dfdl:valueLength, which takes a path, but only to a simple element.
It might be possible to combine AnySimpleType and AnyAtomic, but both terminologies are used.
It might be possible to combine AnySimpleType and AnyAtomic, but both terminologies are used. In DFDL we don't talk of Atomic's much, but lots of XPath and XML Schema materials do, so we have these two types that are very similar really.
There is a type union feature in DFDL, and perhaps the difference between AnyAtomic and AnySimpleType is that AnySimpleType admits XSD unions and list types, where AnyAtomic does not?
AnyType is the Top of the type lattice.
AnyType is the Top of the type lattice. It is the super type of all data types except some special singleton types like ArrayType.
An isolated singleton "type" which is used as a target type for the indexing operation.
An isolated singleton "type" which is used as a target type for the indexing operation.
All complex types are represented by this one type object.
All complex types are represented by this one type object.
For things like fn:exists, fn:empty, dfdl:contenLength
For things like fn:exists, fn:empty, dfdl:contenLength
There is nothing corresponding to NillableKind in the DFDL/XML Schema type hierarchy.
There is nothing corresponding to NillableKind in the DFDL/XML Schema type hierarchy. We have it as a parent of both complex type and simple type since both of them can be nillable.
NonEmptyString is used for the special case where DFDL properties can have expressions that compute their values which are strings, but those strings aren't allowed to be empty strings.
NonEmptyString is used for the special case where DFDL properties can have expressions that compute their values which are strings, but those strings aren't allowed to be empty strings. Also for properties that simply arent allowed to be empty strings (e.g. padChar).
Nothing is the bottom of the type lattice.
Nothing is the bottom of the type lattice.
It is the return type of the daf:error() function. It's a subtype of every type (except some special singletons like ArrayType).
The PrimType objects are a child enum within the overall NodeInfo enum.
A NodeInfo.Kind describes what kind of result we want from the expression. E.g., a + b we want numbers from both a and b expressions. In /a/b we want a "complex" node from the expression a, and a value from the expression b. But fn:exists(../a/b) we need complex node a so that we can test if b exists. In case of a[b] for b we need a value, but furthermore an array index, so 1..n.
Functions motivate some of the options here. e.g., fn:nilled( exp ) is the test for a nilled value. There we want an expression to something that is nillable.
This same Kind is also used to describe the inherent value (bottom up) of an expression. So a literal "foo" is of string kind, whereas 5.0 is Numeric
The nested objects here allow one to write NodeInfo.Kind (type of any of these enums) NodeInfo.Number.Kind (type of just the number variants) NodeInfo.Value.Kind (type of just the value variants) The enums themselves are just NodeInfo.Decimal (for example)
Note that you can talk about types using type node objects: E.g., NodeInfo.Number. But you can also use Scala typing to ask whether a particular type object is a subtype of another: e.g.
So each NodeInfo object has a corresponding class (named with .Kind suffix) which is actually a super-type (in Scala sense) of the enums for the types beneath.The primary advantage of the latter is that this is a big bunch of sealed traits/classes, so if you have a match-case analysis by type, scala's compiler can tell you if your match-case exhausts all possibilities and warn you if it does not.