W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > July 2007

Re: parameters and pipelines

From: Innovimax SARL <innovimax@gmail.com>
Date: Fri, 6 Jul 2007 14:56:59 +0200
Message-ID: <546c6c1c0707060556w3b0b4187pb8cb147569aaf663@mail.gmail.com>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
Cc: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>

Henry,

May I disturb this nice proposition with the namespace matter for
QName parameter names or even values ?

Mohamed

On 7/6/07, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We've got several gaps in this area at the moment.
>
> 1) The current draft doesn't say anything about how you get access to
>    parameters passed to pipelines 'from outside';
>
> 2) The current draft doesn't say anything about how you get access to
>    parameters passed to pipelines when invoking them by name;
>
> 3) There is an ednote in the current draft [1] raising the question of
>    whether steps which declare no parameter inputs get the pipeline
>    parameters by default.
>
> Here are some suggestions about how we deal with this, based in part
> on IRC discussion with Norm (but don't assume he agrees with any of
> this):
>
> 1) Sets of parameter name/value pairs may be externally specified in
>    two ways, which I'll call 'named' and 'anonymous':
>
>    named: a named collection of name/value pairs
>    anonymous: an un-named collection of name/value pairs
>
>    For example
>
>  > xproc -params xslt1 x=1 y=1 -params xslt2 x=2 y=2 -params debug=no pipe.xpl
>
>    might be one way to produce two named sets and one anonymous set
>
>    p:pipeline allows parameter inputs (a parameter input is a static
>    error on any other container).
>
>    It's a dynamic error if a named parameter set is specified
>    externally for a pipeline which does not have a parameter input of
>    the same name.  An unnamed parameter set is always allowed.
>
>    Steps can access named parameter sets in the obvious way, e.g.
>
>      <p:input name='foo' kind='parameter'>
>       <p:pipe step='pipe' port='xslt1'/>
>      </p:input>
>
>    Steps can access the unnamed parameter set using defaulting:
>
>      <p:input name='bar' kind='parameter'/>
>
> 2) A pipeline invoked by name gets its parameters in an analogous way:
>
>    2a) Iff the pipeline was defined with one or more parameter input
>        ports, the invocation may include a binding for those ports:
>
>        <p:pipeline type='my:pipe'>
>         . . .
>         <p:input port='xslt1' kind='parameter'/>
>         . . .
>        </p:pipeline>
>
>        <my:pipe>
>         . . .
>         <p:input port='xslt1'>
>          <p:inline>
>           <c:parameter name='x' value='3'/>
>          </p:inline>
>         </p:input>
>         . . .
>        </my:pipe>
>
>    2b) Explicit use of p:parameter in a named pipeline invocation
>        produces anonymous parameters for the invoked pipeline:
>
>        <p:pipeline type='my:pipe'>
>          . . .
>          <p:xquery>
>           <p:input name='baz' kind='parameter'/>
>           . . .
>          </p:xquery>
>          . . .
>         </p:pipeline>
>
>         <my:pipe>
>          <p:parameter name='forXQuery' value='17'/>
>          . . .
>         </my:pipe>
>
> Open questions:
>
>  A) As specified above there is no way to pass the anonymous set from
>     the top-level pipeline down anonymously to a pipeline invoked by
>     name, which is either a bug or a feature. . .
>
>  B) Should <p:input kind='parameter' .../> as a child of p:pipeline be
>     purely a declaration, i.e. be necessarily empty, or should we
>     allow it to have content, in which case how do we treat that
>     content -- merge it with external input, ignore it if there's any
>     external input, . . .?
>
>  C) There's a covert assumption in the current spec., unchanged by any
>     of the above, that the API from the runtime to step
>     implementations will have a way of accessing parameters.  Since
>     parameters aren't declared, this access will have to be
>     undifferentiated as to port name, that is, it's just "give me all
>     the parameter bindings you have for this instance of this step".
>
>     So question (3) above becomes, in the terms of the proposal in (1)
>     and (2) above, "Under what circumstances should the runtime
>     deliver the anonymous parameter set when a step implementation
>     asks for its parameters?"
>
>     Possible answers:
>       a) Always;
>       b) Only if a parameter port has been explicitly bound to them
>          (as in the 'bar' example under (1) above);
>       c) If a parameter port has been explicitly bound to them, or if
>          no parameter ports have been bound at all.
>
>     I believe Alessandro favours (b), and I favour (c).  The
>     difference is manifested in the case of a simple p:xslt step -- if
>     the pipeline is minimal, i.e.
>
>      <p:pipeline>
>       <p:xslt>
>        <p:input port="transform">
>         <p:document href="..."/>
>        </p:input>
>       </p:xslt>
>      </p:pipeline>
>
>      and I invoke it with some parameters (either 'from outside', or
>      by invoking it by name), does the XSLT step see the parameters?
>      I think users will expect it to, and I think they're right.
>
>      On proposal (c) above, if you want to _protect_ a step from
>      parameters, you would write e.g.
>
>      <p:pipeline>
>       <p:xslt>
>        <p:input port='mum' kind='parameter'>
>         <p:empty/>
>        </p:input>
>       </p:xslt>
>      </p:pipeline>
>
>      thereby forestalling the delivery of the anonymous set.
>
> ht
>
> [1] http://www.w3.org/XML/XProc/docs/WD-xproc-20070706/#default-params
> - --
>  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
>                      Half-time member of W3C Team
>     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
>             Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
>                    URL: http://www.ltg.ed.ac.uk/~ht/
> [mail really from me _always_ has this .sig -- mail without it is forged spam]
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFGjhbFkjnJixAXWBoRAhWuAJ9ztlaeG1QMIf55VdyGUASrKu0rQACdEdB3
> j0eliSE6kCHNCxx2GKpJMVM=
> =gHcj
> -----END PGP SIGNATURE-----
>
>


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Friday, 6 July 2007 12:57:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:53 GMT