From W3C Wiki

[Back to XprocVnext]

Contents 1 Usability issues for Vnext 1.1 Variable values opened up 1.2 Optional options for declared steps 1.3 Empty source on p:template 1.4 Output signatures for compound steps 1.5 Loading computed URIs 1.6 p:group within p:try 1.7 Parameters and the rules for their use 1.8 Location of p:variable 1.9 Choose-style binding 1.10 Add a Note or another spec for documentation conventions 1.11 Simplify working with filesets 2 Verbosity 2.1 Simplify the markup 2.2 Find a good compact syntax

Usability issues for Vnext

Variable values opened up

Can we remove the restriction on variables/options/params being bound only 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 options for declared steps

AM to complete Something that works from the command line but not internally to a library step???

Empty source on p:template

If you're fabricating from whole cloth, you have to waste space with a pointless

<foo/>

• 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 for compound steps

The existing magic is not consistent or easily understandable

Loading 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 as the only top-level children?

Parameters and the rules for their use

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

• At least, get rid of the necessity for p:empty as the parameter input [when it's now required: someone to fill in]

Location of p:variable

Should we allow p:variable anywhere in groups?

Choose-style binding

Suppose you have a pipeline with a step X, and depending on some 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 to use a p:choose a to duplicate the step X with different input bindings in each branch. This not only looks silly, but it is painful to write.

One solution to this would be a choose-style binding (a wrapper around the existing bindings) that would dynamically select the bindings to use.

Add a Note or another spec for documentation conventions

• Parallel to Javadoc?
• add an xml:lang attribute to p:documentaton and recommend its use.
• See https://community.emc.com/docs/DOC-8657 for an example

Simplify working with filesets

In situations where working with sets of files on a file directory system XProc, as currently defined, feels somewhat awkward:

• consider a p:documents element which roughly emulates apache ant filesets
• consider reusable file path structures
• consider providing conventions for making xproc scripts more cross platform e.g. file seperators

Verbosity

Simplify the markup

Can we?

Find a good compact syntax

Can we? Should we?