XProc Architecture

From W3C Wiki
Revision as of 16:39, 11 October 2012 by Arogers (Talk | contribs)

Jump to: navigation, search

[Back to XprocVnext]

What flows between Steps

Should we open up the pipeline architecture to allow non-XML documents to flow through it?

With respect to other media types (see below for some possibilities), there are a number of possibilities:

  1. Allow statically
    1. At the step level (i.e. step signatures include media-types for all inputs/outputs)
    2. At whole-pipeline margins
      1. Require pipeline output media-type to match the media-type of its connected input
        1. Any non-XML output must immediately be converted to XML
        2. Any foo–foo connections are allowed
        3. Auto-shim for every possible pair
        4. Auto-shim only for other–XML and XML–other (so other1→other2 requires two shims)
  2. Allow dynamically (e.g. from p:http-request)
    1. With a static declaration of expected alternatives; anything else is an error
    2. With a pipeline fallback if all else fails, getting <c:data media-type=...>...</c:data>

Any shim-to-XML can be (?) configured wrt the target vocabulary

  • How?
    • We could identify shim tactics with QNames (similar to how serialization methods work in XProc already)


Sequences

Allow the same values that XQuery/XSLT allows as values for variables


Sets of Documents

Allow unbounded number of outputs from some steps?

  • MZ says we need this for the NVDL use case [cross-reference needed]. Markup pipeline allowed this, subsequent steps need to access by name, where default naming is with the integers. . .
  • p:pack could have more than two inputs, so you could do column-major packing


Metadata

Plain text

JSON

Auto-shimming

In other words, automatically converting between media-types as required by output–input connections


Other Architecture Changes

Events

Can we suspend a pipeline waiting for something to happen?

Some examples:

  • wait for HTTP POST from GitHub (notifications)
  • JMS queue listener
  • TCP socket listener

Synchronization/concurrency

Related-but-different (with pipeline-internal events, as it were):

Pipelines frozen in time

Can we dump a partially-evaluated pipeline instance for subsequent resumption?

In other words, can we implement the ability to pause/resume pipelines?

Expose pipelines as XPath functions

For easy re-using of pipelines.

  • Or, allow XQuery/XSLT to import pipelines


XProc
XProc v.Next  Architecture | Usabilitiy | New Steps | Resource Manager | Integration