A common use pattern in pipelines is to iterate on a sequence of documents. The loop contains for instance an initial validation, one or more XSLT transformations, and a final validation.
While the documents on the respective primary input ports change from iteration to iteration, the validation schemas and the stylesheet typically don't.
If the schemas and stylesheets are create inline, a processor could know, that they do not change from iteration to iteration and do some optimization. But if they are loaded with p:document its a bit more tricky, even impossible (thinking of background processes or http-servers).
To optimize such a pipeline, authors could explicitly declare, that the port bindings do not change from iteration to iteration using an option like static="true" on p:with-input.
A processor could use this information to cache the results of schema creation or stylesheet compilation on the first run, and then to use the cache on the later runs.
As I propose this feature as optional, I suppose it to be backward compatible.
A common use pattern in pipelines is to iterate on a sequence of documents. The loop contains for instance an initial validation, one or more XSLT transformations, and a final validation. While the documents on the respective primary input ports change from iteration to iteration, the validation schemas and the stylesheet typically don't. If the schemas and stylesheets are create inline, a processor could know, that they do not change from iteration to iteration and do some optimization. But if they are loaded with p:document its a bit more tricky, even impossible (thinking of background processes or http-servers). To optimize such a pipeline, authors could explicitly declare, that the port bindings do not change from iteration to iteration using an option like
static="true"
onp:with-input
. A processor could use this information to cache the results of schema creation or stylesheet compilation on the first run, and then to use the cache on the later runs. As I propose this feature as optional, I suppose it to be backward compatible.