The types in this schema file are the basic CEA types that are used both in the registration of CEA resources and in the WSDL for the CEA interface defintion. The base application description The CEA type of the application - this allows the system to determine which CEC it should be talking to. The complete list of parameters that might occur in any of the apllication interfaces The list of interfaces that an application might have description of an interface parameters that are always passed to the application - these are not presented to the user, but the server side of the CEA will pick them up and send to the application. *EDitor note* perhaps this should be only an implementation detail. The list of input parameters for an interface The list of output parameters for an interface A description of the interface suitable for presentation in a UI the identifier for the interface A list of interface definitions A particular application interface reference to an application parameter. Used in the interface definitions. attributes for specifiying how often a parameter or parameter group should occur a value of 0 implies unbounded reference to an application parameter that is not repeatable or optional. Used in the interface definitions. allow mixed to put the possibility of value? or make this explicit... The type of the underlying application - commandline, http-get etc application is commandline, wrapped by a CEC application is a http POST/GET application is implemented "internally" in the CEA application is an external web service - will be dealt with by a proxy. The allowed structures for input parameters Allowed constructs for output parameters restricted to prefs at the moment - is there a case for pgroups... a reference to a parameter which has been defined in the Parameters section of the application description. This reference defines how many times the parameter can occur in the particular interface. The content of the element can define an interface dependent default for the parameter? this type is used to make a reference to a parameter - it uses a standard string type rather than an idref because the integrity of the references is checked using xs:unique constraints within VOCEA.xsd. this is the grouping of parameters that are required for a particular value of a head parameter the value that the control parameter has for this grouping name for the particular ConditionalPgroup option - can be used in user interface to label the parameter group. A grouping of parameters, where the actual parameters that must be given is specified by the value of a controlling parameter. the parameters that make up a standard reference to a parameter. reference to the parameter definition whose value determine which of the cgroups will be chosen a flag to allow a suggestion to the user interface that this parameter should normally be hidden from user view ed: note - what is the difference between saying parameter is hidden and specifying a constant in interface A list of parameter definitions Any constant values that should be assumed to be set for a particular interface by the CEA application - it should be an error if the CEA client tries to send a value for this parameter - the CEA server should assume the value. there needs to be at least one constant specified if this construct is used. A grouping of several parameters - this can be done for several reasons 1. provides a group that must be repeated 2. can be used as a visual hint to any applications that use the group. These are the elements that occur anywhere that there is a parameter reference possible in an interface. this is a name for the pgroup that can be used by UI software This really should be unified with the other parameter definitions..... The list of possible parameter types that are passed in CEA messages. Note that the formal schema type of the parameter value is always a string when passed to the web service - The types below are to indicate how that string should be interpreted. There is a mixture of classic atomic types as well as some aggregate types - this wide scope and slightly "fuzzy" definition of a parameter type is a deliberate design decision in CEA as it reflects the typical "objects" that are passed between astronomical applications As Data Models become established then references to these should also be made as top level aggregate types Note that some of the "bulkier" types - e.g. VOTable would normally be passed "by reference" Note that in a typical atomic parameter definition a UType would be specified so that a workflow builder might be able to automatically insert code to extract such a value from the bulk output of a previous step 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 Indentifier A VOTable in its entirety A value that is to be interpreted as a Right Ascension This is obviously a convienience simplification of part of STC A value that is to be interpreted as a Declination This is obviously a convienience simplification of part of STC Modified Julian date ISO Date representation 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 The data are encoded as generic XML. The schema for the xml is given in the UType?... should really reference the XHTML schema, but just did this for convienience a type that allows any style of documentation content. The basic definition of what a parameter is - this is common to all of the CEA implementations. possibility to specify a UType possibility to specify a mime type a possible default for this type of parameter this is repeateable for the case of array parameters. various ways of specifying the legal values that a parameter might have editor note - does this construct produce nice object models in code generators, or would it be better to have an abstract base type here.. For parameters that can only have one of a list of values captures the idea that a parameter can have a range of values the identifier for the parameter The data type of the parameter - note that this is not restricted to atomic data types. deffines the array shape of the parameter if it is an array Defines what a parameter can contain when it is passed to be executed -This can be a single value element, or a simple construction of an array - could perhaps allow a VOQuantity as well. The value of the parameter - formally has an xsd type of string, though the 'real' type is encoded in the parameter definition very simple model of a array - cannot be sparsely filled, The id is a reference to the id of the parameter as defined in the parameters section - used to be called "name" This is unused in implementations at the moment - give the opportunity to specify some form of encoding for parameter values. e.g. if passing a binary parameter by value. 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 server implementation is expected to fetch the parameter before passing it on to the application. The is most often called 'passing by reference' in computer languages. represents an invocation of a CEA application, with all the parameter values defined. 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 taken from the votable definition - the first index varies most rapidy, and the last index may be specified as '*' to mean unbounded. this different type of supported ranges the allowable binary encodings for a parameter value. The parameter value formally has an xsd type of string, but the use of encodings would allow a pure binary object, e.g. a jpeg file to be included as a direct parameter value. simple array model - assumed to be fully filled in a row-major fashion editor note - should this be here to allow overriding of the parameter defintion. A way of specifying that a parameter value should be taken from a list of possible values. a possible value for a value that forms part of a list of values that a parameter could take. the value of a range bound used to specify that a parameter value should lie in a particular range. the maximum value in the range. the maximum value in the range. A list of parameter values some form of reference to a parameter that would appear in an interface definition. This can either be a direct reference, a reference to a repeating group of parameters or a reference to a conditional group of parameters. editor note - not too sure what the best multiplicities are here - this would typically be used in a case a reference to a parameter which has been defined in the Parameters section of the application description. This reference defines how many times the parameter can occur in the particular interface. The content of the element can define an interface dependent default for the parameter? a simple grouping of parameters. The parameters could be grouped because they should be repeated as a group or perhaps because they should appear together on a single pane of the user interface. this represents a point in the parameter tree where there could be a series of different sequences of parameters based on the value of the parameter referred to by this top level.