This is technically not wrong and the information about the element type in the array should usually be accessible through the definition of the feature which references the array - however, we can currently not serialize this.
To Reproduce
See test tsv3-testSimpleSlotFeature.
Expected behavior
Optimally, it should be serialized in the same was as it was loaded. Java UIMA v3 reifies array types in the type system - so instead of only an FSArray, it dynamically creates types like FSArray<LinkType> and binds the FSArray to that - so we have access to the array element type without having to look at the feature it is referenced from. This is particularly useful for arrays which are shared and can be referenced from multiple features (with potentially different yet compatible element type definitions).
However, it seems this won't be trivial to fix in the Python implementation and would require also introducing dynamic array types.
Describe the bug When cassis is parsing an array like this:
it is serialized again as:
This is technically not wrong and the information about the element type in the array should usually be accessible through the definition of the feature which references the array - however, we can currently not serialize this.
To Reproduce See test
tsv3-testSimpleSlotFeature
.Expected behavior Optimally, it should be serialized in the same was as it was loaded. Java UIMA v3 reifies array types in the type system - so instead of only an
FSArray
, it dynamically creates types likeFSArray<LinkType>
and binds the FSArray to that - so we have access to the array element type without having to look at the feature it is referenced from. This is particularly useful for arrays which are shared and can be referenced from multiple features (with potentially different yet compatible element type definitions).However, it seems this won't be trivial to fix in the Python implementation and would require also introducing dynamic array types.
Please complete the following information: