More thought on the flow controller / flowConstraints topic:
I think there's a fundamental question here as to how the flow ought to be specified, now that we've opened things up so that the flow specification might take a variety of forms, not just a flat list. Do we want to: (a) support specifying the flow through the FlowController's configuration parameters OR (b) support extending the <flowConstraints> section of the aggregate descriptor with new kinds of flows in addition to <fixedFlow> and <capabilityLanguageFlow>. We might even imagine a <customFlow> that could be filled in with arbitrary XML, it being the FlowController's job to make sense out of this. An advantage of (a) are that we use the common configuration parameter mechanisms we already have, so for example we could use the same GUIs we use for setting other parmeters to also set the parameters on the flow controller. (In contrast, if we allow arbitrary XML, the user would need an XML editor to be able to edit the flow.) Advantages of (b): It's closer to what the user already knows. It can be much less verbose than using configuration parameters (which also require overrides in the aggregate if the flow is to be specified there). If there's already an XML syntax for the flow it could potentially be used directly. (Although this last could also be done with an external resource referring to a separate file containig the flow definitions.) Thoughts? -Adam
