uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject What should our design be when features which are arrays with element types are merged?
Date Mon, 19 Nov 2007 16:43:29 GMT
Background: Working on https://issues.apache.org/jira/browse/UIMA-529

Consider two definitions of an FSarray feature, one of which declares an
element type, and the other which does not.  The element type is optional. 

One use case:  FSArrays are specified without element types in some
"legacy" descriptor, done before we had this capability.  Later, that
component is used with more recent ones, having an element type specified.

It seems to me, in this case, we might want to allow merging these two
without error.   If a subsequent 3rd instance of this feature specified
a non-conforming element type, then we could signal an error.

The comment on the issue 529 implies to allow merging only if the the
element type is "uima.cas.TOP".  That is the other alternative.

I think we do have a choice here, because the current code requires the
two element types being merged to be equal, so currently the test is
more strict that perhaps it needs to be.

Another use-case: One component declares an FSArray of type Foo, which
is in turn a subtype of Annotation.  Another component declares the same
element to be of type Annotation (which subsumes Foo).   We could
"merge" these two types, by having the resulting type be of the more
restrictive type (Foo).  This would allow a general component to process
arrays of more specific things.  Should we do this?

Thanks for your considered opinions on this.

-Marshall (considering alternatives for "fixing" issue  529)




Mime
View raw message