- From: Matthieu Ricaud-Dussarget <matthieu.ricaud@igs-cp.fr>
- Date: Wed, 12 Oct 2011 18:46:26 +0200
- 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 UTC