RE: Parameters

Hi all,

Continuing our discussion in the call, suppose we drop the notion of parameters altogether, and only rely on options that are maps. Since we are going to support AVTs, we can then do things like this:

<p:declare-step>
  <p:input port="source"/>
  <p:output port="source"/>
  <p:option name="xquery-params" as="map:map(xs:QName, item()*)?"/>
  <p:option name="xslt-params" as="map:map(xs:QName, item()*)?"/>

  <p:xquery parameters="$xquery-params">
    ...
  </p:xquery>

  <p:xslt parameters="$xslt-params">
    ...
  </p:xslt>
</p:declare-step>

It's not that different from V1 (but it still feels better & cleaner to me):

<p:declare-step name="main">
  <p:input port="source"/>
  <p:output port="source"/>
  <p:input port="xquery-parameters" kind="parameter"/>
  <p:input port="xslt-parameters" kind="parameter"/>

  <p:xquery>
    <p:input port="parameters">
      <p:pipe step="main" port="xquery-parameters"/>
    </p:input>
    ...
  </p:xquery>

  <p:xslt>
    <p:input port="parameters">
      <p:pipe step="main" port="xquery-parameters"/>
    </p:input>
    ...
  </p:xslt>
</p:declare-step>

Yes, the magic of "auto-connecting" the parameter ports would be gone, but is it really such an important feature? We are aready passing around options/variables among steps and nobody is complaining about that (except cases such as unspecified optional options; but that is a different story).

The advantage of representing parameters as map options is that we get rid of one extra concept (that nobody likes anyway), the language becomes more uniform, and the pipeline author still has complete control.

Regards,
Vojtech

--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.com
http://developer.emc.com/xmltech

> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com]
> Sent: Monday, February 24, 2014 10:58 PM
> To: public-xml-processing-model-wg@w3.org
> Subject: Re: Parameters
> 
> Alex Milowski <alex@milowski.com> writes:
> > On Fri, Feb 21, 2014 at 10:44 AM, Toman, Vojtech
> <vojtech.toman@emc.com> wrote:
> >
> >>
> >> I agree. But in cases when it is not a good thing, the pipeline
> >> author should be able explicitly override the default behavior.
> >>
> >
> > Yes, you're probably right.   I could see wanting to invoke a step
> and
> > say: "the default parameters are all empty" or set them to specific
> > sets of values.
> 
> On the p:xslt step, that's easy, just provide a value for the
> $parameters option.
> 
> If you're writing a third party pipeline and you want to provide that
> level of control, you can:
> 
>   <p:declare-step type="ex:bar">
>     ...
>     <p:option name="parameters" select="p:parameters()"/>
> 
>     ...
>     <p:xslt>
>       <p:with-option name="parameters" select="$parameters"/>
>     </p:xslt>
>   </p:declare-step>
> 
> Now the caller of ex:bar can set the parameters any way they want.
> If they do nothing, the default passthrough behavior occurs.
> 
> > We would need to add something to do this or possibly use p:group in
> > some way.
> 
> I'm not yet convinced. I don't mind making third party pipeline authors
> type a few extra lines if it saves ordinary users the burden of ever
> having to learn new syntax and hierarchical defaulting rules.
> 
>                                         Be seeing you,
>                                           norm
> 
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com

Received on Wednesday, 5 March 2014 16:19:35 UTC