uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kl├╝gl <peter.klu...@averbis.com>
Subject Re: type system evolution and should deserialization accommodate missing sofa refs?
Date Thu, 08 Sep 2016 08:23:43 GMT
sounds good to me


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

View raw message