IVOA

CEA Implementation: The Common Execution Architecture as a UWS Implementation
Version 1.0

IVOA Working Draft 3 May, 2011

This version:
http://www.ivoa.net/Documents/WD/GWS/CEAApplicationDM-XXXX.html
Latest version:
http://www.ivoa.net/Documents/latest/CEAApplicationDM.html
Previous versions
Authors:
Paul Harrison.

Abstract

This document describes the AstroGrid Common Execution Architecture (CEA) implementation. CEA is a generalised service that implements UWS as a generic parameterized application. The data model for the generic application is presented as well as the XML encoding of this model. The relationship with UWS is explored, and a schema is introduced which can be used to describe the application in an IVOA interoperable registry.

Status of this document

This is an IVOA Working Draft for review by IVOA members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use IVOA Working Drafts as reference materials or to cite them as other than "work in progress."

Parts that the editor considers should be removed from the document are marked in red with a strike through line, and parts to be expanded are in green

Comments on this document are due 15 December 2006 for consideration in the next version of this document. They should be sent to registry@ivoa.net, a mailing list with a public archive or on the VOApplication twiki discussion page. General discussion of related technology is also welcome on the Rwp03 wiki site.

A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.

Acknowledgements

This document has been developed with support from the UK Particle Physics and Astronomy Research Council (PPARC), and from the Eurpean Commission's Sixth Framework Program via the VOTech project.

Conformance-related definitions

The words "MUST", "SHALL", "SHOULD", "MAY", "RECOMMENDED", and "OPTIONAL" (in upper or lower case) used in this document are to be interpreted as described in IETF standard, RFC 2119 [RFC 2119].

The Virtual Observatory (VO) is general term for a collection of federated resources that can be used to conduct astronomical research, education, and outreach. The International Virtual Observatory Alliance (IVOA) is a global collaboration of separately funded projects to develop standards and infrastructure that enable VO applications.

Syntax Notation Using XML Schema

The eXtensible Markup Language, or XML, is document syntax for marking textual information with named tags and is defined by the World Wide Web Consortium (W3C) Recommendation, XML 1.0 [XML]. The set of XML tag names and the syntax rules for their use is referred to as the document schema. One way to formally define a schema for XML documents is using the W3C standard known as XML Schema [Schema].

This document defines the VOCEA and CEABase schema using XML Schema. The full Schema documents are listed in Appendix A and Appendix B. Parts of the schema appear within the main sections of this document; however, documentation nodes have been left out for the sake of brevity.

Reference to specific elements and types defined in the VOCEA schema include the namespaces prefix, cea, as in cea:CeaApplication (a type defined in the VOCEA schema). Use of the specific cea prefix in compliant instance documents is not required (the actual namespace "http://www.ivoa.net/xml/CEA/v1.0" could be assigned to any prefix); its use in this document is simply to indicate that it is an entity defined in the VOCEA schema. The prefixes for other namespaces are given within the folllowing table

Namespace prefixes used in this document
prefix namespace
cea http://www.ivoa.net/xml/CEA/v1.0
ceab http://www.ivoa.net/xml/CEA/base/v1.0
vr http://www.ivoa.net/xml/VOResource/v1.0
vs http://www.ivoa.net/xml/VODataService/v1.0
va http://www.ivoa.net/xml/VOApplication/v1.0

Note that as this document represents a draft the cea: and ceab: namespaces in attached schema and instance documents have the string "rc<n>" appended where "rc" stands for release candidate and <n> is an integer representing the iteration number of the release candidate draft of the associated namespace.

Contents

1. Introduction

The concept of an abstraction of implementation specific details from the creation of an astronomy specific computing grid was introduced in the IVOA Note "A Proposal for a Common Execution Architecture" [CEA] which described the motivation for and benefits of such an abstraction as well as the concrete schema and web interface definitions that were used by the Astrogrid [AG] implementation of the system at the time. The description of CEA is now split into two parts

  1. The data model for an application, as defined in this document. This model is a general description of what parameters a particular application can accept, and as such it may be regarded as a "language" that is implementation independent to describe at the user-level how the application should be called.
  2. A specific web interface (defined in the [CEAIMP] document) for remote invocation of applications that conform to the CEA. The web interface can take a tool XML instance document describing the desired application invocation and actually run the application and return the results in an asynchronous, secure fashion that is consistent with the Universal Worker Pattern ([UWS])

This split between the application model and interface emphasises the fact that the application model could be re-used in other circumstances.

The schema that are presented in this document represent an evolution of those presented in [CEA] that incorporates both

2. Design

As presented in [CEA] the basic model for an application is simply a process that can expose a number of "interfaces" which each may have a number of input and output parameters. This means that the UML domain model for the application description is relatively simple as displayed below;

CEA Application domain model

It is important to realise that the parameter definitions can be reused in multiple interfaces (indicated by the fact that the interfaces are aggregations of parameters) and that the final xml schema representation reflects this by defining all of the parameters for an application first, and then defining the interfaces which contain references to the original parameter definitions.

2.1. The main design aims are;

  • produce a description of an application to allow it to be successfully invoked with the correct parameters, with a degree of validation of the parameters possible before sending to the application.
  • be able to use the description to build a dynamic user interface for specifying the parameters for an application.

In addition the model also needs to be able to specify

  • parameter types
  • logical groupings of parameters
    • indicate parameters that have to be given together for semantic reasons
    • indicate parameters that should appear "together" in a user interface.

2.2. More detail

This diagram does not show the full model that is expressed in the schema, however, a more detailed UML diagram to represent the all of types used in the Application Data model is in Appendix D. The additional complexity that is present in this diagram results from

  • The ability to specify detail about each parameter definition e.g. default values, ranges etc..
  • The ability to group and conditionally repeat parameters in an interface.

2.3. Detailed Description of the CEABase Schema

The two major types within the schema are

  1. ApplicationDefinition - This is the description of an application
  2. Tool - This represents an invocation of an application.

ApplicationDefinition

The main type that is used to describe an application is the cea:CeaApplication which is derived from va:Application, which in turn is derived from vr:Resource. This means that the start of a such a description would be as below, where the elements possible in the region marked "..." are described in [VR] and [VA] - the CEA specific part starts with the <applicationDefinition> element.

Start of the CeaApplication definition
   <Resource xsi:type="cea:CeaApplication"
      created="2005-09-09T12:28:16" updated="2005-09-09T12:28:16" status="active">
      <title>SExtractor</title>
      <shortName>SExtractor</shortName>
      <identifier>ivo://org.astrogrid/SExtractor</identifier>
...
      
      <applicationDefinition>

ApplicationType

2.3.1. Parameters

The first elemtent of the <applicationDefinition> is the <parameters> element. Parameters are defined once per application, and each parameter is defined with a <parameterDefinition> element which is of type ceab:BaseParameterDefinition, which in turn is derived from vs:BaseParam. This means that the possible attributes and sub-elements of the <parameterDefinition> are listed below.

id attribute

This is the identifier for the parameter - the references to parameters in the interfaces use this value as the parameter identifier.

type attribute

The type of a parameter is CEA is a rather broad concept, with the type ranging from standard atomic types, to aggregate 'types'. The choices were made based on an empirical survey of the most common kinds of parameter that occured in the original target application for CEA namely typical astronomical legacy command-line application. In this sense the types are not intended to be "complete", but to represent a useful subset of all possible types.

It should be noted that the formal type of the parameter value that is passed in the Common Exectution Connector [CEAINT] interface is always an xsd:string - any interpretation of this type information is done at the client or the server, but not by the transport protocol.

The choice of what type to declare a parameter is largely a matter of the how much processing or validation of the parameter that the application designer wants the CEA infrastructure to perform - it would be possible to delare just about any parameter as text of binary for instance, which would imply no validation or processing of the value by the CEA client or server.

The server side representation of the parameter is determined from the form of the defaultValue element. A concrete example of this is that a boolean value may be represented in many ways on the client as in the table below, but it might be that on the server side that only true/false can be understood, so the defaultValue would be declared 'true'. The server side treatment of parameters is largely implementation dependent, however, the treatment described in this paragraph is that performed by the 'Commandline Common Excecution Controller' [CEAIMP] and as such possibly should be addressed by a separate implementation defined attribute.

type Description String representation
integer an integer value  

real

 a real value (any precision)  
complex a complex number pair  
text any data that could be interpreted as human readable text in a well known encoding.  
boolean a boolean value 0/1 true/false yes/no on /off
anyURI a string that could be interpreted as a URI.  
VOTable a VOTable conforming to the IVOA specification  
angle Angular measure on the sky sexagesimal allowed
MJD Modified julian data  
DateTime A date and time in ISO 8601 format  
ADQL Astronomical Query Language  
binary arbitrary  
FITS a file conforming to the [FITS] standard  
xml arbitrary xml

the schema for the xml is optionally indicated in the UType of the parameter

 

table some tablular data  
image an astronomical image  
spectrum a spectrum  

Future versions of the allowed enumerations for values of this attribute will be influenced by the work of other IVOA standards working groups, particularly in the areas of Semantics, Theory and Applications.

array attribute

