W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > September 2012

Re: No more automagic inheritance

From: Murray Maloney <murray@muzmo.com>
Date: Fri, 14 Sep 2012 13:55:55 -0700
Message-Id: <D7A7A28F-8AE3-46FC-B24B-834BE816364E@muzmo.com>
Cc: "public-xml-processing-model-wg@w3.org" <public-xml-processing-model-wg@w3.org>
To: Norman Walsh <ndw@nwalsh.com>
On 2012-09-14, at 11:30 AM, Norman Walsh <ndw@nwalsh.com> wrote:

> I wonder if automagic inheritance of parameters is really too
> expensive (in terms of language complexity) to justify.
> 
> If someone gives you this shell script:
> 
>  #!/bin/bash
>  ls
> 
> You can't pass parameters to 'ls' when you run it. You have to modify
> the script:
> 
>  #!/bin/bash
>  ls "$@"
> 
> Perhaps if someone gives you this pipeline
> 
>  <p:pipeline>
>    <p:xslt/>
>  </p:pipeline>
> 
> we should just accept that you can't pass parameters to the p:xslt step
> unless you modify the pipeline:
> 
>  <p:pipeline>
>    <p:xslt parameters="{$parameters}"/>
>  </p:pipeline>
> 
> I don't know.

That seems right to me. That is, it matches my intuition. 


> Alternatively, I guess we could say that the set of parameters
> passed to a step that has an undeclared parameters binding is implementation defined.
> 
> The implementors could invent mechanisms for passing them in.
> 
>  calabash ... -p p:xslt/$initial-mode=fred
> 
> I don't know.

So, does this -p expression say "whenever p:XSLT is run, set its initial-mode parameter to the string 'fred'?" 

It seems a bit obfuscatory. If the called step is modified later, adding another call to p:xslt that doesn't need or want the 'fred' parameter, then what? The step author has to plan for parameters that might be passed to it through Calabash. Does the step author have a way to allow/forbid extra params?

> 
>                                        Be seeing you,
>                                          norm
> 
> -- 
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com
Received on Friday, 14 September 2012 20:56:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 September 2012 20:56:27 GMT