RE: injecting options and parameters into XProc

XProc doesn't allow that, but it does allow something else, which I think is more logical.

You can define a *default* value for an option at the top of a pipeline. If a step has the same option, it will use that value. And when the pipeline is invoked, it can override the value you've specified at the top of the pipeline.

Example:
<p:pipeline xmlns:p="http://www.w3.org/ns/xproc">
  <p:option name="allow-version-mismatch" value="yes"/>
  <p:option name="template-name" value="start"/>
  <p:xslt2>
    <p:input port="stylesheet">
      <p:document href="stylesheet1.xsl"/>
    </p:input>
  </p:xslt>
  <p:xslt2>
    <p:input port="stylesheet">
      <p:document href="stylesheet2.xsl"/>
    </p:input>
  </p:xslt>
  <p:xslt2>
    <p:option name="template-name" value="finish"/>
    <p:input port="stylesheet">
      <p:document href="stylesheet2.xsl"/>
    </p:input>
  </p:xslt>
</p:pipeline>

If you just initiate this pipeline, all transformations in the pipeline will allow version mismatch by default. You can override this from the command line. The spec doesn't say it, but it doesn't need to - the word "default" says it. Also, the first two transformations will start at the "start" template. The last overrides the default value, so it will always start at the "finish" template, and you won't be able to override it without tweaking the pipeline, since it's specified on per-step basis.

Someone correct me if I'm wrong.

-----Original Message-----
From: public-xml-processing-model-comments-request@w3.org [mailto:public-xml-processing-model-comments-request@w3.org] On Behalf Of James Fuller
Sent: Monday, October 08, 2007 10:00 PM
To: jeni@jenitennison.com
Cc: public-xml-processing-model-comments@w3.org
Subject: Re: injecting options and parameters into XProc


On 10/8/07, Jeni Tennison <jeni@jenitennison.com> wrote:
> Jim,
>
> James Fuller wrote:
> > the use case I am highlighting is that of execution configurability.
> >
> > if I can use an analogy with Ant.
>
> You can, but since I don't use Ant it won't mean much to me.
>
> > the current method in xproc, as u describe, is akin to setting
> > presetdef in Ant. That is setting default values of options within
> > xproc code. This is a good thing.
> >
> > to go further, with Ant presetdefs, I can use Ant properties to make
> > these preset default values definable at from the commandline.
>
> In XProc, when you invoke the pipeline from the command line, you can
> pass in values for the options declared on the pipeline. Those option
> values can be passed on to the steps that are invoked inside the pipeline.
>
> In what way is this different from "making default values definable from
> the command line"?
>
> Or are you talking about the options being XPath expressions that choose
> values from an input document? You can do that too (just remember to set
> the namespaces at the same time).
>
> > having this is useful for;
> >
> > * enabling fully configuration of xproc at parse time (options can
> > remain invariant after values are parsed, so I see no big issue with
> > this)
> >
> > * u do not ask the person executing xproc, to have to know xproc, e.g.
> > dig into the code and change things
> >
> > as with any useful software, there should be a larger body of users
> > just 'running' the script...which is what this use case highlights.
>
> Yes, precisely. When you run the pipeline from the command line, you can
> set (a) XProc processor options, as defined by the processor, (b)
> pipeline options, as defined by the pipeline, (c) pipeline parameters,
> which you "just know" are used in XSLT stylesheets used by the pipeline.

this is a perfect characterization of the use case I am trying to
describe ..... I just can't find it explicitly stated in the spec
(like with parameters) anywhere ;)

here is an paraphrased example

I use p:xslt2, in multiple places in an example xproc

<p:xslt2">
     <p:option name="allow-version-mismatch" value="true"/>
     <p:option name="output-base-uri"/>
     <p:option name="allow-collections" value="true"/>
</p:xslt2>

I would like to define in the declare-step a default value of false
for 'allow-version-mismatch' in library.xml.

<p:declare-step type="p:xslt2">
     <p:option name="allow-version-mismatch" value="false"/>
</p:declare-step>

but I would like to be able to override this by defining via commandline

e.g.

xproc somexproc.xml allow-version-mismatch=true


----------

some other thoughts;

perhaps we are confusing things with serialization options?

btw, as an aside (and to confuse this thread), here is my top
confusing terms list in Xproc (things I know end users will have a
problem grokking 1st time around)

* ensuring users know the difference between options and parameters

* ensuring users know how inputs (and outputs) interact with steps

* discussing atomic versus compound steps, whilst also discussing
subpipeline and pipelines

cheers, Jim Fuller

Received on Monday, 8 October 2007 19:26:07 UTC