If present this attribute specifies that the parameter is an array, and it also defines the shape and size of the array. This definition is essentially the same as for the arraySize attribute in VOTable [VOTABLE], where the first specified dimension changes fastest, and the final dimension can be specified as an asterisk which means unbounded, or an integer followed by an asterisk which means guarenteed to be less than or equal to the attribute.

example of the array attribute
array="64*10*x"

Note that strings (the text type above) do not follow the same conventions as VOTable in that they are not considered as arrays of characters.

name element

This is used to present a name of the parameter in a user interface - This is included because the id attribute of the parameter will often be tied to the name that the underlying application uses, and that name might not be very "human-readable".

description element

This can be used to present a human-readable description of the purpose and meaning of the parameter.

unit element

The physical unit of the parameter. The actual strings used to denote units follow the same conventions as for the unit attribute of [VOTABLE].

ucd element

A UCD for the parameter if appropriate.

UType element

The UType of the parameter if appropriate.

mimeType element

The mimeType of the parameter if appropriate.

defaultValue element

A default value for the parameter - note that this is simply for presentation to the user interface - in a tool element the value for the parameter should be explicitly given - it is not part of CEA that the parameter description will be reparsed to obtain a default value for a missing parameter.

optionList element

This can be used to specify that a parameter can have only an enumerated list of values. The client is expected to enforce this requirement.

example of the optionList
<optionList>
<optionVal>NONE</optionVal>
<optionVal>BLANK</optionVal>
<optionVal>CORRECT</optionVal>
</optionList>

 

range element

This element can be used to specify the range of values that a parameter may have

2.3.2. Interfaces

An application needs at least one interface to be callable. Interfaces are identified by their "id" attribute. The 4 possible sub-elements of the <interface> element are

The exact order and grouping of parameters within the input and output sections is made using the pref, pgroup and cgroupHead elements which are described in more detail below

pref

This element is the principal method of making a reference to a parameter definition, and the use is illustrated below.

A pref element referring to the corresponding parameterDefinition
      ...
            <parameterDefinition id="PHOT_APERTURES"
               type="integer">
               <name>Photometry apertures</name>
               <description>
                  MAG_APER aperture diameter(s) in pixels
               </description>
               <ucd />
               <defaultValue>5</defaultValue>
            </parameterDefinition>
         </parameters>
         <interfaces>
            <interfaceDefinition id="qa">
               <input>
                  <pref maxOccurs="1" minOccurs="1"
                     ref="PHOT_APERTURES" />
      ...

 

The ref attribute of the pref element must have a value that corresponds to the id attribute of a <parameterDefinition> to make a valid reference to a parameter in an interface, as illustrated by the blue text in the example above. In addition the <pref> element can have the following attribute

minOccurs
The minimum number of times that the parameter should occur in the interface. The default value is 1.
maxOccurs
The maximum number of times that the parameter should occur in the interace. A value of 0 is interpreted as the parameter being allowed to be repeated an unbounded number of times. The default value is 1.
hidden
If true this is a hint to a client side GUI builder that this parameter should be hidden

pgroup

A <pgroup> element can be used to group parameters in the interface. This grouping can be done for two primary reasons.

  1. To specify that a set of parameters should be repeated as a group
  2. To give hints to the client side GUI builder that the parameters should be presented to the used in a grouped fashion.

The example below shows that the 'targets' and 'matches' parameters should be repeated as a pairs (if at all, as minOccurs takes the default value of 1).

The use of pgroup to group parameter references, so that they need to be repeated in pairs. 
               <input>
                  <pgroup maxOccurs="2">
                     <pref ref="targets" />
                     <pref ref="matches" />
                  </pgroup>
                  <pgroup>
                     <pref ref="matchRadius" />
                     <pref ref="radMax" />
                  </pgroup>

 

cgroupHead & cgroup

These constructs allow a set of alternative groups of parameters to be required dependent on the value of another parameter. In the example below different parameters need to be specified depending on the value of the 'output' parameter - if it takes on the value of "html" then a parameter called "htmlversion" will be required, and if it has the value "VOTABLE" a parameter 'votableserialization' will be required.

The use of a conditional group. 
                  <cgroupHead ref="output" >
                     <cgroup name="html options">
                        <value>html</value>
                        <pref ref="htmlversion" />
                     </cgroup>
                     <cgroup name="votable options">
                        <value>VOTABLE</value>
                        <pref ref="votableserialization" />
                     </cgroup>
                  </cgroupHead>

 

As well as giving instruction to a client side GUI building tool, the cgroupHead and cgroup constructs should also be used by the server side CEA component to do basic validity checking on the parameters that it actually receives.

2.4. Tool

The ceab:Tool type represents an invocation of the application, i.e. it specifies which interface to use and supplies values for all of the necessary parameters. This is principally of interest of course when calling an application via the CEA interfaces and is discussed more fully in [CEAINT]. An important feature of CEA is that the parameter values that are passed to the server side CEA component are fully specified by this <tool> element, and the description of the application specified by ApplicationDefinition is used by the server side CEA component merely for validation purposes - no parameter value would be changed by the server side CEA component. The application that is to be run is identified by the id attribute and the particular interface by the interface attribute of the tool element.

pval

The <pval> element is the principal element that carries parameter values, which are always passed within a <value> element, whether directly or within an <array>. The schema type of the value element is always xs:string.

A complete tool invocation
<tool xsi:type="ceab:Tool" xmlns:ceab="http://www.ivoa.net/xml/CEA/base/v1.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.ivoa.net/xml/CEA/base/v1.0 ../v11/CEABase.xsd"
   id="ivo://dummy" interface="test">
   <input>
      <pval id="p1">
         <array>
            <value>1</value>
            <value>2</value>
         </array>
      </pval>
      <pval id="p2">
         <value>hello</value>
      </pval>
   </input>
   <output>
      <pval id="out" indirect="true">
         <value>vos://org.test!vospace/mydata</value>
      </pval>
   </output>
</tool>

 

Note on ordering of parameter values.

2.5. Generating User Interfaces

Names and descriptions

Default Values

Default values where specified for parameter values are intended for client side GUI builders only, and are not substituted by the server side components for missing parameters.

Validity Checking

The client should attempt to perform validity checking on parameters wherever possible, however this is not manadatory as the server must perform validity checking of parameters and will reject requests to run applications with invalid parameter value specifications.

Repeatable parameters

Where a parameter is repeatable (or deletable) the GUI should attempt to inform the user of such a possibility to the user either by using some direct visual form such as an icon next to the parameter input widget, or by enabling or disabling a "repeat parameter" functionality in another GUI element such as a toolbar or pop-up menu when the parameter is selected.

Parameter Groups

One of the intentions of parameter groups is to provide formatting hints to a client producing an automatic user interface. The client should attempt to show this grouping by means of devices such as "tab panes".

needs diagram illustrating typical GUI widgets

2.6. Registering CEA Applications and CEA Services

To register CEA Applications and services, types from the VOCEA.xsd schema need to be used. The relationships between the types defined by that schema are illustrated below. The main type that is used to register the description of an application is a CeaApplication, which contains standard Resource metadata, as well as an <applicationDefinition > element which contains the actual CEA application description as detailed in the desciption of the CEABase schema above. A service that can run one or more of CEA Applications is registered with a Service type that has a <capability> element of type CeaCapability. The CeaCapability lists references to the ivoa identifiers of the CeaApplications that particular service can offer, as well as detailing which particular CEA interface can be used.

The preceding paragraph describes all of the structures necessary to register CEA applications and services, however there is one convenience type CeaApplicationExtension that can be useful in describing a family of similar applications. The CeaApplicationExtension defines a limited form of application description subclassing, in that it is assumed to inherit all of the parameter and interface definitions of the parent CeaApplication (the one referred to by the extends attribute). It is then allowed to define additional parameters and interfaces, but it should be considered an error if the CeaApplicationExtension tries to redefine an existing parameter.

Class diagram of CEA Registry Types

There is a fully annotated example of the registration entries for a CEA application and server in appendix C

3. Recommendations for Application Description Authors

4. Validation

5. Optional Parameters or different interfaces?

6. Comparision with other "Parameter Models"

There have been a number of other parameter systems implemented in astronomical software systems and it is worthwhile to see the ways in which CEA is different and also the features that CEA has copied to obtain a deeper understanding of the best ways to use the CEA Model.

AIPS

IRAF ICL

Starlink ADAM

  • CEA does not attempt to define any sort of parameter storage mechanism for presenting the "current" values of parameters in the user interface.
  • The formal (XML) type of the parameter values that is passed is always of type string

 

7. Summary of updates since [CEA]

The following represent updates to the CEA Application model since the publication of the original IVOA Note [CEA].

Appendix A. The complete CEABase Schema

Note that this schema can be found on-line at http://www.ivoa.net/xml/CEABase/v1.0 (i.e. the target namespace can also be used as a URL for the schema.) This location should represent the definitive source, the schema is only copied below for completeness of this document.

