[
https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261891#comment-13261891
]
Adam Lally edited comment on UIMA-2391 at 4/25/12 6:23 PM:
-----------------------------------------------------------
Currently, code using the core type system can rely on the fact that instances
of the Type can only ever be a, b, or c. They can be used like enums in this
way. If we implement merging this way we would break that. Are we sure we
want to do that? Code built off the core type system would not be expecting a
value "d" and might not know what to do with it.
An analogous case might be - what happens if I merge two type systems that
define the same type with the same named feature (call it Foo.bar) but
different range types. In type system 1, Foo.bar has range type A and in type
system 2 it has range type B. Would you want to say that in the merged type
system, Foo.bar could be A or B? Probably not.
Or course, I might just be biased against extending the scope of type merging
since I was never happy it existed in the first place. :)
was (Author: alally):
Currently, code using the core type system can rely on the fact that
instances of the Type can only ever be a, b, or c. They can be used like enums
in this way. If we implement merging this way we would break that. Are we
sure we want to do that? Code built off the core type system would not be
expecting a value "d" and might not know what to do with it.
An analogous case might be - what happens if I merge two type systems that the
same type with the same named feature (call it Foo.bar) but different range
types. In type system 1, Foo.bar has range type A and in type system 2 it has
range type B. Would you want to say that in the merged type system, Foo.bar
could be A or B? Probably not.
Or course, I might just be biased against extending the scope of type merging
since I was never happy it existed in the first place. :)
> Uima type merging for string subtypes not working
> -------------------------------------------------
>
> Key: UIMA-2391
> URL: https://issues.apache.org/jira/browse/UIMA-2391
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 2.3.1AS
> Environment: Linux on Power
> Reporter: Charles de Saint-Aignan
> Priority: Critical
>
> The basic situation is that we are providing a UIMA-based core that other
> teams can extend to suit their needs. As such we are making use of UIMA type
> merging to allow them to add new features to existing types. This approach
> works fine since JCasGen merges the two definitions of the given type and
> produces a superset of the features. This is well documented here:
> http://uima.apache.org/d/uimaj-2.3.1/references.html#ugr.ref.jcas.merging_types.jcasgen_support
>
> However, in addition to this, we have the case where we have a string subtype
> with given allowedValues - lets say values a, b and c. The other team wants
> to extend this type and have additional allowedValues, say value d. Ideally,
> what I would like to do is the following (which follows the pattern used for
> adding features):
> Type Definition #1 (provided by core):
> <typeDescription>
> <name>com.ibm.Type</name>
> <description></description>
> <supertypeName>uima.cas.String</supertypeName>
> <allowedValues>
> <value>
> <string>a</string>
> <description></description>
> </value>
> <value>
> <string>b</string>
> <description></description>
> </value>
> <value>
> <string>c</string>
> <description></description>
> </value>
> </allowedValues>
> </typeDescription>
> Type Definition #2 (extension to core):
> <typeDescription>
> <name>com.ibm.Type</name>
> <description></description>
> <supertypeName>uima.cas.String</supertypeName>
> <allowedValues>
> <value>
> <string>d</string>
> <description></description>
> </value>
> </allowedValues>
> </typeDescription>
> In this case I wanted UIMA to recognize the two definitions at runtime and
> allow the superset of allowedValues. However, this does not do the trick -
> at runtime UIMA throws an exception saying that value d is not an allowed
> value for com.ibm.Type.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
