Support models with derived classes that constrain element types

[brynrhodes]

For models that support derived types with type constraints, and where the derived type is being represented as a class in the ModelInfo that maps to the underlying type, the compiler will already have ensured all type access is safe, so any unsafe access is because of: 1. An element in a derived class that has constrained the cardinality of a plural element to 1, so the element is singular in the model, but plural in the base 2. An element in a derived class that has constrained a choice type to a subset, possibly one, and the mapping is still being produced based on the underlying type

The first case is handled by retrieving the first element in the list and re-resolving based on the type of that element

The second case is handled by simply returning null since the element is not of the expected type

The correct solution here is to have the mapping be smarter about what it generates, taking base element types in to consideration, since the base element types are what will be manifest in the data access layer.

A change to the Context.resolveFunctionRef method would be able to address the issue generally by:

• If the function can't be resolved, and there is only one argument, and the function name starts with To
  • If the argument is a list, get the first item in the list and attempt to resolve again
  • Otherwise, return null, on the grounds that this is a conversion function

[brynrhodes]

Note that this issue is addressed much more cleanly by ensuring that resource instances passed out of the retrieve conform with the stated profile requirements. This is the approach currently taken, but it requires that input data declare it's profiles, so that basically, the engine is operating in a "profile-trusted" environment.