<!-- $Id: CEABase.xsd,v 1.4.2.2 2011/04/14 12:10:29 pah Exp $ -->
<!-- This schema represents the first ivoa level release of the CEA defintion schema that was previously internal to Astrogrid. This is refactored from the AGParameterDefinition.xsd and CEABase.xsd schema files, to conform to the Registry v1.0 standards and styles. In addition there are extensions to the original Astrogrid schema * array valued parameters are introduced * parameter groups are possible in an interface definition * conditional parameter groups * parameter ranges Paul Harrison (ESO) - May 2007 -->
< xs:schema targetNamespace = "http://www.ivoa.net/xml/CEA/base/v1.1" elementFormDefault = "unqualified" attributeFormDefault = "unqualified" version = "1.0 RC$Revision: 1.4.2.2 $" xmlns:xml = "http://www.w3.org/XML/1998/namespace" xmlns:ceab = "http://www.ivoa.net/xml/CEA/base/v1.1" xmlns:xs = "http://www.w3.org/2001/XMLSchema" xmlns:vs = "http://www.ivoa.net/xml/VODataService/v1.1" >
< xs:import namespace = "http://www.ivoa.net/xml/VODataService/v1.1" schemaLocation = "../../../vo-resource-types/VODataService/v1.1/VODataService.xsd" />
< xs:annotation >
< xs:documentation > A group where only one of the members is active at any one time - equivalent to the same construct in HTML </ xs:documentation >
</ xs:annotation >
< xs:complexType name = "ApplicationBase" abstract = "false" mixed = "false" >
< xs:annotation >
< xs:documentation > The base application description </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "applicationType" type = "ceab:ApplicationKind" minOccurs = "1" maxOccurs = "unbounded" >
< xs:annotation >
< xs:documentation > The CEA type of the application - this allows the system to determine which CEC it should be talking to. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "parameters" type = "ceab:ParameterDefinitionList" >
< xs:annotation >
< xs:documentation > The complete list of parameters that might occur in any of the apllication interfaces </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "interfaces" type = "ceab:InterfaceDefinitionList" >
< xs:annotation >
< xs:documentation > The list of interfaces that an application might have </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
</ xs:complexType >
<!-- perhpas add a name to interfaceDefinition as well - the ID might be not very human readable. -->
< xs:complexType name = "InterfaceDefinition" mixed = "false" >
< xs:annotation >
< xs:documentation > description of an interface </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "constants" type = "ceab:InterfaceConstants" minOccurs = "0" >
< xs:annotation >
< xs:documentation > 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. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "input" type = "ceab:InputParameterReferenceSpecification" >
< xs:annotation >
< xs:documentation > The list of input parameters for an interface </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "output" type = "ceab:OutputParameterReferenceSpecification" >
< xs:annotation >
< xs:documentation > The list of output parameters for an interface </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "description" type = "xs:string" minOccurs = "0" >
< xs:annotation >
< xs:documentation > A description of the interface suitable for presentation in a UI </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
< xs:attribute name = "id" type = "xs:string" use = "required" >
< xs:annotation >
< xs:documentation > the identifier for the interface </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "name" type = "xs:string" use = "optional" >
< xs:annotation >
< xs:documentation > a name for the interface to displace in UI </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:complexType >
< xs:complexType name = "InterfaceDefinitionList" >
< xs:annotation >
< xs:documentation > A list of interface definitions </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "interfaceDefinition" type = "ceab:InterfaceDefinition" maxOccurs = "unbounded" >
< xs:annotation >
< xs:documentation > A particular application interface </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
</ xs:complexType >
< xs:complexType name = "ParameterRef" mixed = "false" >
< xs:annotation >
< xs:documentation > reference to an application parameter. Used in the interface definitions. </ xs:documentation >
</ xs:annotation >
< xs:attributeGroup ref = "ceab:ParameterReferenceAttributes" />
< xs:attributeGroup ref = "ceab:cardinality" />
</ xs:complexType >
< xs:attributeGroup name = "cardinality" >
< xs:annotation >
< xs:documentation > attributes for specifiying how often a parameter or parameter group should occur </ xs:documentation >
</ xs:annotation >
< xs:attribute name = "minOccurs" type = "xs:int" use = "optional" default = "1" />
< xs:attribute name = "maxOccurs" type = "xs:int" use = "optional" default = "1" >
< xs:annotation >
< xs:documentation > a value of 0 implies unbounded </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:attributeGroup >
< xs:simpleType name = "ApplicationKind" >
<!-- better to replace this with open list of tags... -->
< xs:annotation >
< xs:documentation > The kind of CEA application. This mostly affects how a service implementing the application should be discovered. </ xs:documentation >
</ xs:annotation >
< xs:restriction base = "xs:string" >
< xs:enumeration value = "processing" >
< xs:annotation >
< xs:documentation > The application is a data processing application. This means that all instances of sevrvices that can run the application are deemed to be equivalent. An example of a class of such application are the Astrogrid legacy commandline application wrapping services. </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "http" >
< xs:annotation >
< xs:documentation > application is a legacy http form style POST/GET that has been wrapped by the CEA. </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "dataproducing" >
< xs:annotation >
< xs:documentation > the application produces data - it is not assumed that every instance of a server that can run the application will produced the same results - they might have different underlying data collections. Therefore the appropriate service has to be selected by reference to other metadata about the CEACapable service. </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "grid" >
< xs:annotation >
< xs:documentation > the application is a facade onto a grid computing system. </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
</ xs:restriction >
</ xs:simpleType >
< xs:complexType name = "InputParameterReferenceSpecification" >
< xs:annotation >
< xs:documentation > The allowed structures for input parameters </ xs:documentation >
</ xs:annotation >
< xs:sequence minOccurs = "0" maxOccurs = "unbounded" >
< xs:group ref = "ceab:ParameterReferenceGroup" />
</ xs:sequence >
</ xs:complexType >
< xs:complexType name = "OutputParameterReferenceSpecification" >
< xs:annotation >
< xs:documentation > Allowed constructs for output parameters </ xs:documentation >
< xs:documentation > restricted to prefs at the moment - is there a case for pgroups... </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "pref" type = "ceab:ParameterRef" minOccurs = "0" maxOccurs = "unbounded" >
< xs:annotation >
< xs:documentation > 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? </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
</ xs:complexType >
< xs:simpleType name = "refToParameter" >
< xs:annotation >
< xs:documentation > 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. </ xs:documentation >
</ xs:annotation >
< xs:restriction base = "xs:string" />
</ xs:simpleType >
< xs:complexType name = "ConditionalPgroupOption" >
< xs:annotation >
< xs:documentation > this is the grouping of parameters that are required for a particular value of a head parameter </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "value" type = "xs:string" >
< xs:annotation >
< xs:documentation > the value that the control parameter has for this grouping </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:group ref = "ceab:ParameterReferenceGroup" maxOccurs = "unbounded" />
</ xs:sequence >
< xs:attribute name = "name" type = "xs:string" >
< xs:annotation >
< xs:documentation > name for the particular ConditionalPgroup option - can be used in user interface to label the parameter group. </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:complexType >
< xs:complexType name = "ConditionalPgroup" >
< xs:annotation >
< xs:documentation > A grouping of parameters, where the actual parameters that must be given is specified by the value of a controlling parameter. </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "cgroup" type = "ceab:ConditionalPgroupOption" maxOccurs = "unbounded" />
</ xs:sequence >
< xs:attributeGroup ref = "ceab:ParameterReferenceAttributes" />
</ xs:complexType >
< xs:attributeGroup name = "ParameterReferenceAttributes" >
< xs:annotation >
< xs:documentation > the parameters that make up a standard reference to a parameter. </ xs:documentation >
</ xs:annotation >
< xs:attribute name = "ref" type = "ceab:refToParameter" >
< xs:annotation >
< xs:documentation > reference to the parameter definition whose value determine which of the cgroups will be chosen </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "hidden" type = "xs:boolean" default = "false" >
< xs:annotation >
< xs:documentation > 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 </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "name" type = "xs:string" />
</ xs:attributeGroup >
< xs:complexType name = "ParameterDefinitionList" >
< xs:annotation >
< xs:documentation > A list of parameter definitions </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "parameterDefinition" type = "ceab:BaseParameterDefinition" minOccurs = "0" maxOccurs = "unbounded" />
</ xs:sequence >
</ xs:complexType >
< xs:complexType name = "InterfaceConstants" >
< xs:annotation >
< xs:documentation > 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. </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "pval" maxOccurs = "unbounded" minOccurs = "1" >
< xs:complexType >
< xs:sequence >
< xs:element name = "value" type = "xs:string" />
</ xs:sequence >
< xs:attribute name = "id" type = "xs:string" />
< xs:attribute name = "indirect" type = "xs:boolean" />
</ xs:complexType >
</ xs:element >
</ xs:sequence >
</ xs:complexType >
< xs:complexType name = "PGroup" >
< xs:annotation >
< xs:documentation > 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. </ xs:documentation >
<!-- perhaps some futher hints as to the intention of the PGroup could be given - e.g. should it be presented as a table-like structure in UI (when the maxOccurs is > 1) - perhaps PGroups should also have identifiers-->
</ xs:annotation >
< xs:sequence >
< xs:group ref = "ceab:ParameterReferenceGroup" minOccurs = "2" maxOccurs = "unbounded" >
< xs:annotation >
< xs:documentation > These are the elements that occur anywhere that there is a parameter reference possible in an interface. - should this be a minimum of 2? </ xs:documentation >
</ xs:annotation >
</ xs:group >
</ xs:sequence >
< xs:attributeGroup ref = "ceab:cardinality" />
< xs:attribute name = "name" type = "xs:string" use = "optional" >
< xs:annotation >
< xs:documentation > this is a name for the pgroup that can be used by UI software </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:complexType >
< xs:complexType name = "RadioPGroup" >
< xs:annotation >
< xs:documentation > A grouping of several parameters - where only one should be active at any one time. </ xs:documentation >
<!-- perhaps some futher hints as to the intention of the PGroup could be given - e.g. should it be presented as a table-like structure in UI (when the maxOccurs is > 1) - perhaps PGroups should also have identifiers-->
</ xs:annotation >
< xs:sequence >
< xs:group ref = "ceab:ParameterReferenceGroup" minOccurs = "2" maxOccurs = "unbounded" >
< xs:annotation >
< xs:documentation > These are the elements that occur anywhere that there is a parameter reference possible in an interface. - should this be a minimum of 2? </ xs:documentation >
</ xs:annotation >
</ xs:group >
</ xs:sequence >
< xs:attributeGroup ref = "ceab:cardinality" />
< xs:attribute name = "name" type = "xs:string" use = "optional" >
< xs:annotation >
< xs:documentation > this is a name for the pgroup that can be used by UI software </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:complexType >
<!-- the following used to be in CEAParameterDefinition -->
<!-- This is the standard type -->
< xs:simpleType name = "ParameterTypes" >
< xs:annotation >
< xs:documentation > 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 </ xs:documentation >
< xs:documentation > As Data Models become established then references to these should also be made as top level aggregate types </ xs:documentation >
< xs:documentation > Note that some of the "bulkier" types - e.g. VOTable would normally be passed "by reference" </ xs:documentation >
< xs:documentation > 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 </ xs:documentation >
</ xs:annotation >
< xs:restriction base = "xs:string" >
< xs:enumeration value = "integer" >
< xs:annotation >
< xs:documentation > Integer </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "real" >
< xs:annotation >
< xs:documentation > Real </ xs:documentation >
< xs:documentation > The string formats that can be recognised should be as defined by FORTRAN? Java? C? (all?) </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "complex" >
< xs:annotation >
< xs:documentation > A complex number </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "text" >
< xs:annotation >
< xs:documentation > Any string of characters </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "boolean" >
< xs:annotation >
< xs:documentation > A representation of a boolean - e.g. true/false on/off </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "anyURI" >
< xs:annotation >
< xs:documentation > Any Uniform Resource Indentifier </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "VOTable" >
< xs:annotation >
< xs:documentation > A VOTable in its entirety </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
<!-- possibly remove this - can be signalled via UCD of a real type -->
< xs:enumeration value = "angle" >
< xs:annotation >
< xs:documentation > A value that is to be interpreted as an angular coordinate measurement, e.g. RA, Dec </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "MJD" >
< xs:annotation >
< xs:documentation > Modified Julian date </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "DateTime" >
< xs:annotation >
< xs:documentation > ISO Date representation </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "ADQL" >
< xs:annotation >
< xs:documentation > the full version of the Astronomical Data Query Language </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "STC-S" >
< xs:annotation >
< xs:documentation > A value that is specified using the Space Time Coordinate string definition </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "binary" >
< xs:annotation >
< xs:documentation > A general piece of binary data with no special interpretation </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "FITS" >
< xs:annotation >
< xs:documentation > Data encoded in the Flexible Image Transport System http://fits.gsfc.nasa.gov/iaufwg/iaufwg.html </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "XML" >
< xs:annotation >
< xs:documentation > The data are encoded as generic XML. The schema for the xml is given in the UType?... </ xs:documentation >
<!-- it might be useful to have parameters specified as particular elements in an xml file - perhaps one parameter could point to the file,and the other parameters would be references into that - this would probably be best done as an extension to the pref idea - the main pref would point to the "atomic" definitian and a new attributre could point to the 'bulk' parameter -->
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "Table" >
< xs:annotation >
< xs:documentation > Data formatted in a tabular fashion </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "Image" >
< xs:annotation >
< xs:documentation > An image </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "Spectrum" >
< xs:annotation >
< xs:documentation > A spectrum </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
</ xs:restriction >
</ xs:simpleType >
< xs:complexType name = "tDocumentation" mixed = "true" >
< xs:annotation >
< xs:documentation > a type that allows any style of documentation content. </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:any processContents = "lax" minOccurs = "0" maxOccurs = "unbounded" />
</ xs:sequence >
</ xs:complexType >
< xs:simpleType name = "java-param" >
< xs:restriction base = "xs:token" >
< xs:pattern value = "[a-zA-Z][a-zA-Z0-9]*" />
</ xs:restriction >
</ xs:simpleType >
< xs:simpleType name = "java-class" >
< xs:restriction base = "xs:token" >
< xs:pattern value = "([a-zA-Z0-9]+\.)*[a-zA-Z][a-zA-Z0-9]*" />
</ xs:restriction >
</ xs:simpleType >
< xs:simpleType name = "java-package" >
< xs:restriction base = "xs:token" >
< xs:pattern value = "([a-zA-Z0-9]+\.)*[a-zA-Z0-9]*" />
</ xs:restriction >
</ xs:simpleType >
< xs:complexType name = "BaseParameterDefinition" >
< xs:annotation >
< xs:documentation > The basic definition of what a parameter is - this is common to all of the CEA implementations. </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "vs:BaseParam" >
< xs:sequence >
<!-- editor note - The UCD, UType, and MimeType are not all expected to be filled in for all parameters, but are there to give a workflow builder "hints" about the semantics of a particular parameter beyond the basic type attribute - this is rather fuzzy at the moment and it there is probably some overlap between the scopes of the elements, and certainly there is nothing stopping the user entering inconsistent information-->
< xs:element name = "mimeType" type = "xs:string" minOccurs = "0" >
< xs:annotation >
< xs:documentation > possibility to specify a mime type this can be overridden in the actual parameter passed </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "defaultValue" type = "xs:string" minOccurs = "0" maxOccurs = "unbounded" >
< xs:annotation >
< xs:documentation > a possible default for this type of parameter this is repeateable for the case of array parameters. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:choice minOccurs = "0" >
< xs:annotation >
< xs:documentation > 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.. </ xs:documentation >
</ xs:annotation >
< xs:element name = "optionList" type = "ceab:OptionList" >
< xs:annotation >
< xs:documentation > For parameters that can only have one of a list of values </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "range" type = "ceab:Range" >
< xs:annotation >
< xs:documentation > captures the idea that a parameter can have a range of values </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:choice >
</ xs:sequence >
< xs:attribute name = "id" type = "xs:string" use = "required" >
< xs:annotation >
< xs:documentation > the identifier for the parameter </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "type" type = "ceab:ParameterTypes" use = "required" >
< xs:annotation >
< xs:documentation > The data type of the parameter - note that this is not restricted to atomic data types. </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "array" type = "ceab:arrayDEF" use = "optional" default = "1" >
< xs:annotation >
< xs:documentation > deffines the array shape of the parameter if it is an array </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:extension >
</ xs:complexContent >
<!-- for the new derivation from DataService baseParam attribute name -> id element UI_NAME - uses base name element description - uses base description units - base unit UCD - base ucd -->
</ xs:complexType >
< xs:simpleType name = "arrayDEF" >
< xs:annotation >
< xs:documentation > taken from the votable definition - the first index varies most rapidy, and the last index may be specified as '*' to mean unbounded. </ xs:documentation >
</ xs:annotation >
< xs:restriction base = "xs:token" >
< xs:pattern value = "([0-9]+x)*[0-9]*[*]?(s\W)?" />
</ xs:restriction >
</ xs:simpleType >
<!-- perhaps make this more like the VOTable option element -->
< xs:complexType name = "OptionList" >
< xs:annotation >
< xs:documentation > A way of specifying that a parameter value should be taken from a list of possible values. </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "optionVal" type = "ceab:OptionVal" maxOccurs = "unbounded" >
< xs:annotation >
< xs:documentation > a possible value for a value that forms part of a list of values that a parameter could take. </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
</ xs:complexType >
< xs:complexType name = "OptionVal" mixed = "true" >
< xs:attribute name = "displayValue" type = "xs:string" use = "optional" />
</ xs:complexType >
< xs:complexType name = "RangeBound" >
< xs:annotation >
< xs:documentation > the value of a range bound </ xs:documentation >
</ xs:annotation >
< xs:simpleContent >
< xs:extension base = "xs:string" >
< xs:attribute name = "inclusive" use = "optional" type = "xs:boolean" default = "true" > </ xs:attribute >
</ xs:extension >
</ xs:simpleContent >
</ xs:complexType >
< xs:complexType name = "Range" >
< xs:annotation >
< xs:documentation > used to specify that a parameter value should lie in a particular range. </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "min" type = "ceab:RangeBound" minOccurs = "0" >
< xs:annotation >
< xs:documentation > the maximum value in the range. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "max" type = "ceab:RangeBound" minOccurs = "0" >
< xs:annotation >
< xs:documentation > the maximum value in the range. </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
<!-- uswed to be a rangekind attribute - this is redundant -->
</ xs:complexType >
<!-- the following used to be in CEAParameterDefinition -->
< xs:group name = "ParameterReferenceGroup" >
< xs:annotation >
< xs:documentation > 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. </ xs:documentation >
</ xs:annotation >
< xs:choice >
< xs:annotation >
< xs:documentation > editor note - not too sure what the best multiplicities are here - this would typically be used in a case </ xs:documentation >
</ xs:annotation >
< xs:element name = "pref" type = "ceab:ParameterRef" >
< xs:annotation >
< xs:documentation > 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? </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "pgroup" type = "ceab:PGroup" maxOccurs = "unbounded" >
< xs:annotation >
< xs:documentation > 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. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "cgroupHead" type = "ceab:ConditionalPgroup" maxOccurs = "unbounded" >
< xs:annotation >
< xs:documentation > 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. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "rgroup" type = "ceab:RadioPGroup" />
</ xs:choice >
</ xs:group >
</ xs:schema >

