Re: What can we expect (from processors)

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

Received on Friday, 6 June 2025 17:26:00 UTC