Re: Parameter binding

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

ht writes:

>     <p:pipeline xmlns:my="http://www.example.com/mypipe">
>
>      <p:input port="stdin"/>
>      <p:parameter name="my:parm" value="true"/>
>      <p:output port="stdout"/>
>
>      <p:declare-step type="my:xmpl">
>       <p:input port="in"/>
>       <p:parameter name="my:parm" required="yes"/>
>       <p:output port="out"/>
>      </p:declare-step>
>
>      <p:xinclude/>
>
>      <my:xmpl/>
>
>     </p:pipeline>
>
> Is this a valid pipeline or not?  Where do you look in the spec. to
> get the answer?

So, I'll answer my own questions: no it's not valid.  In 5.7.1 [1] the
spec. says that "If a parameter is required, it is a static error to
invoke the step without specifying a value for that parameter."  Well,
we _have_ specified a value for that parameter, right? -- it's right
there at the top of the pipeline.  Well, no.  In 2.5 [2] the
spec. says

  "All of the in-scope parameters are available to the processor for
   computing actual parameters. The actual parameters passed to a step
   are those that are _explicitly identified_ with p:parameter or
   p:import-parameter tags on the actual step." [emphasis added]

I believe the consequence of this is that either of the following are
correct:

 <my:xmpl>
  <p:import-parameter name="my:parm"/>
 </my:xmpl>
 
 <my:xmpl>
  <p:parameter name="my:parm" select="$my:parm"/>
 </my:xmpl>

But I have to say the second is dodgy -- it's not clear what
environment is appealed to for the evaluation of the variable
reference, and the prose in 5.7.3 suggests it's actually not allowed.

I think this should be allowed, partly because at least some
programming languages allow this -- consider LISP, where

 (lambda (x)
   (let (x (+ x x))
     (* x x)))

computes, somewhat obscurely, (2x)^2, and Python, where

  x=3

  def f(x=x+x):
    return x*x

  print f()

will print 36, but more importantly because the environment which the
p:import-parameter should use clearly does _not_ create a loop, and
the XPath should be seeing the same environment.
 
In other words, and perhaps we should say this explicitly, the
in-scope parameters of the environment are _only_ available in two
ways:

 1) via XPath variable references;
 2) via p:import-parameter.

I guess I think every place we allow an XPath we should say which
environment it is whose in-scope parameters provide the variable
binding static context, and likewise whereever p:import-parameter is
allowed we should say which environment it is whose in-scope
parameters are available for import.  When we have both, as for
e.g. vanilla steps, that environment should be the same in both cases.

> Would it make a difference if the two <p:parameter>s used name="parm",
> i.e. no namespace?

I don't think so.  We don't have a notion of local or global parameter.

ht

[Final quibble -- I find 5.7.2 quite confusing -- the bit in
pink/purple is not actually a valid parameter use -- I think the prose
of 5.7.2 and 5.7.3 should be collapsed, and the first pink/purple box
eliminated.]

[1] http://www.w3.org/XML/XProc/docs/langspec.html#parameter-declaration
[2] http://www.w3.org/XML/XProc/docs/langspec.html#environment
- -- 
 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)

iD8DBQFGE8R+kjnJixAXWBoRArPrAJ9R+Qe/xNtIuq770sudv9Vq5MN7MwCfTkax
h9opdfJoleSAcvQOOqMujMI=
=j6JL
-----END PGP SIGNATURE-----

Received on Wednesday, 4 April 2007 15:30:08 UTC