Appendix B. The complete CEATypes Schema

Note that this schema can be found on-line at http://www.ivoa.net/xml/CEATypes/v1.0 (i.e. the target namespace can also be used as a URL for the schema.) This location should represent the definitive source, the schema is only copied below for completeness of this document.

<!-- $id: $ -->
<!-- these are types that are used only in the CEA interface definitions -->
<!-- note that the type naming in this file is not really in line with the latest style -->
< xs:schema targetNamespace = "http://www.ivoa.net/xml/CEA/types/v1.2" elementFormDefault = "qualified" attributeFormDefault = "unqualified" version = "1.0 $Revision: 1.1.2.2 $" xmlns:xml = "http://www.w3.org/XML/1998/namespace" xmlns:xs = "http://www.w3.org/2001/XMLSchema" xmlns:ceat = "http://www.ivoa.net/xml/CEA/types/v1.2" xmlns:xlink = "http://www.w3.org/1999/xlink" xmlns:uws = "http://www.ivoa.net/xml/UWS/v1.0" xmlns:ceab = "http://www.ivoa.net/xml/CEA/base/v1.1" xmlns:vr = "http://www.ivoa.net/xml/VOResource/v1.0" >
< xs:import namespace = "http://www.ivoa.net/xml/CEA/base/v1.1" schemaLocation = "../../CEABase/v1.1/CEABase.xsd" > </ xs:import >
< xs:import namespace = "http://www.ivoa.net/xml/UWS/v1.0" schemaLocation = "../../UWS/v1.0/UWS.xsd" > </ xs:import >
< xs:import namespace = "http://www.ivoa.net/xml/VOResource/v1.0" schemaLocation = "../../../vo-resource-types/VOResource/v1.0/VOResource.xsd" />
< xs:element name = "tool" type = "ceat:Tool" />
< xs:element name = "message" type = "ceat:message-type" />
< xs:complexType name = "message-type" >
< xs:annotation >
< xs:documentation > A log entry recorded during execution </ xs:documentation >
</ xs:annotation >
< xs:all >
< xs:element name = "phase" type = "uws:ExecutionPhase" minOccurs = "1" >
< xs:annotation >
< xs:documentation > The excecution phase that the message occured in. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "content" type = "xs:string" minOccurs = "0" >
< xs:annotation >
< xs:documentation > The human readable content of the message. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "source" type = "xs:string" minOccurs = "0" >
< xs:annotation >
< xs:documentation > a label indicating the source of the message - e.g. module component name and line number in source code. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "timestamp" type = "xs:dateTime" minOccurs = "0" >
< xs:annotation >
< xs:documentation > The time at which the message was issued. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "level" type = "ceat:log-level" minOccurs = "0" >
< xs:annotation >
< xs:documentation > signicance level of the message </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:all >
</ xs:complexType >
< xs:element name = "jobId" type = "uws:JobIdentifier" >
< xs:annotation >
< xs:documentation > a concrete element containing the job identifier </ xs:documentation >
</ xs:annotation >
</ xs:element >
<!-- supporting types -->
< xs:simpleType name = "log-level" >
< xs:annotation >
< xs:documentation > Enumeration of possible message log levels. </ xs:documentation >
</ xs:annotation >
< xs:restriction base = "xs:string" >
< xs:enumeration value = "info" >
< xs:annotation >
< xs:documentation > a message with only informational content </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "warn" >
< xs:annotation >
< xs:documentation > a message that warns about a possible error condition </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
< xs:enumeration value = "error" >
< xs:annotation >
< xs:documentation > a message that informs about a definite error condition </ xs:documentation >
</ xs:annotation >
</ xs:enumeration >
</ xs:restriction >
</ xs:simpleType >
<!-- should refactor with the CEABase equivalent -->
< xs:complexType name = "ResultListType" >
<!-- not used now - moved to UWS - remove-->
< xs:sequence >
< xs:element name = "result" type = "ceat:ParameterValue" minOccurs = "0" maxOccurs = "unbounded" />
</ xs:sequence >
</ xs:complexType >
<!-- should refactor with the CEABase equivalent -->
< xs:complexType name = "InputList" >
< xs:sequence >
< xs:element name = "parameter" type = "ceat:ParameterValue" minOccurs = "0" maxOccurs = "unbounded" />
</ xs:sequence >
</ xs:complexType >
< xs:complexType name = "execution-summary-type" >
< xs:complexContent >
< xs:extension base = "uws:JobSummary" >
< xs:sequence maxOccurs = "1" >
< xs:element name = "application-name" type = "xs:string" />
<!-- need to think about whether this is ok - would probably expose as CEAresult endpoint on the job -->
< xs:element name = "inputList" type = "ceat:InputList" > </ xs:element >
< xs:element name = "outputList" type = "ceat:ResultListType" />
< xs:element name = "log" type = "ceat:message-type" maxOccurs = "unbounded" minOccurs = "0" >
< xs:annotation >
< xs:documentation > Any informative/error messages issued by the job during execution. </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
<!-- elements to use in interfaces -->
< xs:complexType name = "InitializeJob" >
< xs:sequence >
< xs:element ref = "ceat:tool" />
< xs:element name = "externalId" type = "uws:JobIdentifier" >
< xs:annotation >
< xs:documentation > An external identifier that the caller can use to identify a job. </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
</ xs:complexType >
< xs:complexType name = "Tool" mixed = "false" >
< xs:annotation >
< xs:documentation > represents an invocation of a CEA application, with all the parameter values defined. </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "input" type = "ceat:ListOfParameterValues" minOccurs = "0" >
< xs:annotation >
< xs:documentation > the list of parameters supplied as input </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "output" type = "ceat:ListOfParameterValues" minOccurs = "0" >
< xs:annotation >
< xs:documentation > the list of parameters expected as output </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
< xs:attribute name = "id" type = "vr:IdentifierURI" use = "required" >
< xs:annotation >
< xs:documentation > ivoa resource identifier of the application to call </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "interface" type = "xs:string" use = "required" >
< xs:annotation >
< xs:documentation > which interface of the application to call </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:complexType >
< xs:complexType name = "ParameterValue" mixed = "false" >
<!-- TODO probably should be in CEA Types - the only issue against this is that the interface can have a constant value, which is expressed as a Parameter Value - this should be moved to implementation detail perhaps -->
<!--The parameter value possibly needs to be more strongly typed than it is at the moment...or use the Quantity from the DM working group when available..-->
<!-- perhaps the opportunity could be taken to reduce the length of element names for the v1.0 release -->
< xs:annotation >
< xs:documentation > 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. </ xs:documentation >
</ xs:annotation >
< xs:choice >
<!-- in software use two different subtypes for this choice -->
< xs:element name = "value" type = "xs:string" >
< xs:annotation >
< xs:documentation > The value of the parameter - formally has an xsd type of string, though the 'real' type is encoded in the parameter definition </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "array" type = "ceat:ParameterValueArray" >
< xs:annotation >
< xs:documentation > very simple model of a array - cannot be sparsely filled, </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:choice >
< xs:attribute name = "id" type = "xs:string" use = "required" >
< xs:annotation >
< xs:documentation > The id is a reference to the id of the parameter as defined in the parameters section - used to be called "name" </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "encoding" type = "ceat:BinaryEncodings" use = "optional" >
< xs:annotation >
< xs:documentation > give the opportunity to specify some form of encoding for parameter values. e.g. if passing a binary parameter by value. </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "indirect" type = "xs:boolean" use = "optional" default = "false" >
< xs:annotation >
< xs:documentation > 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. This is most often called 'passing by reference' in computer languages. </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "mime" type = "xs:string" use = "optional" >
< xs:annotation >
< xs:documentation > possible mime type of the parameter </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:complexType >
< xs:complexType name = "ParameterValueArray" >
< xs:annotation >
< xs:documentation > simple array model - assumed to be fully filled in a row-major fashion </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "value" type = "xs:string" minOccurs = "0" maxOccurs = "unbounded" />
</ xs:sequence >
< xs:attribute name = "arrayShape" type = "ceab:arrayDEF" >
< xs:annotation >
< xs:documentation > editor note - should this be here to allow overriding of the parameter defintion. </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:complexType >
< xs:complexType name = "ParameterValueGroup" >
< xs:annotation >
< xs:documentation > a way of grouping parameters to indicate that there will be a repetition of parameters into a table like structure - the "table" is presented to the interface in column order and the attribute ncol indicates how many columns </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "parameter" type = "ceat:ParameterValue" maxOccurs = "unbounded" minOccurs = "1" />
</ xs:sequence >
< xs:attribute name = "ncol" type = "xs:int" />
</ xs:complexType >
< xs:complexType name = "ListOfParameterValues" >
< xs:annotation >
< xs:documentation > A list of parameter values </ xs:documentation >
</ xs:annotation >
< xs:choice maxOccurs = "unbounded" minOccurs = "0" >
<!-- perhaps it would be nice to be able to put in the parameter grouping here - especially for the case where the pgroup is a table like structure. -->
< xs:element name = "parameter" type = "ceat:ParameterValue" minOccurs = "1" maxOccurs = "1" />
< xs:element name = "parameterGroup" type = "ceat:ParameterValueGroup" />
</ xs:choice >
</ xs:complexType >
< xs:simpleType name = "BinaryEncodings" >
< xs:annotation >
< xs:documentation > 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. </ xs:documentation >
</ xs:annotation >
< xs:restriction base = "xs:string" >
< xs:enumeration value = "base64" />
< xs:enumeration value = "none" />
</ xs:restriction >
</ xs:simpleType >
< xs:element name = "executionSummary" type = "ceat:execution-summary-type" > </ xs:element >
</ xs:schema >

