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

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

From: Matthieu Ricaud-Dussarget <matthieu.ricaud@igs-cp.fr>
Date: Wed, 12 Oct 2011 18:46:26 +0200
Message-ID: <4E95C462.1020407@igs-cp.fr>
To: xproc-dev@w3.org
Thank you Romain.

> You can definitely have p:declare-step as a child of p:declare-step, see:
> http://www.w3.org/TR/xproc/#p.declare-step
Right !
It seems my xml editor (oXygen) doesn't accept this... Or I miss placed 
it , I don't know ?
I can't find the schema used by oXygen, I'll investigate this.

The w3c definition also refers to p:import inside p:declare-step... 
oXygen doesn't validate this. Other investigation needed.

I also see p:log in w3c def.. maybe I should use it instead of p:store. 
Another investigation!

> A common practice is to group utility steps (p:declare-step) in a 
> p:library document that you can import in other pipelines using p:import.
>
Thanks for the tip, that's helpfull. I will probably use this when I 
understand the xproc basic.

Regards,

Matthieu.
> Hope this helps,
> Romain.
>
>
> Le 12 oct. 11 à 17:08, Matthieu Ricaud-Dussarget a écrit :
>
>> 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
>>
>
>
>


-- 
Matthieu Ricaud
IGS-CP
Service Livre numérique
Received on Wednesday, 12 October 2011 16:47:02 GMT

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