Re: Handling Configuration File Parameters -- Historical Unrefined Approach Just for Discussion

Hi James,

That's definitely interesting and useful.

I'm a bit inspired here and in the process of creating a simple and dirty
process that has a

   - xproc template with placeholders rather than variables
   - Config files with groups of name value pair parameters
   - Grouping for readability/organization
      - XSLT to merge template and config files
   - Means of execution with multiple instances running the compiled xproc
   pipelines concurrently
   - xproc | batch | java app

I'll share my findings.

Regards
Alex

On Fri, Feb 19, 2010 at 2:51 PM, James Sulak <jsulak@gmail.com> wrote:

> Hi Alex,
>
> An eval-pipeline step has been mentioned before, but as far as I know
> no one's implemented it as an extension function.
>
> I don't know if this is what you're looking for, but I've done
> something similar at runtime (not preprocessing). I had a problem
> where I needed to edit the contents of an XQuery dynamically.  I
> settled on using a step that took parameters and replaced any
> instances of ${varname} with its string value.  For example, I would
> construct an xquery this way:
>
>    <p:identity>
>      <p:input port="source">
>        <p:inline>
>          <c:query xmlns="http://exist.sourceforge.net/NS/exist"
> start="1" max="20" cache="no">
>            <c:text>
>              declare namespace c="http://www.w3.org/ns/xproc-step";
>              let $login := xmldb:login("xmldb:exist:///db",
> "${user}", "${password}")
>              let $response :=
> xmldb:create-collection("${parent-collection}", "${collection}")
>              return (element c:result { concat(request:get-url(),
> $response) })
>            </c:text>
>          </c:query>
>        </p:inline>
>      </p:input>
>    </p:identity>
>
>    <wxp:resolve-placeholders>
>      <p:input port="parameters">
>        <p:empty />
>      </p:input>
>      <p:with-param name="user" select="$user" />
>      <p:with-param name="password" select="$password" />
>      <p:with-param name="parent-collection" select="$parent-collection" />
>      <p:with-param name="collection" select="$collection" />
>    </wxp:resolve-placeholders>
>
>
> The <wxp:resolve-placeholders/> step uses <p:parameters/> to create an
> XML out of the parameters, which is then passed to a transform which
> replaces the variable names with their values.
>
> -James
>
>
> On Fri, Feb 19, 2010 at 6:37 AM, Alex Muir <alex.g.muir@gmail.com> wrote:
> > Hi,
> >
> > I was reading posts about configuration file parameters in the xproc list
> > archives and having my own issues using them that it led me to recall my
> > solution when creating a simple xslt pipe line as probably all on this
> list
> > have done.
> >
> > Regarding handling the configuration file:
> >
> > We started with name value pair configuration declarations in the top of
> the
> > pipe which were referenced below using xpath which became cumbersome to
> use
> > over time and at some point the idea came to use a simpler perhaps
> unrefined
> > solution that worked well.
> > We had to externalize the name value pair configuration xml file to have
> > multiple configuration files, some for end users, some for more technical
> > people...
> >
> > Given the need to have multiple configuration files we preprocessed to
> > combine the configuration files to pass only one config file through the
> > pipe as passing more than one would have been more work.
> > PERHAPS THE KEY POINT: Rather than reference the configuration file using
> > xpath and having the pipeline processor to pass the configuration file as
> a
> > DOM through the whole process to find config values dynamically as they
> were
> > needed using xpath, we replaced all the xpath with '##VariableName##'
> > referencing the same variable name from the config file as the xpath was.
> > Then preprocessing we complied the new pipeline xml document finding and
> > replacing '##VariableName##' with the correct value for each
> configuration
> > file as we no longer combined config files into one as there was no need.
> >
> > The simplification saved us development time in the future.
> >
> > From what I gather this type of script preprocessing is a fairly common
> > practice.
> >
> >
> > Questions for discussion:
> >
> > Are others doing this with their xproc scripts? Why or why not?
> >
> > I wonder would it be better that I use the parameters configuration file
> as
> > it is currently  designed in xproc rather than I create a small script to
> > implement the ## Configuration version?
> >
> > Is it possible to have a small xproc pipe which executes this process and
> > then executes the regular process without running the process twice from
> the
> > command line? ( just thinking out loud here)
> >
> > Would that just require I use the "exec" step for example if I wanted to
> > launch 4 java process of the some pipe compiled with different
> > configurations?
> > I think that will work, no?
> >
> > Thanks Much
> >
> > --
> > Alex
> > https://sites.google.com/a/utg.edu.gm/alex
> >
> > Some Good Music -- mix of western and African relaxing acoustic styles
> > http://sites.google.com/site/greigconteh/
> >
>



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

Some Good Music
http://sites.google.com/site/greigconteh/