Policy for automatically inserting translators into the execution graph

[knoepfel]

We should discuss the framework behavior for inserting data-product translators based on the data-product concept as determined by the algorithm's inputs.

[knoepfel]

Agreement:

1. A data-product concept can be modeled by multiple concrete data-product types.
2. A concrete data-product type may model more than one data-product concept.
3. A translator is a node whose input is of one concrete data-product type and whose output is of a different concrete data-product type, both of which model the same data-product concept. Such concrete data-product types are concept-compatible.
4. A translator will be automatically inserted into the graph between two nodes whose data-product types are concept-compatible but not identical.
5. Algorithms this produce multiple data products that are concept-compatible must specify unique product suffixes for each output data product.
6. The specification of input data products must support data-product concepts. (This may include an optional explicit specification of the data-product concept.)

[knoepfel]

Agreement:

7. The computational graph does not include providers, preservers, or the framework driver.
8. The computational graph can be disjoint.
9. Translator nodes belong to the computational graph: there are no translators that precede a provider; there are no translators that follow a preserver.
10. The data-product concept must be persisted in some form to a file through Phlex's IO backend interface (e.g., FORM).