- From: Innovimax SARL <innovimax@gmail.com>
- Date: Fri, 6 Jul 2007 14:56:59 +0200
- 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 UTC