Step Container Proposal

I've been working on my compiler and have worked through some
terminology that I think may work well in our specification.  One
of the current problems we have is that how the
declare-input/output/etc. work for pipelines, groups, and other
constructs that contain steps has not been well specified in our
current document.  My hope is that this will contribute to
helping make that more clear.

Proposal:

1. We introduce the concept of a "Component Type".  Then components
    can be instances.  This will let us handle the "dynamic" input
    and output declarations on group, foreach, viewport, choose and
    even pipeline.

    A component type is essentially what the [p:]declare-component
    element defines in our current specification.  What I'd like to
    add is that each instance of group, foreach, viewport, choose and
    even pipeline fabricates a component type that matches the
    signature.  For pipelines, this will help us when we go to
    invoke pipelines from libraries in a step--which are then essetially
    just like invoking a component in a step.

    A component type is just the set of inputs ports, output ports, and
    parameters without bindings.  A [p:]declare-component just defines
    a particular static component type that can be used by [p:]step in
    a pipeline.

2. The elements [p:]group, [p:]foreach, [p:]viewport, [p:]choose and
    [p:]pipeline all contain steps and so I propose we call them
    "step containers".  Every "step container" is also a step and
    has a component type that is generated by the [p:]declare-input,
    [p:]declare-output, and [p:]declare-parameter elements present or
    inferred contained in their declaration.

    When a step container is invoked or when its inputs/outputs are
    bound, they act just like a step in that there is a component type
    that defines the inputs and output available and those must be
    bound in the "normal" ways.

3. Step containers also bind their inputs to the output of other
    steps.  We must constrain the reference port to be an output port
    of an ancestor or sibling step in the document.  That constraint
    is not present in the current document as far as I can see.

4. Step containers bind their output port "internally" to the output
    of some step that they contain.  I think we should call that the
    "output source".  Then we can say the step container produces
    outputs on their declared output ports from the output source
    identified on the output port declaration.

    The reference in the output source can only be to direct children
    steps in the step container.  Step containers cannot refer to
    ancestor or sibling step's outputs nor to outputs within other
    step containers.

5. Some steps inside step containers bind their input ports to the
    inputs declared on the step container. This is the one place
    where we reference inputs rather than outputs.  To make this
    make sense, I suggest we call such references "input references".
    Only direct children of a step container can refer to step
    container inputs.

What this means is that at the conceptual level, when you are
"drawing" the flow graph of all the input/output connections
between steps, there are some special interpretations for
step containers.  Since a step container is also a step, from
the perspective of the rest of the pipeline, everything is
exact the same in that inputs point to outputs.

In the case of a step inside a step container, if the target
step of an input binding is the step container, the port name
must point to an input of the step container as this is an
"input reference".

For the step container to produce an output, the step container
must inspect its output sources for the step (or steps in
the case of choose) that may produce its output.

One of the good things about this is that everything is uniform
from the pipeline-as-a-step-container through all the rest of
our pipeline constructs.  We'll need to carefully define
what it means to be "a child step" as we have some cases where
the XML has wrapper elements as in choose or try/catch.

Thoughts?

-- 
--Alex Milowski

Received on Saturday, 2 September 2006 19:30:26 UTC