Appendix C. The complete VOCEA Schema

Note that this schema can be found on-line at http://www.ivoa.net/xml/VOCEA/v1.0 (i.e. the target namespace can also be used as a URL for the schema.) This location should represent the definitive source, the schema is only copied below for completeness of this document.

<!-- <?xml-stylesheet type="text/xsl" href="../../XMLPretty.xsl" ?>-->
<!-- $Id: VOCEA.xsd,v 1.4 2009/05/19 14:23:41 pah Exp $ Definition of CEA registry entries - inherits types from the CEABase.xsd schema. -->
< xs:schema targetNamespace = "http://www.ivoa.net/xml/CEA/v1.0" elementFormDefault = "unqualified" attributeFormDefault = "unqualified" version = "1.0 RC$Revision: 1.4 $" xmlns:xml = "http://www.w3.org/XML/1998/namespace" xmlns:vs = "http://www.ivoa.net/xml/VODataService/v1.1" xmlns:vm = "http://www.ivoa.net/xml/VOMetadata/v0.1" xmlns:cea = "http://www.ivoa.net/xml/CEA/v1.0" xmlns:ceab = "http://www.ivoa.net/xml/CEA/base/v1.1" xmlns:vr = "http://www.ivoa.net/xml/VOResource/v1.0" xmlns:xs = "http://www.w3.org/2001/XMLSchema" xmlns:va = "http://www.ivoa.net/xml/VOApplication/v1.0rc1" >
< xs:annotation >
< xs:documentation > this has been revised to be more v1.0 like - i.e. element definitions have been taken away and the types have the "type" suffix removed </ xs:documentation >
</ xs:annotation >
< xs:annotation >
< xs:appinfo >
< vm:SchemaName > VOCEA </ vm:SchemaName >
< vm:schemaPrefix > xs </ vm:schemaPrefix >
< vm:targetPrefix > cea </ vm:targetPrefix >
</ xs:appinfo >
< xs:documentation > An extension to the core resource metadata (VOResource) for describing applications and server within the Common Execution Architecture </ xs:documentation >
</ xs:annotation >
<!-- <xs:import namespace="http://www.ivoa.net/xml/VODataService/v1.0" schemaLocation="./VODataService-v1.0.xsd"/> -->
< xs:import namespace = "http://www.ivoa.net/xml/VOResource/v1.0" schemaLocation = "../../../vo-resource-types/VOResource/v1.0/VOResource.xsd" />
< xs:import namespace = "http://www.ivoa.net/xml/VOApplication/v1.0rc1" schemaLocation = "../../../vo-resource-types/VOApplication/v1.0rc1/VOApplication.xsd" />
< xs:import namespace = "http://www.ivoa.net/xml/CEA/base/v1.1" schemaLocation = "../../../cea/CEABase/v1.1/CEABase.xsd" />
< xs:complexType name = "CeaApplication" >
< xs:annotation >
< xs:documentation > The definition of a CEA compliant application </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "va:Application" >
< xs:sequence >
< xs:element name = "applicationDefinition" type = "ceab:ApplicationBase" >
<!-- constraints on parameter references to ensure that there are no trivial mistakes in the interface definitions -->
< xs:unique name = "parameternameunique" >
< xs:annotation >
< xs:documentation > ensures that the parameter identifiers are not duplicated for a particular application </ xs:documentation >
</ xs:annotation >
< xs:selector xpath = "./parameters/parameterDefinition" />
< xs:field xpath = "@id" />
</ xs:unique >
< xs:unique name = "interfacenameunique" >
< xs:annotation >
< xs:documentation > ensures that the interface identifiers are not duplicated for a particular application </ xs:documentation >
</ xs:annotation >
< xs:selector xpath = "./interfaces/interfaceDefinition" />
< xs:field xpath = "@id" />
</ xs:unique >
< xs:keyref name = "interfaceParameterReference" refer = "cea:parameternameunique" >
< xs:annotation >
< xs:documentation > ensures that the parameter references do point to a parameter id </ xs:documentation >
</ xs:annotation >
< xs:selector xpath = ".//pref|.//cgroupHead" />
< xs:field xpath = "@ref" />
</ xs:keyref >
< xs:keyref name = "constantReference" refer = "cea:parameternameunique" >
< xs:annotation >
< xs:documentation > ensures that the constants also point to valid parameter ids </ xs:documentation >
</ xs:annotation >
< xs:selector xpath = ".//pval" />
< xs:field xpath = "@id" />
</ xs:keyref >
</ xs:element >
</ xs:sequence >
</ xs:extension >
</ xs:complexContent >
<!-- This would benefit from some sort of indication as to what type of application - datacentre/cmdline/webapp etc.... -->
</ xs:complexType >
< xs:complexType name = "CeaCapability" >
<!-- editor's note - CEA is really only an interface definition in itself, so it is slightly unfortunate to have the 'CEAness' indicated by a capability, as this precludes doing something like directly declaring that a SIA server has a CEA interface for instance - however the it seems that there is no desire to allow CEA to be a service description metalanguage (parameters, calling interface pattern etc), so it probably does not matter - schade! -->
< xs:annotation >
< xs:documentation > The definition of a capability conforming to the CEA specification, capable of running one or more CeaApplications </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "vr:Capability" >
< xs:choice >
< xs:element name = "managedApplications" type = "cea:ManagedApplications" maxOccurs = "1" minOccurs = "1" > </ xs:element >
< xs:element name = "applicationDefinition" type = "ceab:ApplicationBase" maxOccurs = "1" minOccurs = "1" />
</ xs:choice >
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:complexType name = "ManagedApplications" >
< xs:annotation >
< xs:documentation > A reference to an application description of type CeaApplication that can be invoked via this interface. </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element maxOccurs = "unbounded" name = "applicationReference" type = "vr:IdentifierURI" >
< xs:annotation >
< xs:documentation > Reference to a CeaApplication resource entry </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
</ xs:complexType >
< xs:complexType name = "DerivedApplicationDefinition" >
< xs:annotation >
< xs:documentation > A derived application definition that has the following semantics; the parameter and interface definition lists are assumed extend the existing lists that are defined in the CeaApplication that is pointed to by the extends attribute. Redefinition or deletion of existing parameter and interface definions is not allowed. </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "ceab:ApplicationBase" >
< xs:attribute name = "extends" type = "vr:IdentifierURI" >
< xs:annotation >
< xs:documentation > point to the ApplicationDefinition to extend </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:complexType name = "CeaApplicationExtension" >
< xs:annotation >
< xs:documentation > The definition of a CEA compliant application that is made by extending an existing CeaApplication. Note that the more strict parameter name checking that is done for the CeaApplication is not done for this type as it would be beyound the scope of the xmlparser to be able to check the extra semantics inherent in the Derived application definition. </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "va:Application" >
< xs:sequence >
< xs:element name = "applicationDefinitionExtension" type = "cea:DerivedApplicationDefinition" />
</ xs:sequence >
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:complexType name = "CECInterface" >
< xs:annotation >
< xs:documentation > this is an interface that implements the CommonExecutionConnector SOAP web service It has no special elements of its own </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "vr:Interface" />
</ xs:complexContent >
</ xs:complexType >
< xs:complexType name = "UWS-PA" >
< xs:annotation >
< xs:documentation > an interface that implements the UWS-PA pattern. It has no special elements of its own </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "vr:Interface" />
</ xs:complexContent >
</ xs:complexType >
</ xs:schema >

