Decide on whether we need Value

[ewoutkramer]

Although it sounds like we do, there might actually be a better way to get at the value. Consider: not every node has a value, since not every node is a primitive. Just like not every node is comparable or not every node is bindeable. It is probably better to have the nodes that have any of these traits to implement an explicit interface. E.g. we could have a totally separate interface IPrimitiveData, just like the nodes might implement IComparable. FhirPath and the validator really ever hardly need to inspect the values, and certainly, if these values involve parsing or conversions (e.g. from POCO values to CQL values), we shouldn't do it by default.

We might even consider expecting any leaves in a tree to always be a POCO, preferably the ones we have defined for primitives. Why would an ElementNode tree not use POCO's in its leaves? It would automatically profit from the equality, comparisons and other features of those pocos, instead of defining them again in terms of ITypedElement (as is the current situation).

[ewoutkramer]

The chosen solution is as described above:

• The leaves will be existing, known datatypes, so comparison operators are available.
• And so is type information
• And so is the value, original text.

We also decided to not have "value" represented explicitly as a key.

See also #2781 and #2963.