Re: "Fixing parameters"

On Fri, Sep 14, 2012 at 11:30 AM, Toman, Vojtech <vojtech.toman@emc.com> wrote:
> Hi Norm,
>
> It looks simple and interesting. Some immediate questions:

I would go further and state that Norm's approach also has an aspect
of elegance to it.

I agree with Vojetch, that maybe we could go further and just add map
as a type to options and eschew with any special handling of
parameters ?

> 4. A common use case is to have steps that produce parameters as a c:param-set/c:param documents. If we decided to drop p:with-param, how would you - without forcing the users to go to the bottom of the XProc hell and back - feed that output into some other step's parameters?
>

IMO, ppl using parameters are now in a kind of XProc hell  … have we
stated backwards compat as a *must* for vnext ?

my feeling is that we could consider some breaking changes if the
benefit outweighs current status quo.

J

>
> 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: Thursday, September 13, 2012 4:54 PM
>> To: public-xml-processing-model-wg@w3.org
>> Subject: "Fixing parameters"
>>
>> Hi folks,
>>
>> Here's a proposal for "fixing parameters".
>>
>> 1. Adopt the XSLT 3.0 extensions to the data model and functions and
>>    operators to support maps
>>
>> 2. Instead of specifying input ports, steps declare that they accept
>>    parameters in a manner analogous to options:
>>
>>    <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:parameters name="parameters"/> <!-- *** -->
>>    </p:declare-step>
>>
>> 3. Steps accept parameters just like options:
>>
>>    <p:xslt parameters="{$parameters}"> ...
>>
>>    or
>>
>>    <p:xslt parameters="{map:put(map:new(), 'output-format', 'xhtml')}">
>> ...
>>
>>    I think maps basically have to be in variables, so we don't need
>>    to support a <p:with-parameters> instruction.
>>
>> 4. If a step has no bindings for any of its parameters, and its
>> enclosing
>>    pipeline has a parameters with the same name, then those parameters
>>    are passed in automatically. You can explicitly disable this with
>>    parameters="{()}".
>>
>>    We could simplify our lives a lot by removing this magic copying,
>>    but I think we probably still need it.
>>
>>    It is not an error if the enclosing pipeline has no parameters with
>>    the same name, the set of input parameters is simply an empty map.
>>
>> 6. The XML serialization of parameters is still useful, so we keep
>> that.
>>
>> 7. We probably need a new function that takes an XML serialization of
>>    parameters and returns 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 Friday, 14 September 2012 10:05:40 UTC