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.
~`!@#$%^&*()=+{[]}:;'",.<>?/|\
XML structure of secondary articles
The XML structure of these declarations in procedure calls to MOBY Central are as follows:<Parameter articleName="NameOfArticle"> <datatype>Integer|Float|String|DateTime|Boolean</datatype> <description>...</description> <default>...</default> <!-- any/all of these --> <max>...</max> <!-- ... --> <min>...</min> <!-- ... --> <enum>...</enum> <!-- ... --> <enum>...</enum> <!-- ... --> </Parameter>
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.