p:apply. Run a static, known step, whose type is computed dynamically.

Norm: Please consider adding the above to EXProc’s proposed steps!

Steps with varying numbers of inputs/outputs with dynamic names
Examples:

p:nvdl

p:evaluate

p:apply

p:log

Example: When using p:log inside a step that’s repeatedly called (loop, viewport, recursion, etc.), there’s no simple way to log each call to different locations.

Possible solutions:

Dynamic construction of @href

Make p:log more clever enough to detect when it’s being triggered multiple times. (Or is this implementation-defined?)

Syntax, Usability

p:repeat-until-fixed point compound step

Multi-branch/long-form p:viewport

Suppose I use <p:viewport match="chapter | section | foo">...</p:viewport> and I want to process the matches using different sub-pipelines in the viewport. At the moment, I have to use either p:choose inside p:viewport or multiple consecutive viewports. What about introducing a multi-branch (or long-form) p:viewport:

Allow p:xpath-context/@select?
Library-level (“global”) variables? And/or pipeline-level variables that would be visible also in nested pipelines?

Not really a variable, but a p:option or p:parameter that’s visible across multiple pipelines. Example: A directory path shared by several steps that the pipeline user might want to override.
A simple mechanism for constructing XML fragments using local context. (A single template? XQuery style curly braces?)

Here’s a ConstructExample

Make p:rename/@new-name optional, so that it’s possible to move elements from namespace X that match a certain condition to namespace Y. This is currently quite difficult to do.

Could you achieve this using @use-when?

Enforce that Step A must run after Step B

Example: The EXProc steps mkdir and copy have no input/output ports. This makes it awkward to write a pipeline that does mkdir first and copy second. You must wrap the steps and create a dummy connection between the wrappers.

Allow non-XML (text/binary) to flow through a pipeline

The implementation would hex-encode non-XML whenever XML was expected

This would, for example, allow xsl-formatter to produce the output on a port that could then be

serialized by the pipeline

A fallback mechanism. XProc def. (please clarify “def.”: defines? definitely?) of step but with processors allowed to use native implementation?