Informal step name checking algorithm for Appendix G

1. Handling Circular and Re-entrant Library Imports

Define the step name exports of an XProc element, against the background of a set of URIs Visited of resources already visited, as follows:

p:pipeline, p:declare-step

A singleton bag containing the type of the element

p:library

The bag-merger of the step name exports of all the element's children

p:import

Let RU be the actual resolved URI of the resource identified by the href of the element. If RU is a member of Visited, then an empty bag, otherwise update Visited by adding RU to it, and return the step name exports of the document element of the retrieved representation

all other elements

An empty bag

The changes to Visited mandated by the p:import case above are persistent, not scoped. That is, not only the recursive processing of the imported resource but also subsequent processing of siblings and ancestors must be against the background of the updated value. In practice this means either using a side-effected global variable, or not only passing Visited as an argument to any recursive or iterative processing, but also returning its updated value for subsequent use, along with the bag of step names.

Given a pipeline library document with actual resolved URI DU, it is an error (err:XS0036) if the step name exports of the document element of the retrieved representation, against the background of a singleton set containing DU, contains any duplicate names.

Given a (top-level?) pipeline document with actual resolved URI DU, it is an error (err:XS0036) if the bag-merger of the step name exports of the document element of the retrieved representation with the step name exports of its children, against the background of a singleton set containing DU, contains any duplicate names.