uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: working on a significant re-write of the result specification impl
Date Wed, 18 Aug 2010 18:33:28 GMT
 Eddie's post provided motivation for me to actually write test cases :-)

Here's a couple of things that the current impl may not do correctly:

* There is serialization and deserialization available for the
ResultSpecification.  A remote component may get this information (I didn't
check our impl to see if this is being sent now).  However, the serialization
only supports the part of the result specification associated with no language
(or x-unspecified); language specific information is missing.

For the rest of this note, assume
  typeXXX, typeZZZ subtype of typeXXX
  typeXXX:featYYY is a feature introduced in the upper typeXXX,
                  and available (via inheritance of features) in the subtype typeZZZ

* The result specification may have typeXXX:featYYY.  Since typeZZZ is a subtype
of typeXXX, it contains (via inheritance) featYYY.  So, it would seem that
containsFeature(typeYYY:FeatYYY) should return true.  However it currently
returns false.  It seems to me that it should return true, analogous to this
similar case involving just types:

  typeXXX in the result specification,
  containsType(TypeZZZ) is true (because it's a subtype; this is how it is
working in the current impl).

Other opinions?

In the reverse direction:
  typeZZZ:featYYY in result specification,
  containsFeature(typeXXX:featYYY) returns false in the current impl.

Is this correct?  The argument for returning false would be that the result
specification is asking for featYYY on typeZZZ (and subtypes of it), but not on
any supertypes of typeZZZ which have that feature.  The argument for returning
true is that the feature is independent of how it is "spelled"; e.g., the
feature named typeXXX:featYYY is identical with the one named typeZZZ:featYYY.


On 8/17/2010 5:16 PM, Eddie Epstein wrote:
> We got into this because there was a glaring problem with
> x-unspecified, and you have fixed that. Then you started finding more
> obscure problems. If your "2nd try" implementation doesn't add any new
> problems to what was previously there, is it worth more fixing?
> Eddie
> We got into this because there was a glaring problem with x-unspecified.
> On Tue, Aug 17, 2010 at 3:17 PM, Marshall Schor <msa@schor.com> wrote:
>>  update:
>> While trying to fix the last Jira against the Result Spec, I've come up with
>> lots of corner cases, and addressing these with the current implementation looks
>> quite complex, especially with the current impl.
>> So I'm taking a run at simplifying things for the impl.  It's quite hard to
>> figure out the right semantics that handle all the corner cases properly, and
>> I'm on my 3rd try :-) - but each try is giving a better result...
>> I am mindful that result specification handling was a performance issue in
>> earlier implementations, and am hoping to have a well performing impl.
>> Just wanted folks to know I'm still working on this - it may take a while, and
>> I'll be doing a lot more test cases :-).
>> Cheers. -Marshall

View raw message