With version 2.8.1 and 2.9.0, some tightening and clarification of error messages occurred around attempts to add a FS (Feature Structure) to indexes.
In particular, a FS which is a subtype of AnnotationBase can only be added to the view which corresponds to the view specified by the sofaRef feature that comes with AnnotationBase. This has tripped up some users, who are slowly evolving their type system, in the presence of some previously serialized data. They were using xmi serialization, and normal evolution of type systems that merely adds or subtracts features works fine (if in lenient mode for the "subtracts" case). Features added are given default values - usually null or 0 - if not specified in the xmi serialization. This fails, though, for changing a type's supertype from, e.g., TOP to Annotation, which adds the new sofaRef feature. The deserialization happens ok, setting the new feature to null, but if that instance is indexed, the new, tightened checks at add-to-index time throw an exception because the sofaRef (value is null) doesn't match that of the Cas View. We could detect this as a "special case", and if some context flag was set (say by xmi deserialization going on), we could, if the sofaRef was null, set it to the presumably correct value (corresponding to the view it was being indexed in). Does this sound like a good thing to do? -Marshall