Appendix D. An example VOCEA Instance

Appendix E. Full UML diagram for VOCEA and CEABase schema

CEA Application Model FullThis diagram presents more detail than the average author of a CEA application definition will need to understand as instance documents typically have a simpler looking structure because of the choice of common element names. It is included as a aid to authors of CEA based service implementations where the detailed relationships could be more important.

  • The diagram represents the relationships with other IVOA standard schema types, which are displayed in pink.
  • The full lists of possible attribute values are presented.
  • It is representing the types in the XML schema rather than a conceptual model, and the style of schema authoring dictated by [VR] mandates a number of intermediate types that would not be necessary in other styles.

Appendix F. Change History

This is the first version that has been made public - it is derived from IVOA WG wiki content, and the original [CEA] document.

Appendix G. The complete CEAImplementation Schema

Note that this schema can be found on-line at http://www.astrogrid.org/schema/CEAImplementation/v1.0rc1 (i.e. the target namespace can also be used as a URL for the schema.) This location should represent the definitive source, the schema is only copied below for completeness of this document.

<!-- $Id: CEAImplementation.xsd,v 1.1.2.1 2009/07/15 07:46:02 pah Exp $ -->
<!-- This schema specifies the CEC specific parts of the CEC configuration -->
<!-- todo - would perhaps be nice to include all of the registry information here also... -->
< xs:schema targetNamespace = "http://www.astrogrid.org/schema/CEAImplementation/v2.1" elementFormDefault = "unqualified" attributeFormDefault = "unqualified" version = "2.1rc1" xmlns:xml = "http://www.w3.org/XML/1998/namespace" xmlns:ceab = "http://www.ivoa.net/xml/CEA/base/v1.1" xmlns:xs = "http://www.w3.org/2001/XMLSchema" xmlns:ceaimp = "http://www.astrogrid.org/schema/CEAImplementation/v2.1" xmlns:vr = "http://www.ivoa.net/xml/VOResource/v1.0" xmlns:cea = "http://www.ivoa.net/xml/CEA/v1.0" xmlns:stc = "http://www.ivoa.net/xml/STC/stc-v1.30.xsd" xmlns:vs = "http://www.ivoa.net/xml/VODataService/v1.1" >
< xs:import schemaLocation = "../../../vo-resource-types/VODataService/v1.1/VODataService.xsd" namespace = "http://www.ivoa.net/xml/VODataService/v1.1" />
< xs:import namespace = "http://www.ivoa.net/xml/CEA/base/v1.1" schemaLocation = "../../../cea/CEABase/v1.1/CEABase.xsd" />
< xs:import namespace = "http://www.ivoa.net/xml/VOResource/v1.0" schemaLocation = "../../../vo-resource-types/VOResource/v1.0/VOResource.xsd" />
< xs:import namespace = "http://www.ivoa.net/xml/CEA/v1.0" schemaLocation = "../../../vo-resource-types/VOCEA/v1.0/VOCEA.xsd" />
< xs:complexType name = "CeaCmdLineApplicationDefinition" >
< xs:annotation >
< xs:documentation > Description of a command line application </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "ceab:ApplicationBase" >
< xs:sequence >
< xs:element name = "executionPath" type = "ceaimp:ExecutableDescription" >
< xs:annotation >
< xs:documentation > This is the file path of the executable </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
< xs:attribute name = "instanceClass" type = "xs:string" use = "optional" />
<!-- really would want the instance class to be of type java-class - but the simple castor mapping does not cope -->
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:simpleType name = "SwitchTypes" >
< xs:annotation >
< xs:documentation > normal is the -x value style and keyword is the x=value style </ xs:documentation >
</ xs:annotation >
< xs:restriction base = "xs:string" >
< xs:enumeration value = "normal" />
< xs:enumeration value = "keyword" />
</ xs:restriction >
</ xs:simpleType >
< xs:simpleType name = "FileRefTypes" >
< xs:annotation >
< xs:documentation > is a parameter treated as a file or directory reference </ xs:documentation >
</ xs:annotation >
< xs:restriction base = "xs:string" >
< xs:enumeration value = "no" />
< xs:enumeration value = "file" />
< xs:enumeration value = "directory" />
</ xs:restriction >
</ xs:simpleType >
< xs:complexType name = "CommandLineParameterDefinition" >
< xs:annotation >
< xs:documentation > Defines what it is to be a command line parameter - needs more thought with experience </ xs:documentation >
< xs:documentation > implmentation note - it would probably be better to implement most of the properties that are attributes as elements, as there are relationships between the attributes that are not properly expressed in this type. </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "ceab:BaseParameterDefinition" >
< xs:attribute name = "commandSwitch" type = "xs:string" use = "optional" >
< xs:annotation >
< xs:documentation > The characters that make up the commandline switch </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "commandPosition" type = "xs:int" use = "optional" default = "-1" >
< xs:annotation >
< xs:documentation > the command position for a position only parameter. The default value means that the parameter is position independent and is assumed to need a switch. Conversely if a parameter has a position value it is assumed not to need a switch </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "switchType" type = "ceaimp:SwitchTypes" use = "optional" default = "normal" >
< xs:annotation >
< xs:documentation > specifies the style of the switch - would be better to call switchStyle! </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "fileRef" type = "ceaimp:FileRefTypes" use = "optional" default = "file" >
< xs:annotation >
< xs:documentation > does the application treat the parameter as a reference to a file or a directory. If it is a directory and an output parameter, then the corresponding parameter should be repeatable </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "localFileName" type = "xs:string" use = "optional" >
< xs:annotation >
< xs:documentation > the local name of the file that this parameter refers to if the application uses a fixed file name </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "isStreamable" type = "xs:boolean" default = "false" >
< xs:annotation >
< xs:documentation > indicates whether the underlying application is capable of streaming the content pointed to by the parameter - if the local file name is set to "-" then stdout and stdin should be used otherwise it should be assumed that the application can natively stream the parameter (e.g. reading a url) so no attempt should be made by the CEC to download to a local file </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:complexType name = "ExecutableDescription" mixed = "true" >
< xs:annotation >
< xs:documentation > an executable description that allows for backward compatibility with existing setups - the string value is the command line </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "commandpval" type = "xs:string" maxOccurs = "unbounded" minOccurs = "0" >
< xs:annotation >
< xs:documentation > a possible fixed parameter to be placed on the command line - these are treated as individual strings to be added to the command line at this level, so for example -cp /somedir/some.jar would need to be represented by two commmandpval elements with each string <commandpval>-cp</commandpval> <commandpval>/somedir/some.jar</commandpval> </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
</ xs:complexType >
<!-- Stuff to do with HttpApplications most of this used to be in CEABase - however now considered an implementation dependent part of CEA TODO should it be in VOCEA? TODO the capitalization of names in the HTTP elements does not follow latest conventions. -->
<!--The calling document describing the call to the web service-->
< xs:complexType name = "CeaHttpApplicationDefinition" >
< xs:annotation >
< xs:documentation > The definition of a CEA http application </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "ceab:ApplicationBase" >
< xs:sequence >
< xs:element name = "CeaHttpAdapterSetup" type = "ceaimp:WebHttpApplicationSetup" />
</ xs:sequence >
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:complexType name = "ProxyApplicationSetup" >
< xs:annotation >
< xs:documentation > Extra description necessary for describing the case where CEA acts as proxy to underlying service </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:choice >
< xs:element name = "URL" type = "ceaimp:HttpURLType" >
< xs:annotation >
< xs:documentation > A direct reference to a url of the underlying service </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "ResourceReferenceQuery" type = "xs:string" >
< xs:annotation >
< xs:documentation > A query using the registry query language to reference one or more registered resources that provide the underlying http GET/POST service. </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:choice >
</ xs:sequence >
</ xs:complexType >
< xs:complexType name = "WebHttpApplicationSetup" >
< xs:annotation >
< xs:documentation > Description of an HTTP Application </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "ceaimp:ProxyApplicationSetup" >
< xs:sequence >
< xs:element name = "PreProcessScript" type = "ceaimp:PreProcessScript" minOccurs = "0" >
< xs:annotation >
< xs:documentation > This script can be used to map the input parameters to the parameters of the underlying service. This should not usually be necessary as the application defintion will usually be a one-to-one mapping. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "PostProcessScript" type = "ceaimp:PostProcessScript" minOccurs = "0" >
< xs:annotation >
< xs:documentation > This script can be used to post process the result returned by the http application. e.g. to perform a 'screen-scrape' </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:complexType name = "WebHttpCall" >
<!-- this is really an implementation class - not sure that it should be in this schema -->
< xs:annotation >
< xs:documentation > Description of an HTTP get or post service </ xs:documentation >
</ xs:annotation >
< xs:sequence >
< xs:element name = "URL" type = "ceaimp:HttpURLType" />
< xs:element name = "SimpleParameter" minOccurs = "0" maxOccurs = "unbounded" >
< xs:complexType >
< xs:attribute name = "name" type = "xs:string" use = "required" />
< xs:attribute name = "value" type = "xs:string" use = "required" />
</ xs:complexType >
</ xs:element >
</ xs:sequence >
</ xs:complexType >
< xs:complexType name = "HttpURLType" >
< xs:annotation >
< xs:documentation > The URL for an http get or post service </ xs:documentation >
</ xs:annotation >
< xs:simpleContent >
< xs:extension base = "xs:string" >
< xs:attribute name = "method" type = "ceaimp:HttpMethodType" default = "get" >
< xs:annotation >
< xs:documentation > the http method to be used to send parameters to the service. </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:extension >
</ xs:simpleContent >
</ xs:complexType >
< xs:simpleType name = "HttpMethodType" >
< xs:annotation >
< xs:documentation > http method type: get or post </ xs:documentation >
</ xs:annotation >
< xs:restriction base = "xs:string" >
< xs:enumeration value = "get" />
< xs:enumeration value = "post" />
</ xs:restriction >
</ xs:simpleType >
< xs:complexType name = "script" >
< xs:annotation >
< xs:documentation > a snippet of code to massage the inputs and outputs </ xs:documentation >
</ xs:annotation >
< xs:simpleContent >
< xs:extension base = "xs:string" >
< xs:attribute name = "lang" type = "ceaimp:scriptingLanguage" use = "optional" default = "xslt" />
</ xs:extension >
</ xs:simpleContent >
</ xs:complexType >
< xs:simpleType name = "scriptingLanguage" >
< xs:annotation >
< xs:documentation > Scripting language </ xs:documentation >
</ xs:annotation >
< xs:restriction base = "xs:string" >
< xs:enumeration value = "xslt" />
< xs:enumeration value = "javascript" />
< xs:enumeration value = "groovy" />
</ xs:restriction >
</ xs:simpleType >
<!--definitions for web service proxy - experimental-->
< xs:complexType name = "WebServiceApplicationSetup" >
< xs:annotation >
< xs:documentation > Description of WebService </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "ceaimp:ProxyApplicationSetup" >
< xs:sequence />
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:complexType name = "PreProcessScript" >
<!-- not sure that there is any purpose to preprocess script - just needs to be http post or get.... -->
< xs:simpleContent >
< xs:extension base = "ceaimp:script" />
</ xs:simpleContent >
</ xs:complexType >
< xs:complexType name = "PostProcessScript" >
< xs:annotation >
< xs:documentation > this could be a script to do screen scraping for instance.... </ xs:documentation >
</ xs:annotation >
< xs:simpleContent >
< xs:extension base = "ceaimp:script" />
</ xs:simpleContent >
</ xs:complexType >
< xs:complexType name = "ColumnReference" >
< xs:annotation >
< xs:documentation > A reference to a column described by the general table metadata - FIXME - is this used any more? </ xs:documentation >
</ xs:annotation >
< xs:attribute name = "schema" type = "xs:string" use = "optional" />
< xs:attribute name = "table" type = "xs:string" use = "optional" />
< xs:attribute name = "column" type = "xs:string" use = "required" />
</ xs:complexType >
< xs:complexType name = "DBParameterDefinition" >
< xs:complexContent >
< xs:extension base = "ceab:BaseParameterDefinition" >
< xs:sequence >
< xs:element name = "column" type = "xs:string" >
< xs:annotation >
< xs:documentation > A reference to a column in a table in the database - the precise form of the reference depends on how the rest of the application has been set up. </ xs:documentation >
</ xs:annotation >
</ xs:element >
</ xs:sequence >
< xs:attribute name = "isOutput" type = "xs:boolean" default = "true" use = "optional" >
< xs:annotation >
< xs:documentation > should the "parameter" appear in the output VOTable </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:complexType name = "CeaDBApplicationDefinition" >
< xs:annotation >
< xs:documentation > A Database Application - better to derive from CEAApplication? </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "ceab:ApplicationBase" >
< xs:sequence >
< xs:element name = "dbref" type = "xs:string" >
< xs:annotation >
< xs:documentation > reference to the database connection - this should be a reference to a JNDI data source. </ xs:documentation >
</ xs:annotation >
</ xs:element >
< xs:element name = "tableset" type = "vs:TableSet" maxOccurs = "1" minOccurs = "0" />
</ xs:sequence >
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:complexType name = "DBParameterMapping" >
< xs:sequence >
< xs:element name = "colref" type = "ceaimp:ColumnReference" maxOccurs = "unbounded" minOccurs = "0" />
</ xs:sequence >
< xs:attribute name = "ref" type = "xs:string" />
</ xs:complexType >
< xs:complexType name = "CEADALService" >
< xs:annotation >
< xs:documentation > Definition of a general DAL style service served by a CEA server. Includes possibility of specifying ApplicationDefinition - parameters Coverage desired outputs Capabilities - but only need to put in the standardId - the other things will be filled in automatically </ xs:documentation >
</ xs:annotation >
< xs:complexContent >
< xs:extension base = "vs:DataService" >
< xs:sequence >
< xs:element name = "applicationDefinition" type = "ceab:ApplicationBase" > </ xs:element >
</ xs:sequence >
< xs:attribute name = "publishApplication" type = "xs:boolean" use = "optional" default = "false" >
< xs:annotation >
< xs:documentation > if true the application will be published as a separate CEAApplication as well as the DAL service defined here. </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
< xs:attribute name = "DALkind" type = "ceaimp:DALKind" use = "required" >
< xs:annotation >
< xs:documentation > specify the type of DAL application </ xs:documentation >
</ xs:annotation >
</ xs:attribute >
</ xs:extension >
</ xs:complexContent >
</ xs:complexType >
< xs:element name = "CECConfig" >
< xs:complexType >
< xs:sequence maxOccurs = "1" minOccurs = "1" >
< xs:choice maxOccurs = "unbounded" minOccurs = "1" >
< xs:element ref = "ceaimp:CeaApplication" />
< xs:element ref = "ceaimp:CeaDALService" />
</ xs:choice >
</ xs:sequence >
</ xs:complexType >
</ xs:element >
< xs:element name = "CeaApplication" type = "cea:CeaApplication" />
< xs:element name = "CeaDALService" type = "ceaimp:CEADALService" />
< xs:simpleType name = "DALKind" >
< xs:restriction base = "xs:string" >
< xs:enumeration value = "SIAP" />
< xs:enumeration value = "SSAP" />
< xs:enumeration value = "TAP" />
</ xs:restriction >
</ xs:simpleType >
</ xs:schema >

