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

  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 00:38:06 UTC