# Narval Evolution Proposal 002

## Object

The aim of this document is to explain a proposal for easily retreives arguments in Narval actions, writen in Python.

## Advocacy

Today, arguments are passed to actions with a DOM tree, where each argument is encapsulated in a root node (<al:arguments>). The primary idea is that since we know the action's prototype, it's easy to provide to the action a dictionary which would reduce the action's programmer work. A little overview of existent modules tends to show that it's a signifiant part of the code, essentially when there are a lot of optional arguments.

Moreover, with the current model, we are doing the argument's selection twice, a first time in the prototype checking, a second in the action. This achieves to convince me that it's a good thing for Narval to change for a dictionary based solution.

The main default of this solution is to insert changes in the arguments selection for actions and transforms, which is at the moment identic.

Since this seem to be a good idea for inputs, it should be a good one to for outputs?

## Proposition

We should remplace the standard 'def narval_action_f(args)' where args is a dom tree with 'def narval_action_f(doc, args_dict)' where doc is an XML DOM document (factory) and args_dict a dictionary mapped to the action's arguments (see below). Another solution is 'def narval_action_f(args_dict, output)' with output an XML DOM node. This one has the advantage to avoid the output's node creation in the action (this argument is null if we decide to have a dictionary for ouput too).

An action with this prototype:

    <al:action name='read_new' func='read_new_f'>
    <al:input id='mail-box'><al:match>mailbox</al:match></al:input>
    <al:input id='force' optional='yes'><al:match>force</al:match></al:input>
    <al:output id='output' list='yes' optional='yes'><al:match>email</al:match></al:output>
    <al:output id='mail-box' outdates='mail-box'><al:match>mailbox</al:match></al:output>
    </al:action>

would receive the dictionary:

    {'mail-box': dom_node1,
     'force': dom_node2}

If an optional parameter is missing the key should be present but the value set to None. If we have an input with list='yes', we shoud have a list, even if we have 0 or 1 elements matching the input.

We coud easily imagine the same mechanism for the output. The dictionary for the last prototype would be:

    {'mail-box': dom_node1bis,
     'email': [dom_node3, dom_node_4],
     'error': []}

with prototype outputs and optional errors. In this model, the action and the Narval interpreter have to handle the namespaces of elements (two element with the same local name but different namespaces would appear in the same cell)