(rephrase the title of this task once the particular solution to take is decided)
Problem:
When normalizing a canonical representation of a typed list, the type which will be the value of Z881K1 is extracted from the type of the elements found in that list.
Take this example:
"Z1K1": "Z8", "Z8K3": [] // Empty list of testers/Z20
Because the array is empty, it would be normalized into a typed list Z881(Z1), which is not exactly correct but our validator can handle that.
However, when the testers are objects that resolve to something else (Z9, Z7 or Z18s)
"Z1K1": "Z8", "Z8K3": [ "Z100006" ] // Z100006 is a tester
The resulting type is Z881(Z9), and this is incorrect and our validator is crashing.
Solutions
- We remove checking content of Z881K1 in function-schemata: means rolling back a lot of work.
- We add Z9 and Z7 to the enums that validate the content of Z881K1, so for example Z8K3 would pass as valid a list with Z88K1 set to Z1, Z7, Z9 or Z20: this is a fix and ultimately we would be tagging as valid something that's not.
- We add type information to the canonical lists, so that this doesn't happen when normalizing: we should do this, not sure when, but some day.
- Whenever we do normalize an array into a typed list, and we see Z9ns or Z7s in the list, we set it to Z1 instead of Z9 or Z7
4.a.) Whenever we do normalize an array into a typed list, and we see Z9ns or Z7s in the list, we don't set it to Z9 or Z7 unless we know nothing else, in which case Z1.
- When we normalise an array to a typed list, we use the context of what type it's meant to be (parent type) to check each Z9/Z7/Z18.
- Ongoing discussion **
The team agrees that (3) must be implemented as a long-term solution, but in the meantime, we can avoid mistyping typed lists by modifying the logic that infers the type of the elements given an array of zobjects (4.a)