XProc Usability

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

Jump to: navigation, search

[Back to XprocVnext]


  • Simplify the markup
    • Can we?
  • Find a good compact syntax
    • Can we?
    • Should we?

Options, Variables, and Parameters

Allow non-string values in p:variable

Can we drop the restriction that variables, options, and params may only bind to strings?

  • What would be allowed
    • Two biggies that I can see:
      • binaries - This would allow not only the possibility of binary resource files, but all would enable the ability to pass maps, which is where I think the real value-add comes in.
      • sequences - Not just for strings, but for nodes and binaries as well.
  • See also WhatFlows#Sequences

Optional p:options in p:declare-step

(AM to complete) Something that works from the command line, but not internally to a p:library step?

Who or what is “AM”?
Anthony Rogers 15:00, 11 October 2012 (UTC)

Rules for p:parameters

Now that we have a bunch of real pipelines, can we simplify the rules by limiting the allowed usage patterns?

  • At least drop the requirement for p:empty as parameter input [when it’s now required: someone to fill in]
What do you mean by “limiting the allowed usage patterns”?
Anthony Rogers 15:00, 11 October 2012 (UTC)

Location of p:variable

Can/should we allow p:variable anywhere in p:groups?

Empty source in p:template

If you’re fabricating from whole cloth (?), you have to waste space with a pointless <p:inline><foo/></p:inline>

What do you mean “fabricating from whole cloth”?
Anthony Rogers 15:00, 11 October 2012 (UTC)
  • What would be the downside of having the empty sequence as the default input in most/all cases?
    • AM suggests that we allow this on a step-by-step basis

Output signatures in Compound Steps

The existing magic is not consistent or easily understandable.

Can you elaborate?
Anthony Rogers 15:00, 11 October 2012 (UTC)

Computed URIs

Lots of workarounds, but shouldn’t need them.

  • Attribute-value templates . . . would solve this

p:group within p:try

Could we remove this requirement?

  • Is this a case of making life easier for implementors which confuses users? Or is it actually simpler to have the group/catch only as top-level children?

Choose-style binding


  • You have a pipeline with a step X
  • Depending on a dynamic condition, you want X to process documents (or entire sequences of documents) A, B, or C

Currently, the only way to do this is:

  • Use a p:choose to duplicate step X, with different input bindings in each branch
  • This looks silly and is painful to write


  • A p:choose-style binding (a wrapper around the existing bindings) that dynamically selects the bindings to use

Documentation Conventions

Add a Note (or other spec)

Simplify working with filesets

Currently, working with sets of files in XProc feels awkward:

  • consider a p:documents element (roughly emulates Apache Ant filesets)
  • consider reusable filepath structures
  • consider providing conventions for making XProc scripts more cross-platform (e.g. file seperators)

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