W3C home > Mailing lists > Public > xproc-dev@w3.org > October 2011

RE: New to Xproc Question : conditionnal "output port" definition?

From: Geert Josten <geert.josten@daidalos.nl>
Date: Wed, 12 Oct 2011 18:21:03 +0200
To: Matthieu Ricaud-Dussarget <matthieu.ricaud@igs-cp.fr>, "xproc-dev@w3.org" <xproc-dev@w3.org>
Message-ID: <B26C615F8546A84C81165A7BC8BE61A020FC0F9492@EXMBXC01.ms-hosting.nl>
Hi Matthieu,

About the input of p:error. You are right, there was already a p:input port="source" there. It would have made sense to have it on p:choose instead, but that is not possible. The p:identity just before is what gets closest, it supplies a primary input for all choose alternatives. The p:xpath-context (as suggested by Norm, thnx!) is interesting as well, but only applies to the when tests..

Kind regards,
Geert

-----Oorspronkelijk bericht-----
Van: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] Namens Matthieu Ricaud-Dussarget
Verzonden: woensdag 12 oktober 2011 17:08
Aan: xproc-dev@w3.org
Onderwerp: Re: New to Xproc Question : conditionnal "output port" definition?

Hi Geert,

Once again, thanks a lot for your help.

> <p:xslt ... name="xslt"/>
> <p:store .../>
> ...
> <p:error ...>
> 	<p:input port="source">
> 		<p:pipe step="xslt" port="result"/>
> 	</p:input>
> </p:error>
I thought the input port of <p:error> shall contains the error message 
itself (within <p:inline> for example). I guess I have to get 
information on how to deal with error code and message to display.
Anyway the problem is just above :
<p:when 
test="count(distinct-values(/igs:aggregate/doc/pages/page/@viewportX))!=1">
<p:error ...>
</p:when>
My guess is that the xproc processor is not able to perform the xpath 
test above because it can't define a context node at this point of the 
pipeline... because just above is a <p:store> which doesn't through any 
output!

> Another option, which is most often easier, is to put a p:identity with such an input binding after p:store:
Yes you are right, it works !
And I now understand why my former xslt step direct after <p:store> 
works : I piped the input to the good step ... jumping back over the 
<p:store>.
Cool that's clear !

> But since this is a common case, it is worthwhile to declare a helper step to do that.
100% agree !
> I wrote the following, which combines a p:store with such input rerouting, together with a p:choose so the p:store is only done if a debug parameter was passed through..
I actually don't know how to use such a self define step.
My xpl file starts with <p:declared-step> element : It seems I can't add 
a <p:declared-step> within my root element <p:declared-step>.
I thought I should put it in another xpl document and then import it 
from my current xpl with <p:import> but... It's seems <p:import> is not 
allowed as child of <p:declared-step>.

Maybe I should use <p:pipeline> as root element but I actually thought 
it was better to start with <p:declared-step> so I can really understand 
binding concepts in Xproc.

But this consideration is a bit out of the subject : I will keep the 
<p:identity> solution and go further with my pipeline. Later I'll try to 
make it more simple and maybe modular.

Thanks again for your response.

Matthieu
Received on Wednesday, 12 October 2011 16:21:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 October 2011 16:21:29 GMT