Possible design change for Capability Language Flow to consider needed inputs?

[Marshall Schor <ms...@schor.com>]

Suppose I have a capability language flow for an aggregate having 2 
delegates where the aggregate's capability spec says it outputs type 
Toutput.  
 
     Let's say the delegate #2 has a capability spec saying it outputs 
Toutput,
     but needs Tinput as an input, and the aggregate's Capability spec
     *doesn't* include Tinput as an input.

     Let's say delegate#1 has a capability spec saying it outputs Tinput,
     the input needed by delegate#2

The current logic in CapabilityLanguageFlowController.computeSequence 
would build a flow having only delegate #2, because it doesn't currently 
consider the need for some flow elements to produce input types needed 
by later delegates.

I'm not sure if this is worth fixing, or, if it should just be 
documented as a limitation.  A proper fix might take some work - as it 
should consider sequencing to insure needed inputs are produced before 
they're needed.  Any opinions?

Also, currently, it is possible that 
CapabilityLanguageFlowController.computeSequence can fail to find a flow 
that produces all of the types listed in the Output Spec for its 
aggregate.  In this case, it produces a partial flow - one in which some 
(perhaps 0) annotators will run, and not produce all the outputs 
needed.  Currently this is not flagged as an error, or logged.  Should 
it be?

-Marshall