Re: Difficulty overriding parameter values

Hi Vojtech,

Thanks.

I get that now given the select statement would be selecting from the wrong
input. It's taking me a while to understand the input/output and pipes in
xproc.

I was just investigating without luck if using a p:group I could wrap say 5
variables and specify only once which port the following statements are
using?  (had a pascal "with" statement on my mind)  Is is possible to do
something that in xproc?

Thanks
Alex


On Tue, Dec 8, 2009 at 12:20 PM, <Toman_Vojtech@emc.com> wrote:

>  Hi Alex,
>
> The p:pipe binding is necessary here because in this case, you want to read
> the documents appearing on the "par" *parameter* port of the pipeline.
> Without the p:pipe binding, the p:variable would be connected to the
> "source" document input port of the pipeline.
>
> Regards,
> Vojtech
>
>  ------------------------------
>  *From:* xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] *On
> Behalf Of *Alex Muir
> *Sent:* Tuesday, December 08, 2009 1:12 PM
> *To:* Kevin Flynn
> *Cc:* xproc-dev@w3.org
>
> *Subject:* Re: Difficulty overriding parameter values
>
>  Hi Kevin,
>
> I'm just getting a chance now to get your example running. It has helped me
> out a tonne and I'm sure it will help others down the road.
>
> One thing that I don't understand is why <p:pipe step="pipe-abc"
> port="par"/> needs to be inside the p:variable. What function does it have
> in there?
>
>
>         <p:variable name="input-file"
> select="/c:param-set/c:param[@name='input-file']/@value">
>             <p:pipe step="pipe-abc" port="par"/>
>         </p:variable>
>
>    <p:load name="load">
>             <p:with-option name="href" select="$input-file"/>
>         </p:load>
>
>
> Thanks Much
> Alex
>
>
> On Fri, Nov 27, 2009 at 8:51 AM, Kevin Flynn <kevin@escenic.com> wrote:
>
>> I received the following request from alex.g.muir@gmail.com:
>>
>>
>>  I was looking over your posts at the following link regarding Xproc and
>> using and xml file
>>  to drive the processing. I'm looking to do something similar I was
>> wondering if you could
>>  share some solution on the xproc dev list to show how you ended up
>> solving what you were doing.
>>
>>  http://lists.w3.org/Archives/Public/xproc-dev/2009Jul/att-0013/00-part
>>
>> So here goes:
>> =========================================================
>> It's still a work in (intermittent) progress, but what I currently do is
>> use the http://www.w3.org/ns/xproc-step param-set element for making
>> configuration files. For example:
>>
>> ---------------------
>> <c:param-set xmlns:c="http://www.w3.org/ns/xproc-step">
>>
>>  <!-- run this pipeline... -->
>>  <c:param name="pipeline" value="xyz"/>
>>
>>  <!-- with these parameters... -->
>>  <c:param name="input-file" value="file:///some/input/file.ext"/>
>>  <c:param name="output-file" value="file:///some/output/file.ext"/>
>>  <c:param name="abc" value="def"/>
>>
>> </c:param-set>
>> -----------------------
>>
>> A configuration file always contains one "master" parameter, "pipeline"
>> that names the actual pipeline to be run. All the other parameters are the
>> parameters required by that pipeline.
>>
>> This parameter file is submitted as the only input to a master pipeline
>> (called run-pipe.xpl) which just contains a big choose element that runs the
>> specified pipeline and passes on all the specified parameters.
>>
>> ---------------------
>> <p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
>>               xmlns:c="http://www.w3.org/ns/xproc-step"
>>               xmlns:pipes="http://xmlns.escenic.com/2009/xproc/my-pipes"
>>               xmlns:lib="http://xmlns.escenic.com/2009/xproc/my-library"
>>               name="run-pipe">
>>
>>     <p:input port="source"/>
>>     <p:input port="par" kind="parameter"/>
>>
>>     <!-- output port not needed, but this will output the URL of the saved
>> file -->
>>     <p:output port="result">
>>       <p:pipe step="end-of-pipe" port="result"/>
>>     </p:output>
>>
>>  <p:import href="pipes.xpl"/>
>>
>>  <p:variable name="pipeline"
>> select="/c:param-set/c:param[@name='pipeline']/@value">
>>   <p:pipe step="run-pipe" port="par"/>
>>  </p:variable>
>>
>>  <p:choose>
>>   <p:when test="$pipeline='abc'">
>>     <pipes:abc name="abc">
>>       <p:input port="par" kind="parameter">
>>         <p:pipe step="run-pipe" port="par"/>
>>       </p:input>
>>     </pipes:abc>
>>   </p:when>
>>   <!-- ...lots more "whens"... -->
>>  <p:otherwise>
>>     <p:identity>
>>       <p:input port="source">
>>         <p:inline>
>>           <ebd:message>Pipe not found</ebd:message>
>>         </p:inline>
>>       </p:input>
>>     </p:identity>
>>   </p:otherwise>
>>  </p:choose>
>>
>>  <p:identity name="end-of-pipe"/>
>>
>> </p:declare-step>
>> ---------------------
>>
>> pipes.xpl contains all the actual pipelines, each of which has the
>> following basic structure:
>>
>> ---------------------
>>  <p:declare-step type="pipes:abc" name="pipe-abc">
>>
>>       <p:input port="source"/>
>>       <p:input port="par" kind="parameter"/>
>>       <p:output port="result">
>>         <p:pipe step="store" port="result"/>
>>       </p:output>
>>
>>   <p:import href="library.xpl"/>
>>
>>   <p:variable name="input-file"
>> select="/c:param-set/c:param[@name='input-file']/@value">
>>     <p:pipe step="pipe-abc" port="par"/>
>>   </p:variable>
>>   <p:variable name="output-file"
>> select="/c:param-set/c:param[@name='output-file']/@value">
>>     <p:pipe step="pipe-abc" port="par"/>
>>   </p:variable>
>>
>>   <p:load name="load">
>>     <p:with-option name="href" select="$input-file"/>
>>   </p:load>
>>
>>   <lib:some-basic-pipe name="some-basic-pipe">
>>     <p:input port="par" kind="parameter">
>>       <p:pipe step="pipe-abc" port="par"/>
>>     </p:input>
>>   </lib:some-basic-pipe>
>>
>>   <!-- ...more pipes from library.xpl... -->
>>
>>   <p:store name="store">
>>     <p:with-option name="href" select="$output-file"/>
>>   </p:store>
>>
>>  </p:declare-step>
>> ---------------------
>>
>> The pipelines in pipes.xpl extract the parameters they need to "load"
>> input files and "store" output files, and otherwise just call a sequence of
>> simpler pipelines from library.xpl.
>>
>> The pipelines in library.xpl are mostly just sequences of xslt and other
>> atomic steps:
>>
>> ---------------------
>>  <p:declare-step type="lib:some-basic-pipe" name="lib-some-basic-pipe">
>>       <p:input port="source"/>
>>       <p:input port="par" kind="parameter"/>
>>       <p:output port="result">
>>         <p:pipe step="trf2" port="result"/>
>>       </p:output>
>>     <p:xslt name="trf1">
>>     <p:input port="stylesheet">
>>         <p:document href="xsl/trf1.xsl"/>
>>     </p:input>
>>   </p:xslt>
>>
>>   <p:xslt name="trf2">
>>     <p:input port="stylesheet">
>>       <p:document href="xsl/trf2.xsl"/>
>>     </p:input>
>>   </p:xslt>
>>  </p:declare-step>
>> ---------------------
>>
>> All the parameters specified in the configuration file are passed in to
>> all the transformations, which can use the ones they need. trf1.xsl, for
>> example, might contain:
>>
>> ---------------------
>>   <xsl:param name="abc"/>
>> ---------------------
>>
>> and would therefore use the setting 'def' specified in the configuration
>> file.
>>
>> This structure means you can build up a library.xpl containing basic pipes
>> that can be re-used in various ways, and a higher-level pipes.xpl that slots
>> them together in more complex ways and deals with reading and writing files.
>> It's all accessible in a uniform way - one pipe to call them all, plus a
>> configuration file. Since I'm using the standard
>> http://www.w3.org/ns/xproc-step param-set element for the configuration
>> file, you can alternatively specify parameters on the command line.
>>
>> In order to make this framework really useable, two things are needed:
>>
>> - strict naming conventions for parameters
>> - an automated means of exposing all the parameters used by a particular
>> pipeline.
>>
>> What I am thinking of doing is defining a standard way of documenting all
>> parameters, wherever they appear - in XSLT transformations or pipes - most
>> likely using a namespace. It would then be possible to make an XSLT
>> transformation that, given the name of one of the top-level pipes in
>> pipes.xpl, could drill down through all the called sub-pipes and
>> transformations, find all the parameters used and generate a complete,
>> fully-documented configuration file.
>>
>> Any advice, suggestions, offers of help etc. are more than welcome.
>>
>> If this list is an inappropriate forum for this kind of discussion (most
>> posts seem to be focused on the specification, rather than applications),
>> maybe somebody can suggest an alternative?
>>
>> Regards,
>>
>> Kevin Flynn
>>
>>
>
>
> --
>
> Alex
> https://sites.google.com/a/utg.edu.gm/alex
>
>


-- 

Alex
https://sites.google.com/a/utg.edu.gm/alex