Appendix H. The complete CEAExecutionRecord Schema

Note that this schema can be found on-line at http://www.astrogrid.org/schema/CEAExecutionRecord/v1.0rc1 (i.e. the target namespace can also be used as a URL for the schema.) This location should represent the definitive source, the schema is only copied below for completeness of this document.

Appendix I. An example CEC Configuration file.

[RFC 2119]
Bradner, S. 1997. [] , IETF RFC 2119, http://www.ietf.org/rfc/rfc2119.txt
[RM]
Hanisch, Robert (ed.) 2004. [] , IVOA Recommendation, http://www.ivoa.net/Documents/REC/ResMetadata/RM-20040426.htm
[VR]
Plante, Ray (ed.) 2006. VOResource: an XML Encoding Schema for Resource Metadata, IVOA Working Draft, http://www.ivoa.net/Documents/latest/VOResource.html
[VA]
Harrison, Paul. (ed.) 2007. VOApplication: an XML Encoding Schema for Application Resource Metadata, IVOA Working Draft, http://www.ivoa.net/Documents/latest/VOApplicationDM.html
[VSTD]
Harrison, Paul. (ed.) 2007. VOStandard: an XML Encoding Schema for IVOA Standards, IVOA Working Draft, http://www.ivoa.net/Documents/latest/VOResource.html
[VOTABLE]
Ochsenbein & Williams. (eds.) 2004. VOTable Format Definition, version 1.1, http://www.ivoa.net/Documents/latest/VOT.html
[UCD]
Derriere et. al. 2004. An IVOA Standard for Unified Content Descriptors, version 1.10, http://www.ivoa.net/Documents/latest/UCD.html
 
