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

>  4/ a unit test suite, for simple tests

Have you considered using XProcSpec ?
http://daisy-consortium.github.io/xprocspec/

Romain.


On 20 févr. 2014, at 01:37, Florent Georges <fgeorges@fgeorges.org> wrote:

>  Hi,
> 
>  Thanks Geert!  That is indeed exactly the kind of utilities that
> makes sense for PipX.  I guess we need:
> 
>  1/ to integrate a step at a time, so we have a chance to review both
> its interface and implementation carefully (but yours look great!)
> 
>  2/ to document precisely each step in the sources using p:documentation
> 
>  3/ a simple documentation generation for the website (using
> documentation from 2/)
> 
>  4/ a unit test suite, for simple tests
> 
>  I had a try at 4/ on my way back from Prague.  It is very simple
> (too much simple), but still already usable for comparing the primary
> output to an expected document and to test errors are thrown when
> expected.  The code is on the repository
> <https://github.com/fgeorges/pipx> and an example of the reports can
> be found at:
> 
>    http://pipx.org/tmp/pipx-parameter-report.html
> 
>  We're making progress :-)  What do you think would be an interesting
> first candidate to look at?  The step "throw-error" maybe?
> 
>  Regards,
> 
> -- 
> Florent Georges
> http://fgeorges.org/
> http://h2oconsulting.be/
> 
> 
> On 18 February 2014 22:30, Geert J. wrote:
>> Nobody sofar? Let me throw in a few of my utils that are probably already
>> familiar to at some of you:
>> 
>> https://github.com/grtjn/xproc-ebook-conv/blob/master/src/nl/grtjn/xproc/u
>> til/utils.xpl
>> 
>> If you weed out the ones that rely on Calabash extensions, then remain:
>> 
>>        | - empty               Short-cut for p:indentity returning
>> p:empty.
>>        | - expand-dirs         Recurse on directory-list input.
>>        | - insert-doc          Uses xquery and xinclude to dynamically
>> insert doc within root element.
>>        | - log                 Write xml for debugging purposes based on
>> debug parameter.
>>        | - parameters          Short-cut for p:parameters which passes
>> through input, and with primary parameters input.
>>        | - throw-error         Throw error based on string message
>> (instead of input source).
>>        | - wrap                Wraps string value in a custom element.
>>        | - xquery              Accepts both unescaped query and external
>> file ref as query source.
>>        | - xslt                        Accepts external file ref as
>> stylesheet source.
>> 
>> * Empty is pretty straight-forward.
>> 
>> * Expand-dirs saves hassle of writing your own recursion around dir list,
>> but perhaps interface needs review.
>> 
>> * Insert-doc can be used together with viewport to replace doc references
>> with (xml) contents of doc.
>> 
>> * Log is used for debugging purposes mainly. It allows pushing
>> intermediate results to some file. It currenly only does so if a 'debug'
>> 'true' parameter is passed from command-line. If all intermediate steps
>> declare a parameters input, those params end up there automatically.
>> 
>> * Parameters is small workaround to wrap sequences of params into one, to
>> allow easy evaluation of variables against param as follows:
>> 
>>                <ut:parameters name="params"/>
>>                <p:group>
>>                        <p:variable name="debug"
>> select="(//c:param[@name='debug']/@value, false())[1]"><p:pipe
>> step="params" port="parameters"/></p:variable>
>> 
>> I'd rather point to parameters of step containing this group, but variable
>> doesn't like sequences for context. (I really hope V2 will make this work
>> much better)..
>> 
>> * throw-error, much alike Java throw new Exception("code", "message"), or
>> XPath error("code", "message"). Just a bit of added convenience to wrap
>> message into xml before passing it into p:error
>> 
>> * wrap, wrap a string argument into an element. The templating could be an
>> alternative for this, but this is very short. Not sure where I actually
>> used this though..
>> 
>> And of course:
>> 
>> * xquery and xslt, both inspired by a stackoverflow question saying that
>> calling a sequence of xslt transformation can be a real hassle, with all
>> the load doc statements, and such. Both add a convenience switch that
>> determines whether you pass in a xqy/xslt file ref, or an inline
>> query/stylesheet. Passing options through is a bit of a pain though.
>> Better control on option/param types would certainly help, as well as
>> allowing optional options to receive empty sequence..
>> 
>> 
>> Apart from these, I recall that quite a number of side-effect extensions,
>> like file io ones, don't behave as p:identity. It makes using them much
>> more convenient..
>> 
>> Cheers,
>> Geert
>> 
>>> -----Oorspronkelijk bericht-----
>>> Van: fgeorges@gmail.com [mailto:fgeorges@gmail.com] Namens Florent
>>> Georges
>>> Verzonden: dinsdag 18 februari 2014 16:35
>>> Aan: Geert J.
>>> CC: Jostein Austvik Jacobsen; XProc Dev
>>> Onderwerp: Re: PipX, a portable library of XProc pipelines and steps
>>> 
>>>  Hi Geert,
>>> 
>>>  There is no process, really.  Discussing it first before sending a
>>> pull request sounds a sensible approach, so we are sure that we agree
>>> before submitting code.  Opening a ticket in order not to loose track
>>> of anything sounds a good idea as well, yes.
>>> 
>>>  Let's just see where we are going...
>>> 
>>>  Regards,
>>> 
>>> --
>>> Florent Georges
>>> http://fgeorges.org/
>>> http://h2oconsulting.be/
>>> 
>>> 
>>> On 18 February 2014 16:09, Geert J. wrote:
>>>> How to reach consensus on contributions? Or are we taking the xproc
>>>> extensions approach, open a new ticket for each contribution, discuss
>> it
>>>> first, then consider putting code in?
>>>> 
>>>> Cheers
>>>> 
>>>>> -----Oorspronkelijk bericht-----
>>>>> Van: fgeorges@gmail.com [mailto:fgeorges@gmail.com] Namens Florent
>>>>> Georges
>>>>> Verzonden: dinsdag 18 februari 2014 11:30
>>>>> Aan: Jostein Austvik Jacobsen
>>>>> CC: XProc Dev
>>>>> Onderwerp: Re: PipX, a portable library of XProc pipelines and steps
>>>>> 
>>>>> On 18 February 2014 10:00, Jostein Austvik Jacobsen wrote:
>>>>> 
>>>>>  Hi Jostein,
>>>>> 
>>>>>> Would you prefer if the steps are moved to some PipX namespacing
>>>>>> regime or are any namespace fine?
>>>>> 
>>>>>  Unless there was a specific technical reason, I'd rather keep all
>> in
>>>>> the PipX namespace (maybe split at some point among several
>>> namespace).
>>>>> I think it makes things more clear.
>>>>> 
>>>>>> I think the main obstacle to using PipX in other projects are how
>>>>>> easily it can be integrated into other build processes.
>>>>> 
>>>>>  Among other important points, yes.  Using the EXPath packaging
>> might
>>>>> help here.  If you have any specific ideas or problems with you own
>>>>> build system, I'd be interested to hear them.  In the meantime I have
>>>>> added a few open questions at http://pipx.org/progress.html, and
>> would
>>>>> be happy to expand it based on comments (or even resolve them :-p).
>>>>> 
>>>>>  Regards,
>>>>> 
>>>>> --
>>>>> Florent Georges
>>>>> http://fgeorges.org/
>>>>> http://h2oconsulting.be/
>

Received on Thursday, 20 February 2014 08:02:05 UTC