Implementing XProc, VI

This essay is part of a series of essays about implementing an XProc processor. XProc: An XML Pipeline Language is a W3C specification for specifying a sequence of operations to be performed on one or more XML documents. I'm implementing XProc as the specification progresses. Elsewhere you'll find background about pipelines and other essays about XProc.

This essay assumes you've got some familiarity with the current (as of 13 June) story about options and parameters in XProc, perhaps by reading my other essay about them.

Options are fairly easy to implement. Like variables in many other languages, they're lexically scoped. At any given point in the pipeline, the set of options known are the set declared on your ancestors. The current value of each option is the value declared on your most recent ancestor.

The XProc specification says that option values are accessible in XPath expressions used to compute other values. That means that when you setup the XPath context for a select expression on a pipeline element, you provide all the in-scope options as the set of variable bindings in the context.

Parameters, now they're another story. There are three things we have to deal with: declaration of parameter sets, use of parameter sets, and the use of inputs inside a parameter set.

Because the declaration of a parameter set can include inputs that might be read from the outputs of other steps, I think p:parameter-set has to be treated like any other step in the pipeline. Certainly for the purpose of detecting loops in the graph, that appears to be the case.

Consequently, the p:use-paremeter-set element is really just a new kind of input from the point of view of the step on which it occurs.

My current analysis is that the parameter story can be simplified further in XProc. I'm likely to hold off on actually implementing the current proposal until the working group has considered further simplifications.