[
https://issues.apache.org/jira/browse/UIMA-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470798#comment-17470798
]
Michael Stenger commented on UIMA-6408:
---------------------------------------
I see where you are coming from. I was thinking about cases where - and may it
even be by chance - the two types on which TRANSFER is applied share a feature,
i.e. ID, but of a different data type, and the rule engineer intentionally
wants to transfer all features but ID. I was thinking of outputting a warning
and transfer what's matching, i.e. STRING -> STRING, ANNOTATION -> ANNOTATION,
etc.
I can work with your "hard" feedback approach, too. That's fine. There should
be a work-around for the above cases with CREATE. But the inconsistency problem
remains: For some data types, no implicit casting is done where I'd suspect it
and instead, the exception mentioned in my description is thrown. I checked it
again and it looks like it is mainly related to array features like
StringArray, BooleanArray, FSArray, etc. My choice of example was poor in that
regard, apologies.
Another one:
{noformat}
DECLARE T1 (BooleanArray feat);
DECLARE T2 (StringArray feat);
DECLARE T3 (BOOLEAN feat);
"This"{-> CREATE(T1, "feat" = {true, false, true})};
T1 {-> TRANSFER(T2)}; // RuntimeException
"is" {-> CREATE(T3, "feat" = true)};
T3 {-> TRANSFER(T1)}; // RuntimeException{noformat}
Primitive types seem to be converted into one another as one would expect.
> Ruta: No type check of features in TRANSFER
> -------------------------------------------
>
> Key: UIMA-6408
> URL: https://issues.apache.org/jira/browse/UIMA-6408
> Project: UIMA
> Issue Type: Bug
> Components: Ruta
> Affects Versions: 2.8.1ruta, 3.1.0ruta
> Reporter: Michael Stenger
> Assignee: Peter Klügl
> Priority: Minor
> Fix For: 2.9.0ruta, 3.1.1ruta
>
>
> Hi again.
> I think there is a bug in action TRANSFER when it comes to transferring - or
> better not transferring - values from a feature of kind A to a feature of
> type B, where both features have the same identifier. Such an attempt throws
> an exception in cases where values cannot implicitly be converted. An example:
> Text:
> {noformat}
> alpha beta{noformat}
> Script:
> {noformat}
> DECLARE T1 (Annotation a, STRING ID);
> DECLARE T2 (STRING a, INT ID);
> w:"alpha" {-> CREATE(T1, "a" = w, "ID" = "3ef9")};
> T1 {-> TRANSFER(T2)};{noformat}
> Expected output (new annotations):
> * {type: T2, begin: 0, end:5, features:{}}
> But throws:
> {noformat}
> org.apache.uima.cas.CASRuntimeException: Trying to access value of feature
> "Main.T2:a" as "uima.cas.String", but range of feature is
> "org.apache.uima.ruta.type.RutaBasic".{noformat}
> My suggestion is to only transfer values between features if they are of the
> same kind, for consistency's sake.
> Best, Michael
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
