While experimenting with this approach, I found some tests wouldn't
run. (By the way, the test cases are great - they have been a great
help :-) ).
Here's a case I'm want to be sure I understand:
Let's suppose that the aggregate says it produces type Foo with language
x-unspecified.
Let's suppose there are 2 annotators in the flow: the first one
produces Foo with language "en", the 2nd one produces Foo with language
"x-unspecified". A flow given language "x-unspecified" should run the
2nd annotator, skipping the first one. (This is how it works now).
=======
Here's another similar case, using the other language subsumption
between "en-us" and "en".
Let's suppose that the aggregate says it produces type Foo with language
"en".
Let's suppose there are 2 annotators in the flow: the first one
produces Foo with language "en-us", the 2nd one produces Foo with
language "en". A flow given language "en" should run the 2nd annotator,
skipping the first one. (This is how it works now, I think).
With this explanation, I see there is a modification to the result
spec's containsType/Feature method with a language argument needed for
this use.
Currently, the ResultSpecification matching works like this:
Language arg RsltSpc Matches
"en" "en-us" no
"en-us" "en" yes
"x-unspecified" *any* yes <<< behavior needs to be different
"en" "x-unsp.." yes
Is this correct?
-Marshall
Marshall Schor wrote:
Can I replace the class CapabilityContainer with the much more
efficient (now) ResultSpecification class?
It seems to me they do the almost same thing, and the
ResultSpecification may be handling the corner cases better.
Is there some subtle difference I'm missing? It would be nice to
eliminate a class -
smaller code base => less maintenance effort in the future :-)
-Marshall
