Well, in the current design, the flow constraints are only required for the two "built-in" flow controllers - the fixed flow and the capability-language ones.
Users have built custom flow controllers; those have no obligation to make use of the flowConstraints (although they can if they want to). -Marshall On 9/26/2013 5:00 PM, Richard Eckart de Castilho wrote: > Not the controller, but its configuration. The skipping is clearly affecting > the flow. So why not add something to the flowConstraints, e.g.: > > <flowConstraints> > <fixedFlow> > <node>[String]</node> > <node>[String]</node> > ... > </fixedFlow> > <skip> > <node>[String]</node> > <node>[String]</node> > ... > </skip> > </flowConstraints> > > or > > <flowConstraints> > <fixedFlow> > <node skip="true">[String]</node> > <node>[String]</node> > ... > </fixedFlow> > </flowConstraints> > > Personally, I'd not make any modifications to the descriptor at all, but > rather would just skip the delegate when programmatically creating the > descriptor. We do that all the time in our experiments. But if that is for > some reason not an option and the extension is a strong requirement, the > change should at least be made at the location that conceptually makes most > sense (imho). > > @Marshall: do you want to provide some more background why you do not simply > create the descriptors programmatically and externalize this skipping, > including, etc. into your experimental setup? > > -- Richard > > On 26.09.2013, at 22:53, Peter Klügl <[email protected]> wrote: > >> Am 26.09.2013 22:51, schrieb Richard Eckart de Castilho: >>> I believe this is a concern of the flow controller and should not be >>> configured on the delegates, but rather within the flow controller >>> configuration. >> That was also my first guess, but do you really wanna touch or change the >> flow controller for just skipping a component? >> >> Peter >> >>> -- Richard >>> >>> On 26.09.2013, at 17:23, Marshall Schor <[email protected]> wrote: >>> >>>> To handle the use cases briefly described on the user list for selectively >>>> skipping some annotators in an aggregate, based on some externally supplied >>>> configuration data, I'd like to propose something along these lines: >>>> >>>> * Add to the existing element <delegateAnalysisEngine key="[String]"> one >>>> or two >>>> additional attributes. One would be "skip=${xxx}" and the other would be >>>> its >>>> inverse (for improved readability, only, not logically needed): >>>> "run=${xxx}", >>>> where the value of the parameter would need to be "true" or "false" (or >>>> "yes" or >>>> "no"). >>>> >>>> The parameter could be written literally as "true", etc., but also could be >>>> written using the standard variable naming syntax used elsewhere in the >>>> descriptors, and would be resolved by settings in the now-standard >>>> "external >>>> overrides" files used by UIMA. This means that the external overrides >>>> would >>>> continue to be a place where all of the specific configuration info for a >>>> particular "run" could be placed, together. >>>> >>>> The implementation would do nothing new if the parameters were indicating >>>> to run >>>> the delegate, but if they were indicating it should be skipped or not run, >>>> then >>>> the effect would be as if the delegate had been edited out of the xml >>>> descriptor. >>>> >>>> This would satisfy some pleas from some user groups for help in managing >>>> their >>>> descriptors across various related experiments. >>>> >>>> An example: a user might have a delegate which came in two forms: one to >>>> run >>>> "locally", and the other to run "remote". >>>> >>>> They could then include both descriptors in the aggregate, and have only >>>> one of >>>> them "active", by coding: >>>> >>>> <delegateAnalysisEngine key="NE-detector" run="NE-Detector-local"> ... >>>> </delegateAnalysisEngine> >>>> <delegateAnalysisEngine key="NE-detector" skip="NE-Detector-local"> ... >>>> </delegateAnalysisEngine> >>>> >>>> WDYT? >>>> >>>> -Marshall >
