Re: Alternate "parameters" draft

Henry S. Thompson wrote:
> 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).

Yes. If you want to inherit parameters from the container step with 
amendments to individual parameters, under Norm's draft you have to 
explicitly say that you want to do that inheritance. For example:

<p:xslt>
   ...
   <p:input port="parameters">
     <p:pipe step="pipe" source="parameters" />
   </p:input>
   <p:parameter name="foo" value="bar" />
   ...
</p:xslt>

will inherit all the parameters from the pipeline, and either add or 
override the value of the 'foo' parameter to 'bar'.

The other way to do it would be to say that they were inherited by 
default, but then you'd want a way of *excluding* the parameters that 
you really didn't want to pass through. I didn't go this route because:

(a) I think in most cases you *won't* want to pass through parameters if 
you're also setting parameters yourself
(b) the mechanism above seems fairly straight-forward
(c) I couldn't think of a simple mechanism of excluding parameters

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

Obviously I haven't implemented it, but I imagine that implementations 
could actually pass around a map of name/value pairs and only construct 
the <c:parameters> document when that was actually required as a 
standard input to a step.

> 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.

I think that's fine, and I think it's a great idea to allow a sequence 
of <c:parameters> documents.

> 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]?

I don't think that I can pass parameters to a pipeline that I define and 
then filter those parameters within the pipeline. For example, if I 
invoke my:funky-pipeline like:

<my:funky-pipeline>
   <c:parameter name="filter1" value="@name = 'N'" />
   <c:parameter name="filter2" value="@type = 'date'" />
   <c:parameter name="sort1" value="@subtype" />
</my:funky-pipeline>

I don't think there's a way, under your proposal, to design 
<my:funky-pipeline> so that all the parameters starting with 'filter' 
are directed to one XSLT transformation while those starting with 'sort' 
are directed to another, or to iterate over the parameters, or anything 
like that.

I could design all my pipelines so that they accept XML documents and 
options rather than parameters, but I don't really want to force users 
to create XML documents to pass in parameters to my pipeline.

So I could live with this, in the interests of the getting the spec 
done, but it wouldn't be my first choice.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Friday, 25 May 2007 19:34:22 UTC