[CEA]
Harrison, Paul. 2005. A Proposal for a Common Execution Architecture , IVOA Working Draft, http://www.ivoa.net/Documents/latest/CEA.html
[CEAINT]
Harrison, Paul. 2007. CEA Interfaces: How to Invoke Applications in the Common Execution Architecture, IVOA Working Draft, http://www.ivoa.net/Documents/latest/CEAInterface.html
 
[xml]
Bray, Tim, Paoli, Jean, Sperberg-McQueen, C. M., Maler, Eve, Yergeau, Francois (editors) 2004, [] , W3C /TR/REC-xml
[schema]
Fallside, David C., Walmsley, Priscilla (editors) 2004, [] , W3C Recommendation 28 October 2004, http://www.w3.org/TR/xmlschema-0/
[ISO8601]
Wolf, Misha and Wicksteed, Charles 1997, [] , http://www.w3.org/TR/NOTE-datetime.
[OAI]
Lagoze, Carl, Van de Sompel, Herbert, Nelson, Michael, and Warner, Simeon 2004, [] , http://www.openarchives.org/OAI/openarchivesprotocol.html.
[ID]
Plante, R., Linde, T., Williams, R., Noddle, K. 2005, [] , http://www.ivoa.net/Documents/REC/Identifiers/Identifiers-200505XX.html.
[FITS]
FITS: Flexible Image Transport Specification, specifically the Binary Tables Extension, http://fits.gsfc.nasa.gov/.
[WSDL]
Christensen, E., Curbera, F., Meredith, G., Weerawarana, S. [] , W3C Note 15 March 2001, http://www.w3.org/TR/wsdl.
[SOAP]
Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendolsohn, N., Neilsen, H.F., Thatte, S., Winer, D. [] , W3C Note 08 May 2000, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

$Revision: 847 $ $Date: 2008-10-29 14:33:57 +0000 (Wed, 29. Oct 2008) $ $HeadURL: $