I went back and checked the Javadocs for the ResultSpecification, prior
to my reworking of it. I think I treated the x-unspecified slightly
wrong, and if I had done it right, then the anomaly noted in the
previous note (below) would not be there.
The previous Javadocs all say that the setters for a typeOrFeature
without a language argument, are equivalent to passing in the
x-unspecified language. The method containsType/Feature(foo,
"x-unspecified") should be made to return true only if the Result
specification for this contained x-unspecified. It might not, if, for
instance, the setting for Foo was only for languages "en" and "de".
A consequence of making it work this way is the following:
containsType(foo, "x-unspecified") will return "false" if foo is in
the result spec
only for particular languages.
and the containsType(foo) <<< no language argument
would also return "false", if foo is in the result spec
only for particular languages.
I plan correct the treatment of x-unspecified, along these lines, to
work as described above.
Please post any concerns/objections :-)
-Marshall
Marshall Schor wrote:
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
