From W3C Wiki

[Back to XprocVnext]

Contents 1 Verbosity 2 Options, Variables, and Parameters 2.1 Allow non-string values in p:variable 2.2 Optional p:options in p:declare-step 2.3 Rules for p:parameters 2.4 Location of p:variable 3 Empty source in p:template 4 Output signatures in Compound Steps 5 Computed URIs 6 p:group within p:try 7 Choose-style binding 8 Documentation Conventions 9 Simplify working with filesets

Verbosity

• 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

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)

• Parallel to Javadoc?
• Add 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

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

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