Re: On parameters

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Norman Walsh writes:

> HST wrote:
> | 1) We are grabbing another port name for pipeline use;

> Yes. There seem to be two possibilities: grab the name "parameters" or
> add some sort of 'type' attribute to inputs so that authors can
> indicate which one(s) are for parameters.

I actually prefer grabbing the name, I was just noting this for the
record as it were.

> |  c) If a step-type is declared to take a 'parameters' input, and no
> |     binding for that port is given on an instance of that step, then
> |     that instance sees all and only the #pipeline-parameters and the
> |     parameters explicitly specified with <p:parameter> directly within
> |     that instance (and the latter take precedence).
> |
> | So you can 'protect' a step _type_, by not declaring a 'parameters'
> | input for it, but if a step type _is_ declared to have a 'parameters'
> | input port, then you have to do
> |
> |   <p:input port="parameters">
> |    <p:empty/>
> |   </p:input>
> |
> | to 'protect' an _instance_ of such a step type.  I guess I think
> | that's about right.
>
> Or, alternatively, if you don't provide a binding for the parameters
> port, then the default is the same as a) (i.e., no parameters by
> default).

Well, I disagree -- see previous discussion and thread about making
XProc behave like XSLT. . .

> In this case, you have to add a parameters port and
>
>   <p:input port="parameters">
>     <p:pipe step="main" port="parameters"/>
>   </p:input>
>
> if you want the pipeline parameters passed through.

Arghh!  You just added a whole additional bunch of functionality,
namely that parameter ports are visible to other parameter ports, and
that you have to declare one in p:pipeline to get at the external
params.  I don't like _either_ of those changes (they weren't
mentioned in your proposal).

> <p:pipeline name="main" xmlns:p="http://www.w3.org/2007/03/xproc">
> <p:input port="source"/>
> <p:output port="result"/>
> <p:input port="parameters" maybe-some-type="parameters"/> <!--this-->

I want that to be built-in, consistent with the above comment.

> That doesn't seem like too large a burden.

It does to me -- I still want the pipeline author to not have to do
_anything_ in the 90% case, where a pipeline is created simply to wrap
e.g. xinclude plus xslt.

> I suppose it's a little simpler if we say that there is exactly one
> parameter port and it's named "parameters" and you don't have to/may not
> declare it.

As I suggested, I prefer "don't have to, and if you don't you don't
get any" for step type declarations, and "you can't" for compound
steps (except for p:pipeline).

For my 90% story to be true, there has to be a special story for the
p:pipeline itself.  I think we need to reconsider the whole question
of defaults for p:pipeline, particularly the top-level one. . .

ht
- -- 
 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)

iD8DBQFGcVOqkjnJixAXWBoRAlqqAJ9sbWtCvkf+W+oAQXIp62ga6R+lKQCeJRMU
jnDQ51qjIpcE5hPabucI0aY=
=3S6W
-----END PGP SIGNATURE-----

Received on Thursday, 14 June 2007 14:42:01 UTC