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

Hi Florent,

So perhaps let us take a closer look at one of them, I suggest not
starting with ut:throw-error, that relies on ut:wrap..

And let me start a new mail thread as wel..

Cheers

> -----Oorspronkelijk bericht-----
> Van: fgeorges@gmail.com [mailto:fgeorges@gmail.com] Namens Florent
> Georges
> Verzonden: donderdag 20 februari 2014 1:37
> Aan: Geert J.
> CC: Jostein Austvik Jacobsen; XProc Dev
> Onderwerp: 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 06:36:12 UTC