Re: Split and eval

I think that having p:eval declare all its input and output should
stay mandatory

What we should do is define what will happen to input and output that
are not bounded.

Mohamed

On Tue, Mar 19, 2013 at 5:21 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> Pursuant to my action A-213-14, here's a brief description of the split and
> eval steps.
>
> Consider the eval step: its goal is to evaluate an arbitrary pipeline
> supplied on the input port. The number of inputs and outputs that that
> step needs is dependent on the number of inputs and outputs that the
> supplied pipeline has.
>
> Here's an example:
>
>   <p:eval>
>     <p:input port="pipeline">
>       <p:inline>
>         <p:pipeline>...</p:pipeline>
>       </p:inline>
>     </p:input>
>   </p:eval>
>
> Ideally, p:eval has source and result ports.
>
>   <p:eval>
>     <p:input port="pipeline">
>       <p:inline>
>         <p:declare-step>
>           <p:input port="source"/>
>           <p:input port="stylesheet"/>
>           <p:output port="result"/>
>       </p:inline>
>     </p:input>
>   </p:eval>
>
> Ideally, this invocation has source, stylesheet, and result ports.
>
> I think that's impractical because port names have to be known at
> "compile time" and the pipeline isn't even available necessarily until
> "runtime".
>
> But you could say that p:eval has an unbounded number of input and
> output ports, named, perhaps "source1", "source2", ..., "result1",
> "result2", etc.
>
> Then the semantics of p:eval could be that it maps source1 to the
> first (in document order) source pipe in the pipeline, etc. It'd be a
> bit ugly to use, but it would be prettier than the current alternative
> of wrapping all the inputs up into a single document.
>
> The split step would have a single source port and an unbounded number
> of result ports.
>
> In my V2 implementation, I rewrite the pipeline graph so that there is
> exactly one step reading from any pipe. I introduce a split step to
> achieve this, but now I have a pipeline graph that cannot be
> serialized which is a little disappointing.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com



-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Monday, 22 April 2013 12:11:24 UTC