W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > September 2006

Re: Step Container Proposal

From: Alex Milowski <alex@milowski.org>
Date: Thu, 07 Sep 2006 07:43:03 -0700
Message-ID: <45002FF7.6020805@milowski.org>
To: public-xml-processing-model-wg@w3.org

Norman Walsh wrote:
> 
> 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.

Yes.

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

What I meant was that from the component type perspective and
outside the step container, those input and output port binding follow
the same rules for as regular steps.

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

Preceding includes ancestor steps and that definition doesn't include
following steps of the current container.

Also, how can a declared input on a step container be bound to the
input of a ancestor step ?  I think that needs to be an ancestor
step container.


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

I suppose we don't need to give it a name.  I was just naming
everything.  In this case, it probably isn't needed.

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

Again, preceding doesn't contain the following steps of the current
step container.  ...but I would like to have one statement for
both steps and step containers, if possible.

--Alex Milowski
Received on Thursday, 7 September 2006 14:50:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:48 GMT