W3C Wiki?

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!

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"/> <!-- defaults to primary output port of step -->

• 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?

CategoryHomepage