RE: Revisiting "fixing parameters"

Hi all,

Nice proposal. Regarding 4, does inheritance work regardless of the parameters name? In other words, if I have:

<p:declare-step>
  <p:option name="par" parameters="true"/>

  <p:declare-step type="ex:step">
    <p:option name="foo" parameters="true"/>
    ...
  </p:declare-step>

  <ex:step/>
</p:declare-step>

will "foo" inherit the bindings of "par" from the enclosing pipeline?

---

Regarding 5 and pipelines with anonymous parameters, how would you pass parameters to such a pipeline? If you cannot, why bother with creating an empty anonymous parameters option and inheriting from it?

---

But I am actually wondering if the distinction that something is a parameter is really that important. Perhaps we could get rid of the notion of parameters altogether and introduce instead some convenience rules for inheriting options/variables that would:

- allow for more or less the same "magic" that we expect with today's parameters
- reduce the amount of <p:with-option name="filter" select="$filter"/>
- and, related to the previous point, maybe get rid of some the problems with unbound options etc.

The following might be too radical/simplistic/problematic, but what about simply introducing an "inherit" attribute on the p:option/p:variable element? If the processor encounters an unbound option/variable while evaluating the pipeline, it would search for the nearest in-scope option/variable with the same name that was declared as inherit="true".

The main change for parameters would be that you would have to be careful about how you name the options (the names have to match), but suppose p:pipeline is equivalent to the following:

<p:declare-step>
  <p:input port="source">
  <p:output port="result"/>
  <p:option name="parameters" inherit="true"/>
  ...
</p:declare-step>

then you will still be able to do things like:

<p:pipeline> 
  <p:xslt/>
</p:pipeline>

and be sure that the parameters passed to the pipeline will get passed to the p:xslt step.

It obviously has a whole number of implications (maybe it introduces even more magic than we have now) and I haven't put much thought to it, but my ideal still remains that there are no parameters and special parameter-related rules in XProc.

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: Wednesday, December 05, 2012 1:38 AM
> To: public-xml-processing-model-wg@w3.org
> Subject: Revisiting "fixing parameters"
> 
> Hi folks,
> 
> Here's my synthesis of the discussions at the face-to-face:
> 
> 1. Adopt the XSLT 3.0 extensions to the data model and functions and
>    operators to support maps
> 
> 2. Parameters become a special kind of option:
> 
>    <p:declare-step type="p:xslt" xml:id="xslt">
>       <p:input port="source" sequence="true" primary="true"/>
>       <p:input port="stylesheet"/>
>       <p:output port="result" primary="true"/>
>       <p:output port="secondary" sequence="true"/>
>       <p:option name="initial-mode"/>
>       <p:option name="template-name"/>
>       <p:option name="output-base-uri"/>
>       <p:option name="version"/>
>       <p:option name="parameters" parameters="true"/>
>    </p:declare-step>
> 
>    The special flag is necessary because of the special "inheritance"
>    rules for parameters.
> 
> 3. Steps accept parameters just like options:
> 
>    <p:xslt parameters="{$parameters}"> ...
> 
>    or
> 
>    <p:xslt>
>      ...
>      <p:with-param name="parameters" select="map{'output-format' :=
> 'xhtml'}"/>
>    </p:xslt>
> 
> 4. If a step has no bindings for any of its parameters options, then
>    the bindings of the nearest enclosing pipeline are inherited.
> 
> 5. All pipelines have at least one parameters option. If a p:declare-
> step
>    does not specify any parameter options, then the pipeline has an
>    anonymous parameters option that can only be accessed via the
>    inheritance mechanism.
> 
> 6. If a pipeline declares more than one parameters option, then it is
>    en error to rely on the inheritance; each contained step must
> specify
>    a binding for each of its parameter options.
> 
> 7. Inheritance can be explicitly blocked by specifying the empty
>    sequence as the value of the parameters option.
> 
> 8. The XML serialization of parameters is still useful, so we keep
> that.
> 
> 9. If a map-type option is passed an XML document that is a c:param-
> set, then
>    it's automatically converted to a map.
> 
> Maps have to be immutable, so we'll need to work through some of the
> details with care.
> 
>                                         Be seeing you,
>                                           norm
> 
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com

Received on Wednesday, 5 December 2012 09:47:04 UTC