- From: Norman Walsh <ndw@nwalsh.com>
- Date: Fri, 06 Jul 2007 10:05:00 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87y7htzkz7.fsf@nwalsh.com>
/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 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).
Yes.
| 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.
Yes.
| 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>
The kind of input is determined when it's declared. They're just like
any other input when they're used:
<p:input name='foo'>
<p:pipe step='pipe' port='xslt1'/>
</p:input>
| Steps can access the unnamed parameter set using defaulting:
|
| <p:input name='bar' kind='parameter'/>
That would be:
<p:input name='bar'/>
I guess we could do this. That makes this exactly the same as not
specifying any p:input for the parameter input at all, right?
| 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>
Yes, that all sounds ok, I think.
| 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. . .
That's not what I expected. If
<p:xslt/>
is going to get the anonymous parameters by default, then
<my:pipe/>
ought to as well.
| 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, . . .?
I'd be happy if it was just a declaration. If it isn't, then its
binding should be treated like the other input bindings, only used if
there's no binding given by the caller.
| 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".
Yes, I guess that's true. I wonder if we should forbid p:parameter
elements on an atomic step which does not have a parameter port.
| 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="stylesheet">
| <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>
Except that the parameter port on p:xslt has the name 'parameters' and
doesn't get a declaration on the use:
<p:input port="parameters">
<p:empty/>
</p:input>
| </p:xslt>
| </p:pipeline>
|
| thereby forestalling the delivery of the anonymous set.
Does the following sound good to anyone?
1. If an atomic step has no parameter input port, then it gets no
parameters. Use of p:parameter is forbidden.
2. If an atomic step has a parameter input port, then all the
parameters appear on that port.
3. If an atomic step has two or more parameter input ports, then it
gets whatever parameters appear on those ports; p:parameter is
forbidden.
4. Compound steps have no influence on parameters; they're
transparent.
5. Pipeline parameters that are anonymous are passed to called
pipelines as the anonymous parameters on those pipelines.
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> | A child becomes an adult when he
http://nwalsh.com/ | realizes he has a right not only to be
| right but also to be wrong.--Thomas
| Szasz
Received on Friday, 6 July 2007 14:05:17 UTC