RE: Parameters

> -----Original Message-----
> From: Alex Milowski [mailto:alex@milowski.com]
> Sent: Wednesday, March 05, 2014 11:53 PM
> To: public-xml-processing-model-wg@w3.org
> Subject: Re: Parameters
> 
> On Wed, Mar 5, 2014 at 8:57 AM, Henry S. Thompson <ht@inf.ed.ac.uk>
> wrote:
> 
> > But, either I'm missing something, we've lost the un-named
> parameters?
> >
> > That is, from the command-line, I'm guessing you're assuming
> something
> > along the lines of Norm's example for specifying parameters in
> _named_
> > groups, but that's it.  Otherwise there's no way to know where to put
> > parameter bindings which come from the command line, is there?
> >
> > That means we have no way to reconstruct the current simple command
> > line for a pipeline with an xslt step, right?
> 
> Yes.

If by 'un-named' parameters Henry meant the V1 magic that auto-connects the parameter input port of a step to the parameter input port of the owner pipeline, then yes. But I still wonder how important that is.

> The use case that we discussed at some length at the meeting in
> Edinburgh was the "docbook stylesheet" example where you have this
> pipeline:
> 
> <p:pipeline>
>   <p:xinclude>
>   <p:xslt>
>     <p:input port="stylesheet"> ...</p:input>
>   </p:xslt>
> </p:pipeline>
> 
> and you want the parameters to be able to be controlled from the
> outside.  Having that as magic is compelling but is it enough to have
> this whole mechanism?  That's what we need to decide.
> 
> Here's the alternative via Vojtech's proposal:
> 
> <p:declare-step>
>   <p:input port="source"/>
>   <p:output port="result"/>
>   <p:option name="parameters" as="map:map(xs:QName, item()*)?"
> select="map{}"/>
> 
>   <p:xinclude/>
>   <p:xslt parameters="$parameters">
>     <p:input port="stylesheet"> ...</p:input>
>   </p:xslt>
> 
> </p:declare-step>
> 
> Differences?
> 
> 1. You probably can't use p:pipeline unless we say it always has a
> 'parameters' option now.

I may be wrong, but isn't it in our plans to drop p:pipeline in V2?

> 2. A user would need to know the name of the option used to pass
> parameters when they specify parameter values from the outside.

How would that be different from V1? If a user wants to pass parameters to a V1 pipeline, he needs to know the name(s) of its parameter input ports anyway. In the case of a simple pipeline with a single primary parameter input port, the implementation may provide some convenience so that the user does not have to specify the parameter port name, but that is purely impl-defined behavior. Nothing that comes from the specification.

If we drop parameters and only use options, the user of a hypothetical processor xyz might do something like this in the command-line:

xyz -i source=... pipeline.xpl username=john password=foo parameters=k1=v1,k2=v2,...

Compared to Calumet (or Calabash; I believe the syntax is more or less similar) and V1:

calumet -i source=... pipeline.xpl -p k1=v1 -p k2-v2 username=john password=foo
// or the long form
calumet -i source=... pipeline.xpl -p parameters@k1=v1 -p parameters@k2-v2 username=john password=foo

> If we added a 'parameters' option to p:pipeline, we'd be back to:
> 
> <p:pipeline>
>   <p:xinclude>
>   <p:xslt parameters="$parameters">
>     <p:input port="stylesheet"> ...</p:input>
>   </p:xslt>
> </p:pipeline>
> 
> I'm not sure how I feel about the above.

Do you mean: "All p:pipeline pipelines have an implicit primary input port named 'source', an implicit primary output port named 'result', and an implicit optional option of type map named 'parameters'."? If so, I am not sure about that either. But if the idea is to drop p:pipeline in V2, then we won't have that problem.

Regards,
Vojtech

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

Received on Thursday, 6 March 2014 08:48:01 UTC