Re: Parameters, Manifests, and Use Case 5.6

Richard Tobin wrote:
> I'm still having trouble seeing the problem you (Alex) made on the
> call.  It's true that you can't start a process until its parameters
> are available, but that's not a problem unique to parameters.  You
> can't start a process in a choose until you've determined whether that
> branch will be taken.  You can't start a process in the loop of a
> for-each or viewport until you know whether there will be a document
> for it.
> 
> The 90% case will be steps with no computed parameters.  So long as
> these cases can be readily determined at compile time, I don't see why
> the possibility of computed parameters should make much difference.


Part of my "component contract" to the component developer is that they
will have parameter information before they receive non-static inputs.

In fact, the full contract gives them more:

1. The component is initialized before the pipeline starts.

2. Statically available input information (URLs and here documents)
    is delievered to the component after initialization.

3. The component is started when the nearest "iteration" starts.

4. Non-static inputs are received in arbitrary order.

5. The component is notified of the iteration end.

Here I'm using "iteration" to denote any kind of excution
sequence--whether it is a single run or multiple for a viewport or
for-each.

Now, if parameters are dynamically calculated against arbitrary
inputs, those input computations must happen between (3) and (4) or
the component must cache all the input until it receives
notification of a required parameter binding.

To guarantee some ability to stream and not cache input, I have
the insert input edges to the steps and ensure that the parameter
is bound *before* the component starts.  That means I have to do
quite a bit of work to achieve this 10% case.

Now, considering that we don't have any direct use cases that detail
why we need this feature, I'm questioning why we do this in V1.0.

What I've heard so far for use cases for computed parameters is:

   1. use case 5.6
   2. parameter renaming (e.g. your 'x' parameter is not my
     'x' parameter).
   3. computing parameters from parameters (e.g. substring on a
      parameter).

I think we have a fine solution for (1) that involves one more
step and no computed parameters.  I think this technique is much more
clear.

(2) and (3) are interesting use cases that we do not have in our
use case and requirements document.  If we want to do them, we
should revise that document and acknowledge that we're slightly
expanding the scope.  There is probably a simple solution to
(2) and (3) that involves a suggestion from Norm to use a
"null context".


-- 
--Alex Milowski

"The excellence of grammar as a guide is proportional to the paucity
of the inflexions, i.e. to the degree of analysis effected by the
language considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Thursday, 12 October 2006 17:40:31 UTC