What about allAnnotatorFeatures? Supposed the aggregate says it needs a
particular Feature of a particular type. Suppose a delegate is marked
as producing that type, and has allAnnotatorFeatures marked. This
wouldn't work.
You could say in this case that the output capability of the delegate
*must not* rely on allAnnotatorFeatures, but instead *must* explicitly
list those features it produces. In one sense, this could be a good
idea, because no delegate could *accurately* mark that it outputs
allAnnotatorFeatures, anyway, due to the possiblity that some other
component could add features to the type in question, completely unknown
to this delegate - and of course, this delegate would not be setting
those other features.
This would lead to another question - should we deprecate
allAnnotatoreFeatures because of this?
-Marshall
Michael Baessler wrote:
Marshall Schor wrote:
Without actually testing this (so this may be a wrong conclusion) -
it seems to me that the code in CapabilityLanguageFlowController that
sets up the result specs for components, by language, in the
mFlowTable, ignores the typesOrFeatures that the result spec adds
when compile() is called.
If you recall, the compile method for results specifications augments
the set of types/features by doing 2 things: if the type has
allAnnotatorFeatures=true, it adds all the features of the type; and
if the type has subtypes, it adds those too, propagating the
allAnnotatorFeatures processing down.
A consequence would be that the mFlowTable would miss these cases:
An aggregate wants type A output, and has a delegate with output
capability A-subtype.
An aggregate wants Feature F output, and has a delegate with output
capability type-A with allAnnotatorFeatures marked, having that feature.
Can anyone confirm this? (perhaps adding a test case :-) )?
Michael - do you know what the design intent was for this - if things
are as I've conjectured above, is this something that needs to be
fixed, or is it working as intended?
Yes that is correct. The mFlowTable only contains these output types
that are specified in the aggregate ae as output type. The guideline
for the capabilityLanguageFlow was to
specify all output results (with all interim results) in the aggregate
that must be produced.
I we now change the mFlowTable content to match the resultSpec we also
changes the capabilityLanguageFlow. So if we do that, how can I
prevent the a sub types isn't produced if a super type must be
produced? So I prefer to stay with the current design - specify all
you need.
What do you think?
-- Michale
