Re: Revised parameters proposal

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| I think we're getting there. A few more comments from me.
|
| Norman Walsh wrote:
|> This proposal is my proposal from a few days ago adjusted to address
|> the comments made by Alex, Henry, and Jeni.
|>
|> 1. No more automatic inheritance. Consequently, remove parameters
|>    from compound steps.
|>
|> 2. Add a grouping mechanism, a la XSLT attribute sets:
|>
|>    <p:parameter-set
|>      name = NCName>
|>     (p:inline|p:pipe|p:document|p:parameter*)
|>    </p:parameter-set>
|>
|>    For V1, I propose that p:parameter-set be allowed only as a child
|>    of p:pipeline.
|
| Is it allowed between steps or only before the subpipeline? I think
| the latter will be hard to use, so I hope it's the former.

I hadn't thought about it. I'd have been tempted to say only at the
beginning, like p:option and p:parameter, but...

| In fact, I'm not all that convinced that parameter sets will get much
| reuse, so rather than forcing people to do:
|
| <p:pipeline ...>
|   ...
|   <p:parameter-set name="my-xslt-parameters">
|     <p:pipe step="foo" source="result" />
|     <p:parameter name="view" value="default" />
|   </p:parameter-set>
|   ...
|   <p:xslt use-parameter-sets="my-xslt-parameters">
|     ...
|   </p:xslt>
| </p:pipeline>
|
| I think we should allow:
|
| <p:pipeline ...>
|   ...
|   <p:xslt>
|     ...
|     <p:parameter-set>
|       <p:pipe step="foo" source="result" />
|       <p:parameter name="view" value="default" />
|     </p:parameter-set>
|   </p:xslt>
| </p:pipeline>
|
| The proximity of the construction of the parameter set and the use of
| the parameter set will help users.
|
| [In fact, I think that <p:parameter-set> could be removed from the
| <p:pipeline> context: if you want to share parameter sets, you can
| always create a sequence of <c:parameter> documents to hold them.]

I think that would complicate the defaulting story. Instead of saying
that the default value for @use-parameter-sets is "#top-level" we
have to say ... something like:

  A step that does not contain a p:parameter-set is treated as if it
  contained a p:parameter-set that contained a pipe pointing to a step
  that copies the top level parameters. The copying step is also
  implied if it doesn't exist.

|>    If the same parameter is specified more than once inside a
|>    p:parameter-set, the last value specified is used.
|>
|>    Having sets isn't very useful if you can't use them, so we also
|>    need @use-parameter-sets on steps. (For steps not in the pipeline
|>    namespace, that's spelled @p:use-parameter-sets.)
|
| I have a strong preference for using a nested syntax rather than an
| attribute for constructing the parameter set from other parameter
| sets. In other words, rather than:
|
| <p:parameter-set name="setc" use-parameter-sets="seta">
|   <p:parameter name="aname" value="3"/>
| </p:parameter-set>
|
| use:
|
| <p:parameter-set name="setc">
|   <p:use-parameter-set name="seta" />
|   <p:parameter name="aname" value="3" />
| </p:parameter-set>
|
| and rather than:
|
| <p:xslt use-parameter-sets="seta setb">
|   ...
| <p:xslt>
|
| use:
|
| <p:xslt>
|   <p:use-parameter-set name="seta" />
|   <p:use-parameter-set name="setb" />
| </p:xslt>
|
| The reason is that elsewhere (namely in <p:input>) we use a nested
| syntax for constructing sequences of documents, and this seems to be a
| similar kind of thing. It also simplifies things when it comes to
| figuring out whether parameters in the content or from the used
| parameter sets get priority (see below).

I have a preference for attributes. It's not uncommon to use
attributes to point to stuff: attribute-sets, output parameters, and
character maps in XSLT, for example.

That said, you're right about the fact that we use nested elements
inside p:input.

I'll vote "concur" on this one if it helps get us finished.

|>    I propose that we address that by allowing "#top-level" as a
|>    parameter set name. It means "all the parameters passed to the
|>    p:pipeline", which might be the empty set.
|
| I don't much like '#top-level' as a name (sorry). What about
| '#pipeline-parameters'?

"Concur" :-)

I proposed #default and Henry didn't like it. I considered
"#pipeline-parameters" and rejected it mostly because it's about 10
letters longer, but that's not a good reason.

| In the nested syntax that I suggested above, you could manage this by
| altering the order in which the nested <p:parameter> or
| <p:use-parameter-set> elements were specified. For example, to get the
| same effect as above you could do:
|
| <p:parameter-set name="setc">
|   <p:parameter name="aname" value="3" />
|   <p:use-parameter-set name="seta" />
| </p:parameter-set>
|
| and:
|
| <p:parameter-set name="setd">
|   <p:use-parameter-set name="seta" />
|   <p:parameter name="aname" value="3" />
| </p:parameter-set>

Yes, I agree, if we nest them that's the right answer.

| The other thing from my proposal that I'd like to see here is to allow
| extension attributes on the <c:parameter> elements, which are simply
| ignored when a new parameter set is created. It just means that I can
| use documents to hold my parameter sets and not have to worry about
| stripping away any annotations I might place on them.

Yes, I didn't say it, but I intended that extension attributes would
be allowed.

|> Pipelines that need to perform more complex computations can do so:
|>
|>   <p:pipeline>
|>     <p:parameter-set name="global">
|>       <p:pipe port="result" step="load-global"/>
|>       <p:pipe port="result" step="some-top-level"/>
|>     </p:parameter-set>
|>
|>     <p:try name="load-global">
|>       <p:group>
|>         <p:output port="result"/>
|>         <p:load>
|>           <p:option name="href" value="~/.globals.xml"/>
|>         </p:load>
|>       </p:group>
|>       <p:catch>
|>         <p:output port="result"/>
|>         <p:identity>
|>           <p:input port="source">
|>             <p:inline>
|>               <c:parameters/>
|>             </p:inline>
|>           </p:input>
|>         </p:identity>
|>       </p:catch>
|>     </p:try>
|
| That should be:
|
|   <p:catch>
|     <p:output port="result" />
|     <p:identity>
|       <p:input port="source"><p:empty /></p:input>
|     </p:identity>
|   </p:catch>

Right. That was a holdover from when I was thinking of having
c:parameter*s* documents.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | One may be driven to commit murder by
http://nwalsh.com/            | love or hatred, but one can only
                              | advocate murder out of sheer
                              | wickedness.--Italo Svevo