Secondary Articles

Secondary articles are those that are required in addition to a Primary article(s) in order to modify the behaviour of the service, or are optionally, (and not necessarily predictably), passed back to the client to provide additional information about the service execution. There is currently only one form of Secondary article. The article may or may not be specifically configured by the client as Input, and may or may not be returned by the Service as output.
  • In the case of inputs, they are generally user-configurable immediately prior to service invocation.
  • During service invocation a client must send all secondary articles defined in the Service Instance, even if no value has been provided either as default, or Client-side.
  • Secondary articles that are considered "required" by the service should be registered with a default value.
  • the service may fail if an unacceptable value is passed for any secondary article.

Secondaries are required to be named using the articleName attribute. These are to assist the server-side parsers to identify particular inputs, e.g. if the service requires named inputs. The order of articles in a single Input or Output set must not be meaningful. This name may not contain spaces and or special characters, like:

XML structure of secondary articles

The XML structure of these declarations in procedure calls to MOBY Central are as follows:

  <Parameter articleName="NameOfArticle">
        <default>...</default> <!-- any/all of these -->
        <max>...</max>         <!-- ... -->
        <min>...</min>         <!-- ... -->
        <enum>...</enum>        <!-- ... -->
        <enum>...</enum>        <!-- ... -->

The components of the Parameter specification are:

  • datatype - one of Integer, Boolean, Float, String, DateTime, which specifies the type of data involved
  • description - a description of this parameter.
  • default - an optional default value, in case none is specified
  • max - if the values are not enumerated, the maximum value the parameter may have
  • min - if the values are not enumerated, the minimum value the parameter may have
  • enum - the allowed parameter values may be enumerated by including one enum element for each value.

DateTime secondaries use the W3C profile of the ISO-8601 specification for specifying dates and times.

Boolean secondaries use the XML schema definition for valid boolean values. Hence BioMOBY clients and services can send one of the following literals {true, false, 1, 0} and must understand all of {true, false, 1, 0}. Other commonly used boolean values like {T,F,TRUE,FALSE} etc. are not supported and illegal in BioMOBY lingua.