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

Nobody sofar? Let me throw in a few of my utils that are probably already
familiar to at some of you:

If you weed out the ones that rely on Calabash extensions, then remain:

	| - empty		Short-cut for p:indentity returning
	| - 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: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..


> -----Oorspronkelijk bericht-----
> Van: [] 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
> 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
> > first, then consider putting code in?
> >
> > Cheers
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: [] 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
> >> 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
> >> 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, and
> >> be happy to expand it based on comments (or even resolve them :-p).
> >>
> >>   Regards,
> >>
> >> --
> >> Florent Georges
> >>
> >>

Received on Tuesday, 18 February 2014 21:30:39 UTC