Difference between revisions of "XProc Usability"

From W3C Wiki
Jump to: navigation, search
m (Fixed heading levels)
m (Grouped related headings)
Line 12: Line 12:
  
  
= Allow non-string values in <code>p:variable</code> =
+
= Options, Variables, and Parameters =
 +
== Allow non-string values in <code>p:variable</code> ==
 
Can we drop the restriction that  <code>variables</code>, <code>options</code>, and <code>params</code> may only bind to strings?
 
Can we drop the restriction that  <code>variables</code>, <code>options</code>, and <code>params</code> may only bind to strings?
 
* What ''would'' be allowed
 
* What ''would'' be allowed
Line 20: Line 21:
 
* See also [[WhatFlows#Sequences]]
 
* See also [[WhatFlows#Sequences]]
  
 
+
== Optional <code>p:option</code>s in <code>p:declare-step</code> ==
= Optional <code>p:option</code>s in <code>p:declare-step</code> =
+
 
('''AM to complete''') Something that works from the command line, but not internally to a <code>p:library</code> step?
 
('''AM to complete''') Something that works from the command line, but not internally to a <code>p:library</code> step?
  
 
:''Who or what is “'''AM'''”?'' <br>[[User:Arogers|Anthony Rogers]] 15:00, 11 October 2012 (UTC)
 
:''Who or what is “'''AM'''”?'' <br>[[User:Arogers|Anthony Rogers]] 15:00, 11 October 2012 (UTC)
 +
 +
== Rules for <code>p:parameter</code>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 <code>p:empty</code> as parameter input [when it’s now required: '''someone to fill in''']
 +
 +
:What do you mean by “limiting the allowed usage patterns”? <br>[[User:Arogers|Anthony Rogers]] 15:00, 11 October 2012 (UTC)
 +
 +
 +
== Location of <code>p:variable</code> ==
 +
Can/should we allow <code>p:variable</code> anywhere in <code>p:group</code>s?
  
  
Line 51: Line 61:
 
Could we remove this requirement?   
 
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 <code>group</code>/<code>catch</code> only as top-level children?
 
* Is this a case of making life easier for implementors which confuses users?  Or is it actually simpler to have the <code>group</code>/<code>catch</code> only as top-level children?
 
 
= Rules for <code>p:parameter</code>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 <code>p:empty</code> as parameter input [when it’s now required: '''someone to fill in''']
 
 
:What do you mean by “limiting the allowed usage patterns”? <br>[[User:Arogers|Anthony Rogers]] 15:00, 11 October 2012 (UTC)
 
 
 
= Location of <code>p:variable</code> =
 
Can/should we allow <code>p:variable</code> anywhere in <code>p:group</code>s?
 
  
  

Revision as of 16:49, 11 October 2012

[Back to XprocVnext]


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)


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