Re: Alternate "parameters" draft

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

So after thinking a bit more about this, I'm left with two things at
least I don't like at all:

 1) Parameter inheritance is now very complicated -- in the absence of
    any parameter ports, parameters are effectively inherited and
    shadowed on an individual basis, but in the _presence_ of explicit
    parameter port bindings, an individual parameter binding may be
    hidden even though no parameter of that name was presented to the
    relevant parameter port (see example A below).

    And parameter port bindings are shadowed on a whole-document
    basis, so that I have to explicitly join parameter documents by
    multiple references (see example B below), and parameters set by
    parameter port bindings are _not_ visible inside named pipes if
    they also happen to use parameter ports (see example C below).

 2) In the case where both individual parameter binding and parameter
    port binding occur, in at least some cases the engine will have to
    compute and make available a synthetic c:parameters document (see
    example D below).

I have an alternate proposal, which I believe is both much simpler to
explain and to implement, and which provides all the functionality of
the current 'alternative' [2]:

 To the _status quo_ (inherited, scoped, individual parameter
 bindings, per [1] as of 10 May), simply add a single new element,
 let's call it p:parameters, allowed once only in all steps (including
 containers), content model as of p:input, that is

 (p:inline|p:document|p:pipe)+

 Contents should be a sequence of c:parameters documents, containing
 c:parameter*.

 Parameter semantics are unchanged from [1] except that we treat the
 c:parameter name-value pairs as if they were p:parameter name-value
 pairs on the step, occuring _before_ any explicit p:parameter
 elements there.

That's it -- consistent inheritance and scoping, but the ability to
construct, target and manipulate groups of parameter bindings.  Jeni,
Norm -- is there anything you _can't_ do with this mechanism that you
could do with [2]?

ht

Examples (stipulate that we define our XSLT step with

 <p:input port="params" parameters="yes"/>

Example A:

<p:pipeline>
 <p:option name="debug"/>
 <p:parameter name="debug" value="$debug"/>

 . . .

 <p:xslt>
  <p:input port="params">
   <p:inline>
    <c:parameters>
     <c:parameter name="diff" value="0"/>
    </c:parameters>
   </p:inline>
  </p:input>
 </p:xslt>
</p:pipeline>

There will be _no binding_ for the 'debug' parameter visible within
the XSLT step.

Example B:

<p:pipeline>

 . . .

 <p:group name="g">
  <p:input port="defaults" parameters="yes">
   <p:document href="my-parms.xml"/>
  </p:input>
 
  . . .

  <p:xslt>
   <p:input port="transform">...</p:input>
  </p:xslt>

  <p:xslt>
   <p:input port="transform">...</p:input>
   <p:input port="params">
    <p:document href="my-parms.xml"/>
    <p:inline>
     <c:parameters>
      <c:parameter name="diff" value="0"/>
     </c:parameters>
    </p:inline>
   </p:input>
  </p:xslt>
</p:pipeline>

I have to explicitly reference the my-parms.xml document a second time
in the second XSLT step (but not in the first).

Example C:

<p:pipeline name="utility">

 . . . Steps X . . .

 <p:group>
  <p:input port="defaults" parameters="yes">
   <p:document href="my-parms.xml"/>
  </p:input>
 
 . . . Steps Y . . .
 </p:group>
</p:pipeline>

<p:pipeline>
 <p:option name="debug"/>
 <p:parameter name="debug" value="$debug"/>
 . . .

 <my:utility>
  . . .
 </my:utility>
</p:pipeline>

The 'debug' parameter will be visible to Steps X, but not to Steps Y.
There is _nothing_ you can do in the outside pipeline to get
parameters into Steps Y.

Example D:

<p:pipeline>

 . . .

 <p:group name="g">
  <p:input port="defaults" parameters="yes">
   <p:document href="my-parms.xml"/>
  </p:input>
  <p:parameter name="foo" value="baz"/>
 
  . . .

  <p:xslt>
   <p:input port="transform">...</p:input>
   <p:input port="params">
    <p:pipe step="g" port="defaults"/>
    <p:inline>
     <c:parameters>
      <c:parameter name="diff" value="0"/>
     </c:parameters>
    </p:inline>
   </p:input>
  </p:xslt>
</p:pipeline>

The p:pipe in the "params" port must see a synthetic c:parameters
document combining my-parms.xml and a binding for 'foo' to 'baz'.

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

iD8DBQFGVZa0kjnJixAXWBoRAruyAJ9xnSFqXrmj5QJX0voeWbHsi9vJJACfWfUH
TeQAsFqNYPIEvtLOWvWZ7pE=
=0qxC
-----END PGP SIGNATURE-----

Received on Thursday, 24 May 2007 13:44:43 UTC