uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Lally" <ala...@alum.rpi.edu>
Subject Re: Default Result Specifications too complicated?
Date Tue, 12 Jun 2007 15:18:34 GMT
On 6/11/07, Michael Baessler <mba@michael-baessler.de> wrote:
> OK, for the next release I think we have to possibilities...
> 1) we implement the SimpleStepWithResultSpec function to fix the
> capabilityLanguageFlow as it was in UIMA 1.4. This allows UIMA 1.4 users
> that use the capabilityLanguageFlow to migrate to Apache UIMA 2.2.
> 2) we do not implement the SimpleStepWithResultSpec and remove the
> capabilityLanguageFlow completely since it has not the same
> functionality as in UIMA 1.4. So
>  users that want to migrate see that they cannot use this functionality
> with Apache UIMA 2.2 and have to implement their own flow based on their
> type system. But this would break user code that is based on the
> capabilityLanguageFlow.
> Using the capabilityLanguageFlow code with a different flow name will
> also be possible, but I don't think that this helps us in our decision.

I think leaving things the way they are is also an option to consider.
 capabilityLanguageFlow still works in many cases (as evidenced by the
fact that our test cases still pass).

While adding a SimpleStepWithResultSpec is a possibility for backwards
compatibility, I'm really not that happy with that idea going forward,
since it encourages people to build applications that rely on Result
Specifications.  I think Result Specifications should only be a
performance optimization.  Since only a handful of annotators in the
world pay attention to their Result Spec at all, I think it's not a
very good idea for applications to rely on them.  In your example, if
the second annotator produces tokens will this be just a performance
problem or will the application actually break?

An alternative way of doing things would be for the second annotator
to check for existence of tokens before creating more tokens.  This
requires special support in the annotator, certainly, but so does
requiring the annotator to pay attention to its result spec, so I
don't think we are any worse off.


View raw message