High Level Requirement Specification

Default values for parameters.

Reference	Techreq.DefaultParameterValues
Referenced Use-cases	OnDex
Dependencies	ParamaterDescriptions
Champion	Tom Oinn
Status	ASSESSED by Stian

	Taverna 1.3	Taverna 2.0
Priority	3
Rough estimate	WEEK	WEEK

Overview

If services provide possible default values for the parameters in the service description, then Taverna should recognise this and provide the option of using them. For services that do not provide default values, then a possible approach is for the user to define some default values and for Taverna to remember these when that service is added to a model at a later date.

Overall Goals

The overall goal is to provide a solution that allows a mechanism for handling default values.

Assessment

Affected Components

Taverna workbench.

Key Tasks

• Identify if any services provide default values.
• If appropriate (as an outcome of above task) update Taverna to make use of provided default values.
• Discuss with users other mechanisms that may be helpful in handling default values.
• Implement outcomes of above if appropriate.

Appendix

• Find a way to specify in a Port object that the port is optional. Other metadata such as descriptions or default values could possibly also be made available. 2 days
• Make a GUI that is easy enough to understand that some port is optional. Use of color can help, for instance brighter colors on the text and on the graph view, but it should also be shown textually like (optional) or something. Remember that both inputs and outputs can be optional. Optional output usually means that the service might not give an output on that particular port, for instance an error port. 1 week
• Integrate with "Set default value" that's already in Taverna. This is like the client-side of default values, where the workflow designer adds a default value to a processor port so that people who reuse it don't have to add any String constants or similar unless they want to control the value. 1 day
• Work with service repository. A service could be described in the (we are dreaming here) Services Portal with example or default values for ports, and Taverna could fetch this. The repository should differentiate between examples and defaults, though. 1 month

(At least) these services have the concept of optional parameters:

WSDL complex types

Using the input and output splitters for complex types (ref. Stuart), many such web services can have optional inputs and outputs. For instance the NCBI services give output on different outputs depending on which inputs have been used.

WSDL Document based services say minOccurs="0" in the schema for optional stuff. 1 day

Soaplab

Some parameters are specified with mandatory: false (see "Show soaplab info" on processors). Examples are edit/noreturn, edit/seqret. 1 hour

Biomart

Yes, some parameters can be optional, but it also depends on the query made by the user. 1 day

BioMoby^?

Has some stuff called "Secondary inputs" which we are not currently using. Not quite sure what this is yet. Most services expect "OBJECT" and "input", there could be something here, investigate more. 1 day

Inferno

I'm not quite sure what the Inferno processors do, but they seem to have "optional output ports", with restrictions such that you can only fetch one or the other, but not both. 1 hour