Is your feature request related to a problem? Please describe.
Currently many stages typically work with a single type of task as input/output for eg: DocumentBatch or VideoTask.
Even if a stage accepts different task types often they may have the same input/output requirements ["data"]["text"].
However with more cases of stages being applicable cross modality and cross task there might be cases where the input and output spec vary depending on the task type.
For eg: MinHashStage can be extended to operate on DocumentBatch in addition to FilegroupTask. However the input requirements for fgtask is (["data"], []) however for DocumentBatch it would be (["Data"], ["text","id"]). Which breaks validate_inputs in many cases or forces the stages to include the least amount of validation requirements to allow multiple types to work.
Describe the solution you'd like
One solution might be to allow inputs/ouputs to be of type Dict{Class: tuple[list, list]} where each key is the task implementation.
Describe alternatives you've considered
Alternative is for each stage with this requirement to override the validate_input/validate_output stage to handle the custom branching logic.
Additional context
Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe.
Currently many stages typically work with a single type of task as input/output for eg: DocumentBatch or
VideoTask.Even if a stage accepts different task types often they may have the same input/output requirements ["data"]["text"].
However with more cases of stages being applicable cross modality and cross task there might be cases where the
inputandoutputspec vary depending on the task type.For eg: MinHashStage can be extended to operate on DocumentBatch in addition to FilegroupTask. However the input requirements for fgtask is
(["data"], [])however for DocumentBatch it would be(["Data"], ["text","id"]). Which breaksvalidate_inputsin many cases or forces the stages to include the least amount of validation requirements to allow multiple types to work.Describe the solution you'd like
One solution might be to allow
inputs/ouputsto be of typeDict{Class: tuple[list, list]}where each key is the task implementation.Describe alternatives you've considered
Alternative is for each stage with this requirement to override the
validate_input/validate_outputstage to handle the custom branching logic.Additional context
Add any other context or screenshots about the feature request here.