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

Re: Parameter binding

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Wed, 04 Apr 2007 16:30:05 +0100
To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
Message-ID: <f5b1wj017k2.fsf@hildegard.inf.ed.ac.uk>

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

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

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


  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

 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.


[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

[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]
Version: GnuPG v1.2.6 (GNU/Linux)

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:42 UTC