this file captures some of the ideas used in the WSDL-like parameter definition files, but as yet is not used for validation the baseparameter definition is mimiced by the contents of a part element in the wsdl important types are defined here that would have special significance.... The list of possible parameter types that are passed in CEA messages. Note that the formal schema type of the message is always a string - The types below are to indicate how that string should be interpreted. Note that some of the "bulkier" types - e.g. VOTable would normally be passed "by reference" The enumeration values should have the namespace appended? I have removed them to make castor generate nicer objects Integer Real The string formats that can be recognised should be as defined by FORTRAN? Java? C? (all?) A complex number Any string of characters A representation of a boolean - e.g. true/false on/off Any Uniform Resource Indicator A value that is to be interpreted as a Right Ascension This should probably be deprecated in favour of the STC-S A value that is to be interpreted as a Declination This should probably be deprecated in favour of the STC-S the full XML version of the Astronomical Data Query Language The string representation of Astronomical Data Query Language A value that is specified using the Space Time Coordinate string definition A general piece of binary data with no special interpretation Data encoded in the Flexible Image Transport System http://fits.gsfc.nasa.gov/iaufwg/iaufwg.html should really reference the XHTML shema, but just did this for convienience what documentation can be The basic definition of what a parameter is - this is common to all of the CEA implementations. The name that is to be used to display this parameter in te UI A long description of the parameter that might be displayed in the UI to help the user If the parameter has a UCD then use the reference here - it could help in workflow typing... a possible default for this type of parameter - should probably be xs:any, but castor/axis do not deal with this well This would ideally be an enumeration of all the possible types of units? For parameters that can only have one of a list of values A particulat value in an option liest Defines what a parameter can contain when it is passed to be exevuted - this is in fact just a single value element at the moment, which is of string type This is unused in implementations at the moment - give the opportunity to specify some form of encoding for parameter values . This specifies whether the parameter value is indirect - i.e. if value of the parameter is some form of URI to the actual parameter value. If the value is indirect then the CEA implementation is expected to fetch the parameter before passing it on to the application. represents a call to a CEA application the list of parameters supplied as input the list of parameters expected as output ivoa resource identifier of the application to call which interface of the application to call