[
https://issues.apache.org/jira/browse/UIMA-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664569#comment-13664569
]
Marshall Schor commented on UIMA-2917:
--------------------------------------
What happens after this fix, is that an ResourceInitializationException is
thrown, saying the 2 same-named types cannot be successfully merged.
What happened before this fix is that no checking was done, and the "first one"
in the merge set "wins", the others were ignored.
To your point of one type system making a restriction, and the other not -
let's see... the one not making a restriction would define a feature to be of
type "uima.cas.String"; the other would define it to be of type
"my.set.of.allowed.values", which, in turn is a subtype of uima.cas.String.
The current merge code requires feature range types to match, in all cases. So
type merging always throws an exception if one feature fff has a range type of
uima.cas.String in one definition of type TTT, and the other definition of type
TTT, feature fff has a range type of my.set.of.allowed.values. See the code in
CasCreationUtils, line 1683.
I hope I haven't misunderstood your case.
> Type System Merging for string subtypes with allowed values
> -----------------------------------------------------------
>
> Key: UIMA-2917
> URL: https://issues.apache.org/jira/browse/UIMA-2917
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 2.4.0SDK
> Reporter: Marshall Schor
> Priority: Minor
> Fix For: 2.4.1SDK
>
>
> UIMA uses type system merging to combine separately developed annotators and
> their type systems. When the same type is define in multiple type systems,
> perhaps with different features, these are "merged" where possible, and if
> not possible, exceptions are thrown. The current implementation is missing
> any support for merging subtypes of Strings - which UIMA uses for associating
> Allowed-Values for. If two type systems define the same-named subtype of
> String, no merging of allowed values is done, no exception is thrown if the
> allowed value sets are different, and the merge uses the first definition as
> the merge result, ignoring the others.
> The behavior could be changed to be "strict" - throwing an exception if the
> allowed values are not identical, or more lenient - for example, having the
> merged definition be the union of the the sets of allowed value. The
> drawback to the union approach is that any annotator which was assuming a
> "closed universe" of possible values, could now be seeing values not in the
> set it expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
