Re: PipX, a portable library of XProc pipelines and steps

- Download xprocspec (or clone its repository):
http://daisy-consortium.github.io/xprocspec/
- If you want validation of the xprocspec documents (useful when authoring
them - gives autocomplete etc); add xprocspecs catalog.xml to your list of
xml catalogs (in oxygen; edit "~/Oxygen XML Editor
15/frameworks/catalog.xml" and add "<nextCatalog
catalog="/home/USERNAME/xprocspec/xprocspec/src/main/resources/META-INF/catalog.xml"/>"
to the end.
- To execute a xprocspec test, run
"~/xprocspec/xprocspec/src/main/resources/content/xml/xproc/xprocspec.xpl"
with your xprocspec test document on the primary input source port. If
you're on Windows you should set the optional "temp-dir" option to
something more appropriate than the default "file:/tmp/"
- xprocspec has three secondary output ports; result, html and junit. The
"result" port contains the raw output from the xprocspec evaluation. It's
probably not useful to most users. The "junit" is mainly intended for maven
integration but can be useful if you need a machine-readable format. The
"html" port is probably what you want though; it contains a single html
document containing the test report.

I've set up a scenario in oXygen called "Basic xprocspec test" where I use
the current document as input and point the output ports to files in
file:/tmp/. So whenever I have a xprocspec test document open in oXygen I
can run that scenario, then go to my browser and refresh
"file:///tmp/xprocspec-html.html" to see the results. You could also
instruct oXygen to automatically open the html file I suppose.

I also have a oXygen scenario that lets me run the test while viewing the
XProc document itself (to avoid switching between tabs when repeatedly
running tests), but that's based on file nameing conventions etc. so I
won't bother you with the details (unless you're interested).

Hope this helps.



wrt verbosity: I'm not sure how to make it less verbose without removing
functionality or overloading elements with attributes. But I'm open to
suggestions!
wrt subpipelines: If you want to test subpipelines, then you can create a
small wrapper script and test its inputs and outputs (which you might want
to expose in your library anyway if it's a common pattern). By the way,
xprocspec supports custom implementations of assetions if that helps.


Jostein


On 20 February 2014 19:10, Florent Georges <fgeorges@fgeorges.org> wrote:

> On 20 February 2014 18:46, Jostein Austvik Jacobsen wrote:
>
> > Here's an equivalent xprocspec test:
> > https://github.com/fgeorges/pipx/pull/1/files
>
>   Thanks.  I accepted your pull request, I'll have a look later.  Can
> you explain how to run it?  At first glance, I would say it is a bit
> verbose, and it has the same drawback (someone would say advantage) as
> XSpec has: it allows you only to execute one step, not a subpipeline.
> What if you want to test for instance:
>
>     <pipx:step-a .../>
>     <pipx:step-b .../>
>
> instead of just calling either pipx:step-a or pipx:step-b?
>
>   I will try to update http://pipx.org/progress.html soon also, but
> for now, I have to call it a day...
>
>   Regards,
>
> --
> Florent Georges
> http://fgeorges.org/
> http://h2oconsulting.be/
>