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:00:31 UTC