RE: XProc Usability (was Re: New to Xproc Question : conditionnal "output port" definition?)

Hi Norm!

> > - Things like generating empty input taking up 5 lines (p:identity
> > with p:input with p:empty inside), can't that be done shorter?
> 
> When do you need this? Can you show me a small example?

Let me take some examples from my ePub XProc application.. ;)

A small example will be difficult, it is usually in a larger combination that such tricks come in play. Matching inputs and outputs within choose alternatives (most notably when using things like p:store in one branch and plain processing in the other, and after the choose) is an example.

But it comes in play in viewports as well for instance. This could perhaps be done more smartly but what I did in one particular occasion was process the result of p:directory-list using a p:viewport to act on each c:file (conditionally I thought). Within the viewport I am deleting the files. The cxf:delete extension takes no input, so I had to put a p:sink in front. Subsequent processing was expecting result however, so I had to add an empty identity to make things work as well, as csf:delete is not producing (primary) output either. It did effectively nuke those c:file elements from the listing that had been processed, which was exactly what I wanted. And with a utility step for the empty identity it was just two extra lines, but still..

I could look for more examples if you like..

> > - Maybe something specific to XMLCalabash, but why can't I just do
> > p:variable with a p:pipe connecting to parameters port? It complains
> > about context, forcing me to pipe the parameters through a
> > p:parameters first, and rerouting input around the p:parameters as
> > well.
>
> Uhm. Can you show me an example of the problem?

The ut:log step I posted in answer to Matthieu contained such a trick. It contained a ut:parameters step, but that is just a wrapper around p:parameters, and does a p:identity effectively, so it actually just adds a non-primary output stream for use in p:variable. The relevant bit was this:

		<!-- clean up parameters port input to stop p:variable from complaining -->
		<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>
			

If you expand ut:parameters you would get something like:

		<!-- clean up parameters port input to stop p:variable from complaining -->
		<p:parameters name="params">
			<p:input port="parameters"> <!-- not declared primary (bummer!), so have to bind explicitly -->
				<p:pipe step="main" port=" parameters"/>
			</p:input>
		</p:parameters>

		<p:identity>
			<p:input port="source">
				<p:pipe step="main" port="source"/>
			</p:input>
		</p:identity>
		
		<p:group>
			<p:variable name="debug" select="(//c:param[@name='debug']/@value, false())[1]"><p:pipe step="params" port="parameters"/></p:variable>

As said, this may be XMLCalabash specific, but it looks like parameters port on the 'main' returns a sequence, which p:variable doesn't like. I don't really see why parameters port should do that?

> > - Lot's of extensions don't produce output, but do take input without
> > doing much with that (most notably the file io extensions for
> > example). Why not just let them do identity transform as well, making
> > it much easier to do a large sequence of such steps..
>
> That's an intersting idea. The exproc.org steps are community driven.
> If we decide they should do the identity transform, we can do that.

I pondered with the thought creating my own library that does that, I have done that with a few already.

I saw your l:store extension, nice. I might consider using identity-store as name myself, just to make more distinction with the original p:store..

Kind regards,
Geert

PS: did you submit your epub application yet? :)

Received on Wednesday, 12 October 2011 20:38:54 UTC