Couldn't the (XMI) deserializer handle that locally as part of the deserialization instead of having to pass some context parameter down into the bowels of the framework?
Cheers, -- Richard > On 08.09.2016, at 10:23, Peter Klügl <[email protected]> wrote: > > sounds good to me > > Peter > > > Am 07.09.2016 um 22:45 schrieb Marshall Schor: >> 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
