XProc Usability

From W3C Wiki
Revision as of 07:10, 8 August 2013 by Vtoman2 (Talk | contribs)

Jump to: navigation, search

[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.
  • 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

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 different input 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)

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
XProc v.Next  Architecture | Usabilitiy | New Steps | Resource Manager | Integration