Re: Alternate "parameters" draft

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

Jeni Tennison writes:

> Alex Milowski wrote:
>> On 5/23/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>>> Alex Milowski wrote:
>>> > I'm a little confused by:
>>> >
>>> > "If no binding is provided for a parameter input port, a default
>>> > binding is constructed. If the step's container has exactly one
>>> > parameter input port, then this port is bound to it. If the container
>>> > does not have exactly one parameter input port, then this port is
>>> > bound to a document that consists only of an empty c:parameters
>>> > element."
>>> >
>>> > So, that means the in-scope parameters for the contained steps are
>>> > "bound" to any
>>> > unbound parameter input port, right?
>>>
>>> Yes, except there aren't any in-scope parameters, only parameter input
>>> ports on the container.
>> That doesn't work with how p:group can bind parameters via the
>> status quo.
>> That makes the fact that p:group as a p:parameter element not make
>> much sense.
>> http://www.w3.org/XML/XProc/docs/alternate/#p.group
>
> It works in exactly the same way. <p:group> has at least one parameter
> input port, and any <p:parameter> elements within the <p:group> are
> used to create the <c:parameters> document that's bound to that
> parameter input port. That parameter input port is then exposed to
> steps contained in the <p:group>, and by default they are passed that
> <c:parameters> document as well.

That's not what Norm's draft says.  It only combines p:parameter
bindings on a step or container with c:parameter bindings on its
parameter port in creating the set of bindings visible to the step [1]:

 If the step contains literal p:parameter elements, then the
 name/value pair specified by each of those elements is treated as if
 it appeared in a c:parameter element at the very end of the document
 on the parameter input port.

 The resulting set of name/value pairs, after resolving duplicate
 names, is passed to the step as its parameters.

(Actually, other prose _could_ be read as contradicting this. . . [2]:

  If no port attribute is specified and the step has exactly one
  parameter input port, then the parameter is added to the set of
  parameters that appear on that parameter input port.)

If we re-inforce the latter reading, which is closer to yours, we end
up with something which reconstructs the scoping behaviour of the
_status quo_, via a rather more complex mechanism. . .

But either way, that appearance is illusory, because we've actually
_lost_ the individual parameter granularity of scoping/shadowing.

Consider the following pipeline:

<p:pipeline name="top">
 <p:input port="stylesheet"/>
 . . .
 <p:group>
  <p:input port="port-for-params">
   <p:document href="my-standard-defaults.xml"/>
  </p:input>
  . . .

  <p:xslt>
   <p:input port="transform">p
    <p:pipe port="stylesheet" step="top"/>
   </p:input>
  </p:xslt>
 </p:group>
</p:pipeline>

The xslt step will see the params that come in at the group level from
the my-standard-defaults file.

Now suppose that since the stylesheet is user-specified, I realise I
should allow a user to specify parameter bindings as well, so I change
it to look like this:

<p:pipeline name="top">
 <p:input port="stylesheet"/>
 <p:input port="params"/>
 . . .
 <p:group>
  <p:input port="port-for-params">
   <p:document href="my-standard-defaults.xml"/>
  </p:input>
  . . .

  <p:xslt>
   <p:input port="transform">p
    <p:pipe port="stylesheet" step="top"/>
   </p:input>
   <p:input port="params-for-xslt">
    <p:pipe port="params" step="top"/>
   </p:input>
   </p:xslt>
 </p:group>
</p:pipeline>

where 'params-for-xslt' is the name of whatever parameter port we add to
p:xslt .

Whoops!  my-standard-defaults are lost, even if they don't overlap
with the user-specified params at all in practice, because the
granularity of inheritance has changed from params to param ports.

Sigh.

I'll think some more about this, but I think we have to go back to
param-by-param granularity of scoping, but maybe we can integrate
parameter ports in a simpler way into that view.

ht

[1] http://www.w3.org/XML/XProc/docs/alternate/#parameter-sets
[2] http://www.w3.org/XML/XProc/docs/alternate/#p.parameter
- -- 
 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)

iD8DBQFGVX6fkjnJixAXWBoRAhOaAJ9oMCoe8XeLGvNU9rHhLvyn6SRJkwCdEvH9
cADjW2voLSw4YFI2RzwihlM=
=1Sej
-----END PGP SIGNATURE-----

Received on Thursday, 24 May 2007 12:01:53 UTC