Re: Parameter Calculations and Removing Complexity

Hi Alex,

Alex Milowski wrote:
> If we allow arbitrary steps to have parameter calculated
> from arbitrary inputs, those parameters would have to
> be calculated and "set" on the step before the step
> receives any input.  That is, now you have parameters flowing into
> components that must be delivered before any input is delivered.  We do
> not have the requirement that inputs must be delivered in
> a certain order.
> 
> So, the affect of adding that "step/source/select" on the [p:]param
> element means you've effectively wrapped the step in a [p:]group.
> That ensures that the order is correct.
> 
> I'm not certain that the "auto-wrapping" of steps to
> produce the calculation before the steps runs is so
> obvious to the user.  That pre-input dependency may cause
> things to happen in orders that they might not expect.

I think you're imagining a scenario like:

  <p:step name="A" ...>...</p:step>
  <p:step name="B" ...>...</p:step>
  <p:step name="C" ...>...</p:step>
  <p:step name="D" ...>
    <p:input port="doc" step="A" source="result" />
    <p:input port="aux" step="B" source="result" />
    <p:param name="foo" step="C" source="result" select="/some/thing" />
  </p:step>

Let's say that we have the rule in place that implementations must 
behave as if the steps were executed in order.

If your implementation can determine that step C doesn't depend on steps 
A or B, then it can execute step C first without breaking that rule.

If step C explicitly depends on steps A or B then step C must be 
executed after steps A or B. You have to do whatever you usually do to 
temporarily hold the results of those steps so that they can be used in 
step D.

If you can't tell whether step C depends on steps A or B, then you have 
to do the same as if there were explicit dependencies, but you will 
probably want to message the user to tell them that they're not getting 
the best performance out of their pipeline with your implementation.

The only behaviour that users wouldn't expect is your implementation 
barfing.

> Further, there is a conceptual burden that I'm not certain
> we really need for a 1.0 specification.  If the main use-case here is to
> set XSLT parameters via inputs, that can be done by another step that
> computes a stylesheet:
> 
> <p:pipeline name="pipeline">
> 
> <p:declare-input port="config"/>
> <p:declare-input port="input"/>
> <p:declare-output port="output" step="transform" source="result"/>
> 
> <p:step name="bind-parameters"
>         type="p:xslt">
>   <p:input port="document" step="pipeline" source="config"/>
>   <p:input port="transform">
>      <xsl:transform version="1.0">
>         <xsl:template match="/">
>             <xslo:transform version="1.0">
>                <xslo:import href="mytransform.xsl"/>
>                <xslo:param name="color">
>                   <xsl:value-of select="/config/@color"/>
>                </xslo:param>
>             </xslo:transform>
>         </xsl:template>
>      </xsl:transform>
>   </p:input>
> </p:step>
> 
> <p:step name="transform" type="p:xslt">
>    <p:input port="document" step="pipeline" source="input"/>
>    <p:input port="transform" step="bind-parameters" source="result"/>
> </p:step>
> 
> </p:pipeline>

(You missed the <xsl:namespace-alias> that's necessary in the above.)

I am *absolutely certain* that users will find this extremely hard work. 
I am pretty damned sure that the complexity it adds for the user far 
outweighs the complexity that it removes for the implementer.

So let's not remove step/source/select from <p:param>.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 4 October 2006 15:07:15 UTC