OldWikiVnext

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!

Dynamics, Flexibility

Attribute value templates Dynamic attribute values:

p:data/@href

p:viewport/@match

p:input/@select

p:serialization

p:viewport-source

p:iteration-source

p:option

Data types!

Arbitrary data model fragments (for p:parameters also)

Custom XPath functions (ala xsl:function) using “simplified XProc steps” (whatever that means)

Dynamic evaluation

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 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:

       <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:variable templates

   Syntactic shortcuts…

       <p:input port="source" href="…"/>

       <p:input port="source" step="name" step-port="secondary"/>

       <p:input port="source" step="name"/>

       <p:pipe step="name"/>  

   Adding a p:variable requires adding p:group…feels odd

       Explanation: see here 

   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?

Processing

Cache intermediate URIs

SAX filter step (will also add as an extension step)

Support a more event-driven processing model?

XPath 2.0 only?