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

Re: Parameters middle ground

From: Norman Walsh <ndw@nwalsh.com>
Date: Tue, 29 Oct 2013 23:07:52 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m28uxbh04n.fsf@nwalsh.com>
Alex Milowski <alex@milowski.com> writes:
> I don't like how this intrudes on the parameter names.  This means you
> couldn't ever have a parameter named 'step'.

Sure, but by the same token, you can never use the syntactic shortcut
for an option named "name". So the precedent is set.

> Couldn't we just add either:
>
>    * an option to every step with parameters called 'parameters' that
> takes a whitespace separated list of ancestor step names (same
> semantics as you propose)

Yes, we could.

>    * a p:use attribute that could be used on the p:parameters
> attribute to do the what 'step' does.

Sure, but then you couldn't use p:parameters to set a parameter named
p:use, so...

> I'd prefer a syntax outside of p:parameters as "inheriting" parameters
> is a more complex use case and so a more complex (but not onerously
> so) syntax is justified.
>
> Another option is:
>
>    <p:parameters param1="value1" param2="{$value2}">
>       <p:use step="main"/>
>       <p:use step="other"/>
>       ...
>    </p:parameters>
>
> which would have the effect of merging "main" and "other" and then
> overriding/setting param1/param2.

Yeah. But the body of p:parameters is presumably a binding for the
context item for expressions, so that's kind of complicated.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com

Received on Wednesday, 30 October 2013 04:08:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:52 UTC