Re: What can we expect (from processors)

Fantastic info, thanks Norm.

Cheers, Wendell


On Fri, Jun 6, 2025 at 1:25 PM Norm Tovey-Walsh <ndw@nwalsh.com> wrote:

> Wendell Piez <wapiez@wendellpiez.com> writes:
> > Briefly, if I bind an input using a port, and then my XProc never uses
> it, can I hope it will never be accessed (located and parsed)?
>
> I don’t think the steps say much about this, and I’m not sure they should.
> Processors are allowed to be lazy, but they aren’t required to be.
>
> I think you’d need to define what you mean by “bind an input” and “and my
> XProc never uses it” in a little more detail.
>
> If you’re talking about connections between steps in the pipeline, then
> (in my implementation) the question isn’t relevant. You’re passing XDM data
> model instances around, there’s nothing to locate and parse.
>
> If you mean from the outside:
>
> <p:declare-step>
>   <p:input port="source" primary="true"/>
>   <p:input port="secondary"/>
>   <p:output port="result"/>
>   <p:identity>
> </p:declare-step>
>
> Obviously, anything you pass to “secondary” is going to fall on the floor.
> But you must pass something to “secondary” (because it doesn’t allow
> sequences).
>
> The API for my implementation only lets you pass parsed data models to the
> processor. The command line wrapper around the underlying implementation
> deals with all the filenames passed on the command line and such. It is
> going to parse the thing you said you were passing on the “secondary” port
> (and reject it if it isn’t XML).
>
> > - A static option 'skip' is set to a Boolean
> > - A document is given on the main input port
> > - A p:load is given that says 'use-when="$skip"'
> > - Nowhere does a step bind to the main input
> >
> > Will the document on the main input port be loaded?
>
> Yes, I think, in practice, a processor has to load the documents you pass
> in from the outside to satisfy content type and sequence constraints.
>
> The use-when case is perhaps a little more subtle. If $skip evaluates to
> false, then your pipeline doesn’t contain a p:load step. So there are no
> circumstances in which that p:load step will look at any of its options,
> load any documents, or so anything else.
>
> > Same question can be asked with p:variable and p:if or p:choose wrappers
> (i.e., not use-when).
>
> My implementation evaluates variables lazily unless you ask it not to. A
> p:if only has one conditional expression, so that will have to be
> evaluated. If a p:choose has more than one, they’re evaluated in document
> order stopping at the first one that evaluates to true. (Or p:otherwise,
> which is logically the same as p:when test=true().)
>
> > And lastly, the same question(s) again, only this time all dynamic
> loading - will a p:load be
> > loaded if its results are never bound to anything? (say, another p:load
> happens.)
>
> My implementation binds any otherwise unbound ports to p:sink behind your
> back so there are no unbound ports. I have in mind an optimization to go
> back and remove chains of steps that have no effect, but I haven’t done it
> yet.
>
> > Should one generally assume everything is always loaded, if a port
> binding is given? Or always loaded, period, even if subsequent steps make
> no use of step outputs (or port bindings)?
>
> Yes, probably.
>
> > If all this is processor dependent (and even if not), how could one
> learn more? is this the kind of thing that 'trace' options will show?
>
> The trace output on my process will tell you more, as will
> --verbosity:debug if you’re willing to watch it flow by on the console.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norm Tovey-Walsh <ndw@nwalsh.com>
> https://norm.tovey-walsh.com/
>
> > We humans are such limited creatures—how is it that there are so few
> > limits when it comes to human suffering?--Pierre Marivaux
>


-- 
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...