RE: Annoyances with parameter input ports

> So we'd be trading one default behavior for another. Consider this
> pipeline:
> 
>   <p:pipeline name="main" ...>
>     <p:xslt>
>       <p:input port="stylesheet">
>         <p:document href="http://.../docbook.xsl"/>
>       </p:input>
>       <p:with-param name="root-dir" select="'./html'"/>
>     </p:xslt>
>   </p:pipeline>
> 
> At the moment, if I pass additional parameters on the command line,
> they all get passed to the XSLT step and they allow the caller to
> overide my default for the 'root-dir' parameter.
> 
> If I want to make my 'root-dir' parameter the only acceptable value,
> then I can do so explicitly:
> 
>   <p:pipeline name="main" ...>
>     <p:xslt>
>       <p:input port="stylesheet">
>         <p:document href="http://.../docbook.xsl"/>
>       </p:input>
>       <p:input port="parameters">
>         <p:pipe step="main" port="parameters"/>
>       <p:with-param name="root-dir" select="'./html'"/>
>     </p:xslt>
>   </p:pipeline>
> 
> And if I want to make my 'root-dir' parameter the *only* parameter, I
> can do that explicitly:
> 
>   <p:pipeline name="main" ...>
>     <p:xslt>
>       <p:input port="stylesheet">
>         <p:document href="http://.../docbook.xsl"/>
>       </p:input>
>       <p:input port="parameters">
>         <p:empty/>
>       <p:with-param name="root-dir" select="'./html'"/>
>     </p:xslt>
>   </p:pipeline>
> 

Yes.

> Under your proposal, if I understand it, my original pipeline:
> 
>   <p:pipeline name="main" ...>
>     <p:xslt>
>       <p:input port="stylesheet">
>         <p:document href="http://.../docbook.xsl"/>
>       </p:input>
>       <p:with-param name="root-dir" select="'./html'"/>
>     </p:xslt>
>   </p:pipeline>
> 
> would have the effect of making 'root-dir' the *only* parameter. But
> if I wanted to allow other parameters, I could do so explicitly, as
> above, and make the 'root-dir' parameter the fixed value or the
> default value.

Yes.

> 
> On the whole, I think the status quo behavior is more likely to be
> what users expect and want. But in either case, some semantics can
> only be achieved explicitly, and *all* semantics can be achieve
> explicitly, so I'm not (yet, at least) convinced that it's worth
> changing the status quo.
> 
> Getting parameters right was *a lot* of work and took *a long time*.
> I'm a little gun shy about touching them unless the benefits are
> overwhelming. But maybe that's just me.

I understand that, and I don't necessarily want to change the status
quo. I was just interested in what other people think about this. I
think it is more a question of which default behavior (my proposal vs.
what the spec says at the moment) is the least surprising for the user.
But perhaps it doesn't matter; users will be surprised anyway :)

Vojtech

Received on Friday, 21 November 2008 14:00:27 UTC