uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie Epstein <eaepst...@gmail.com>
Subject Re: working on a significant re-write of the result specification impl
Date Thu, 19 Aug 2010 01:18:15 GMT
My 2 cents

On Wed, Aug 18, 2010 at 2:33 PM, Marshall Schor <msa@schor.com> wrote:
>  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.

Result specs not sent to services.

>
> 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.

I'd opt for containsType(typeZZZ-FeatYY) being true and the reverse
direction being false, but neither strongly enough to do anything
about it :)

Mime
View raw message