Merge this into the W3C wiki (http://www.w3.org/wiki/XprocVnext) or merge that into here. Or something.
- Binary content to/from p:exec should be considered
XProc V.next: Ideas
This page is a scratchpad for ideas about XProc V.next.
This is essentially just a brainstorm—so if you've ever been writing something in XProc and wondered, “wouldn't it be cool if…”, please feel free to add it to the list!
- Attribute value templates
- Dynamic attribute values:
Arbitrary data model fragments (for p:parameters also)
Custom XPath functions (ala xsl:function) using “simplified XProc steps” (whatever that means)
p:evaluate. Compile a pipeline and run it.
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
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.
Dynamic construction of @href
Make p:log more clever enough to detect when it’s being triggered multiple times. (Or is this implementation-defined?)
p:repeat-until-fixed point compound step
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:
<p:viewport> <p:match match="chapter">...subpipeline...</p:match> <p:match match="section | foo">...subpipeline...</p:match> </p:viewport>
xsl:iterate (XSLT 3.0) like compound step
Improve p:string-replace quoting ugliness
<p:input port="source" href="…"/>
<p:input port="source" step="name" step-port="secondary"/>
<p:input port="source" step="name"/>
<p:pipe step="name"/> <!-- defaults to primary output port of step -->
Adding a p:variable requires adding p:group…feels odd
Explanation: see here
- 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
- 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?
- Cache intermediate URIs
- SAX filter step (will also add as an extension step)
- Support a more event-driven processing model?
- XPath 2.0 only?