Re: Step Container Proposal

/ Alex Milowski <alex@milowski.org> was heard to say:
| 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.

So you're thinking of something along the following lines:

All components have a component type defined by the name of the
component and the specific set of inputs, outputs, and parameters that
it declares. Many components (e.g., xslt, xinclude, etc.) have a
static component type determined by the name, input, output, and
parameters declared in the p:declare-component for that component.
Language constructs (e.g, pipeline, for-each, group, etc.) that have
declarations as their immediate children implicitly define a component
type that matches their signature.
|
| 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".

I had sort of hoped to avoid making a point of the distinction between
"step container" steps and "ordinary steps". But looking at the
constraints that we have to describe on port bindings, I think you may
be right.

|    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.

But they aren't bound in the "normal" ways, they're simultaneously
declared and bound in the declare-input/declare-output statements.
However, I agree that we need to say that all of the declared inputs
and outputs must be bound, just as they must be bound in the
invocation of a "normal" component.

| 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.

I think you're right about it not being explicit in the document yet.
I believe that the constraint is:

   The declare-inputs (whether implicit or explicit, which is a
   separable question) of a step component must be bound to the output
   port of some preceding step or the declared-input port of some
   ancestor step.

| 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.

Do we need to define output source? Can't we just say that the
declare-output statements in a step container must be bound to the
output port of a step that is a direct child of the step container?
(If they're bound to an output port at all, they may just be "here"
documents or static hrefs.)

| 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.

I think the constraints on inputs on steps within a step container are
the same as the constraints on the input to the container itself: the
inputs of a step in a step container must be bound to the output port
of some preceding step or the declared-input port of some ancestor
step container.

| 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?

I think it's a good direction.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.