Re: No more parameter ports

  Hi,

  I mostly agree. But still I like to be able to pass parameters
around as a first-class object, where the set of parameters (including
their names and the number of them) is generated in a previous step,
and passed to a step that will actually use them in calling the step
consuming them.

  Another technique I use often is to read config parameters from a
file, and connect them straight as parameters.  This is very handy.
But to be honest that should probably require some more parsing and
validation of the parameters in the file anyway.

  Maybe there could be a parameter set concept that would be decoupled
from ports?

  Regards,

-- 
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/


On 8 October 2013 17:44, Norman Walsh wrote:
> Hi folks,
>
> I expect many of you have seen the requirements document (still an
> unofficial draft) that the XProc WG produced in Edinburgh:
>
>   http://www.w3.org/XML/XProc/docs/xproc-v2-req.html
>
> I want to draw particular attention to the "simplify parameters"
> requirement:
>
>   Experience with parameters in XProc 1.0 reveals that they are too
>   complicated. They often cause user confusion and introduce syntactic
>   complexity not justified by their function. XProc v2.0 must
>   dramatically simplify parameters, perhaps simply removing parameter
>   ports altogether without replacing them with a new mechanism of
>   equivalent power (and complexity).
>
> Not inventing a new mechanism would mean that p:with-param would still
> exist but parameter ports would not. Consider this pipeline:
>
>   <p:declare-step name="main">
>     <p:input port="source"/>
>     <p:output port="result"/>
>     <p:option name="page-size" select="'A4'"/>
>
>     <p:xslt>
>       <p:input port="stylesheet">
>         <p:document href="style.xsl"/>
>       </p:input>
>       <p:with-param name="page-size" select="$page-size"/>
>       <p:with-param name="style" select="'draft'"/>
>     </p:xslt>
>   </p:declare-step>
>
> Without parameter ports that would be valid (no more stupid warnings
> about unbound parameter input ports, thank you very much!)
>
> The pipeline caller could change the value of the 'page-size'
> parameter by passing in the page-size option to the pipeline. They
> could not change the value of the 'style' parameter or pass in any
> other parameters.
>
> On the one hand, this is a decrease in functionality. On the other,
> the complexity of parameters VASTLY outweighs the practical utility of
> that functionality (in the experience of the members of the WG present
> in Edinburgh).
>
> Your thoughts on this trade off would be most appreciated.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com

Received on Tuesday, 8 October 2013 16:03:52 UTC