Re: XProc execution model

Thanks Erik for your response.

I know, I didn't bring it up with 3.0 in mind. I think it could be
something for an extension attribute at least though.

But more importantly I'm interested in understanding the reasoning behind
the current approach. Because like I said for me the behavior that I
described is more intuitive for a pipeline language.

I do realize that in real pipelines not everything is pure, that is why I
suggested to have an attribute to control it. Note that I'm not suggesting
to make "true" the default value of the attribute (although to me that
would actually make more sense).

Also note that the spec already encourages you to use real connections if
possible to influence the order in which steps are executed (see the
section "Sequential steps, parallelism, and side-effects"), even though
since the first version the "depends" attribute has been added. In the same
way I think you could encourage the use of real connections when possible
to ensure certain steps with side effects are included in the execution.

For me the added value is really clear. Refer to the use case that I
described earlier (where you have a step that can do many things but what
it actually does depends on the connected outputs). Just try to imagine
what an enormous hassle it would be to achieve this without the proposed
feature: the user of the step would have to specify with options which
outputs he is interested in, and based on that info the step itself would
have to "manually" make certain parts conditional. IMO that is not how a
declarative language is supposed to work.

Bert


Op vr 29 mei 2020 om 14:16 schreef Erik Siegel <erik@xatapult.nl>:

> Hi Bert,
>
>
>
> Omitting parts of the pipeline not needed for the results on output ports
> sounds like a bad idea to me. I sometimes have these “appendices” on
> pipelines that do things like logging or writing stuff to disk, but do not
> contribute to the “official” results on the output ports.
>
>
>
> Personally I don’t see any added value in a “pure=true” flag. And anyway,
> for the 3.0 spec that idea would be too late, but we can always add it to
> the list of ideas for a next version (if we ever get to that).
>
>
>
> Erik Siegel
>
>
>
> *From:* Bert Frees <bertfrees@gmail.com>
> *Sent:* Thursday, 28 May 2020 20:49
> *To:* XProc Dev <xproc-dev@w3.org>
> *Subject:* XProc execution model
>
>
>
> Hi.
>
> There is something in the XProc specification that I hadn't noticed before
> and that was kind of surprising to me. I apologize in advance if this has
> been discussed many times before.
>
> The spec says:
>
> Unless otherwise indicated, implementations must not assume that steps are
> functional (that is, that their outputs depend only on their inputs,
> options, and parameters) or side-effect free.
>
>
> Without ever having actually checked it in the spec, I was in the belief
> that engines had the choice to omit parts of a pipeline that are not needed
> to compute the requested outputs. I just assumed.
>
> This would give you a nice way to do optional stuff in a pipeline, based
> on whether a certain output port is connected. If you are not interested in
> an output, don't connect the port and it will also not be computed. This is
> a feature I would use extensively. Has this ever been considered or
> discussed?
>
> Would it be a good idea to add an attribute (e.g. pure=true|false) on
> steps to control the behavior (to indicate whether it is a pure function)?
> Or are there maybe already extension attributes for it? Would it be easy to
> do?
>
> Thanks,
> Bert
>