In this case, the original looks kind-of like this: Container features -> FSArray of FeatureAnnotation each of which has 5 slots: sofaRef, begin, end, name, value
the new TypeSystem has Container features -> FSArray of FeatureRecord each of which has 2 slots: name, value The deserializer code would need some way to decide how to 1) create an FSArray of FeatureRecord, 2) for each element, map the FeatureAnnotation to a new instance of FeatureRecord I guess I could imagine a default mapping (for item 2 above) of 1) change the type from A to B 2) set equal-named features from A to B, drop other features This mapping would need to apply to a subset of the A's and B's, namely, only those referenced by the FSArray where the element type changed. Seems complex and specific to this use case though. -Marshall On 9/16/2019 2:42 PM, Richard Eckart de Castilho wrote: > On 16. Sep 2019, at 19:05, Marshall Schor <[email protected]> wrote: >> I can reproduce the problem, and see what is happening. The deserialization >> code compares the two type systems, and allows for some mismatches (things >> present in one and not in the other), but it doesn't allow for having a >> feature >> whose range (value) is type XXXX in one type system and type YYYY in the >> other. >> See CasTypeSystemMapper lines 299 - 315. > Without reading the code in detail - could we not relax this check such that > the element type of FSArrays is not checked and the code simply assumes that > the source element type has the same features as the target element type > (with the usual lenient handling of missing features in the target type)? - > Kind of a "duck typing" approach? > > Cheers, > > -- Richard
