XProc Usability
[Back to XprocVnext]
Verbosity
- Simplify the markup
- Can we?
- Find a good compact syntax
- Can we?
- Should we?
base uri
- add a mechanism to set the base URI of documents created with p:inline. If possible the base URI can be set dynamically (e.g. from a variable), but if it's not possible the 'p:set-base-uri' step declared above is enough.
- add a 'base-uri' option to steps that produce new documents (e.g. p:wrap-sequence, p:wrap, etc).
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.
- Two biggies that I can see:
- See also WhatFlows#Sequences
Optional p:option
s in p:declare-step
(Alex Milowski to complete) Something that works from the command line, but not internally to a p:library
step?
Rules for p:parameter
s
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:group
s?
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?
- Alex Milowski 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
Suppose:
- 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 differentinput
bindings in each branch - This looks silly and is painful to write
Suggestion:
- 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)
- Parallel to Javadoc?
- Add
xml:lang
attribute top:documentaton
and recommend its use. - See https://github.com/vojtechtoman/xprocdoc for an example
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)
Functions
- consider allowing definition and/or import of XPATH functions
- consider allowing definition and/or import of XSLT/XQuery functions
define a built-in extension function that loads documents from readable ports, or allow a sequences of documents to be available as collections in the XPath dynamic context. For instance to switch cases depending on the number of elements in the sequence you currently have to - use p:count to get the size of the sequence - re-pipe the flowing document - p:choose with an XPath context piped to the result of the p:count This is very verbose for a simple and common task. Mapping readable ports to collections would allow something like: - p:when test="count(collection('my-step#my-port')) gt 0"
XProc v.Next | Architecture | Usabilitiy | New Steps | Resource Manager | Integration |
---|