diff --git a/Repository_Explorer-2.0-1.46/Makefile b/Repository_Explorer-2.0-1.46/Makefile new file mode 100644 index 0000000..0388535 --- /dev/null +++ b/Repository_Explorer-2.0-1.46/Makefile @@ -0,0 +1,157 @@ +# Makefile for OAI Repository Explorer +# July 2005 +# Hussein Suleman + +# variables +include ../deploy_env.properties + +ifeq ($(wildcard /data/rofr/devel/$(USER)/ivy),) + IVY_DEFAULT_IVY_USER_DIR = +else + IVY_DEFAULT_IVY_USER_DIR = -Divy.default.ivy.user.dir=/data/rofr/devel/$(USER)/ivy +endif + +RESOLVER = local +STATUS = integration +OVERWRITE = false +JAVA = java +CFLAGS = -O2 -Iexpat/lib -Wno-deprecated +C++ = g++ + +LDFLAGS = + +LFLAGS = -lcurl + +# rules +# list the headers to get the dependencies right. +# needs to be refactored if the includes change +# run 'g++ -MM about.c' to get new dependencies after changing the includes +about.o: about.c blocks.h cgi.h attlist.h config.h language.h + $(C++) $(CFLAGS) -o $*.o -c $< +addarchive.o: addarchive.c blocks.h cgi.h attlist.h config.h language.h + $(C++) $(CFLAGS) -o $*.o -c $< +attlist.o: attlist.c attlist.h escape.h + $(C++) $(CFLAGS) -o $*.o -c $< +blocks.o: blocks.c config.h language.h + $(C++) $(CFLAGS) -o $*.o -c $< +cgi.o: cgi.c cgi.h attlist.h + $(C++) $(CFLAGS) -o $*.o -c $< +comply.o: comply.c config.h language.h taglist.h attlist.h validate.h \ + xml.h + $(C++) $(CFLAGS) -o $*.o -c $< +convert.o: convert.c + $(C++) $(CFLAGS) -o $*.o -c $< +convpredef.o: convpredef.c + $(C++) $(CFLAGS) -o $*.o -c $< +escape.o: escape.c + $(C++) $(CFLAGS) -o $*.o -c $< +language.o: language.c attlist.h language.h + $(C++) $(CFLAGS) -o $*.o -c $< +parser2.o: parser2.c config.h escape.h language.h parser2.h taglist.h \ + attlist.h + $(C++) $(CFLAGS) -o $*.o -c $< +parser.o: parser.c escape.h language.h parser.h taglist.h attlist.h + $(C++) $(CFLAGS) -o $*.o -c $< +replace.o: replace.c replace.h + $(C++) $(CFLAGS) -o $*.o -c $< +sortlist.o: sortlist.c sortlist.h + $(C++) $(CFLAGS) -o $*.o -c $< +taglist.o: taglist.c taglist.h attlist.h + $(C++) $(CFLAGS) -o $*.o -c $< +testoai.o: testoai.c blocks.h cgi.h attlist.h config.h language.h \ + parser.h taglist.h parser2.h sortlist.h validate.h xml.h + $(C++) $(CFLAGS) -o $*.o -c $< +validate.o: validate.c config.h replace.h taglist.h attlist.h validate.h \ + xml.h + $(C++) $(CFLAGS) -o $*.o -c $< +xml.o: xml.c expat/lib/expat.h expat/lib/expat_external.h taglist.h \ + attlist.h + $(C++) $(CFLAGS) -o $*.o -c $< + +# targets + +OBJECTS = xml.o attlist.o taglist.o escape.o language.o \ + validate.o replace.o comply.o blocks.o + +OBJECTS2 = cgi.o xml.o attlist.o taglist.o parser.o escape.o language.o \ + validate.o replace.o testoai.o sortlist.o blocks.o parser2.o + +OBJECTS3 = cgi.o attlist.o language.o addarchive.o blocks.o escape.o + +OBJECTS4 = cgi.o attlist.o language.o blocks.o about.o escape.o + +XMLOBJECTS = expat/lib/xmlparse.o \ + expat/lib/xmltok.o \ + expat/lib/xmlrole.o + +TARGET = comply +TARGET2 = testoai +TARGET3 = addarchive +TARGET4 = about + +all: $(TARGET) $(TARGET2) $(TARGET3) $(TARGET4) + @echo Finis. + +dist: oai-repository-explorer.tar.gz + +install: publish + +config.h: config.h.in + sed -e "s,@rofr_base_url@,$(rofr.base.url),g; s,@rofr_email@,$(rofr.email),g; s,@rofr_home@,$(rofr.home.dir),g; s,@python_path@,$(python.path),g; s,@http_proxy@,$(http.proxy),g; s,@https_proxy@,$(https.proxy),g;" $< > $@ + +$(TARGET): config.h $(OBJECTS) $(XMLOBJECTS) + $(C++) $(LDFLAGS) -o $(TARGET) $(OBJECTS) $(XMLOBJECTS) $(LFLAGS) + +$(TARGET2): config.h $(OBJECTS2) $(XMLOBJECTS) + $(C++) $(LDFLAGS) -o $(TARGET2) $(OBJECTS2) $(XMLOBJECTS) $(LFLAGS) + +$(TARGET3): config.h $(OBJECTS3) + $(C++) $(LDFLAGS) -o $(TARGET3) $(OBJECTS3) $(LFLAGS) + +$(TARGET4): config.h $(OBJECTS4) + $(C++) $(LDFLAGS) -o $(TARGET4) $(OBJECTS4) $(LFLAGS) + +$(XMLOBJECTS): + cd expat ; make ; cd .. + +oai-repository-explorer.tar.gz: comply enus.lan toolkit.xsd lynx.pl resolve + -rm -fr oai-repository-explorer/ + mkdir -p oai-repository-explorer/bin/ + mkdir -p oai-repository-explorer/lib/ + cd oai-repository-explorer/bin + ln comply oai-repository-explorer/bin/comply + ln enus.lan oai-repository-explorer/bin/enus.lan + ln toolkit.xsd oai-repository-explorer/bin/toolkit.xsd + ln lynx.pl oai-repository-explorer/bin/lynx.pl + ln xerces/validate.sh oai-repository-explorer/bin/validate.sh + ln lib/xercesImpl.jar oai-repository-explorer/lib/ + ln lib/xercesSamples.jar oai-repository-explorer/lib/ + ln lib/xml-apis.jar oai-repository-explorer/lib/ + tar czf oai-repository-explorer.tar.gz oai-repository-explorer/ + -rm -fr oai-repository-explorer/ + +resolve: ../ivysettings.xml ivy.xml + $(JAVA) $(IVY_DEFAULT_IVY_USER_DIR) -jar antlib/ivy.jar -settings ../ivysettings.xml -ivy ivy.xml -retrieve 'lib/[artifact](-[classifier]).[ext]' + +publish: dist ../ivysettings.xml ivy.xml + if [ "$(STATUS)" == "integration" ]; \ + then revision=`date +%Y%m%d%H%M%S`; \ + else revision=`sed -e '/#define reversion "/!d' -e 's/#define reversion "\([^"]*\)"/\1/' -e q config.h`; \ + fi; \ + $(JAVA) $(IVY_DEFAULT_IVY_USER_DIR) -jar antlib/ivy.jar -settings ../ivysettings.xml -ivy ivy.xml -publish $(RESOLVER) -publishpattern "[module].[ext]" -revision $$revision -status $(STATUS) -overwrite $(OVERWRITE) + +clean: + cd expat ; make clean ; cd .. + rm -f *.o config.h + +distclean: veryclean + rm -rf oai-repository-explorer.tar.gz ivy-*.xml lib/ + +veryclean: + cd expat ; make clean ; cd .. + rm -f *.o config.h + rm -f $(TARGET) + rm -f $(TARGET2) + rm -f $(TARGET3) + rm -f $(TARGET4) + diff --git a/ivoaharvest/src/main/resources/html/index.html.in b/ivoaharvest/src/main/resources/html/index.html.in index e5bd79c..32e4bf2 100644 --- a/ivoaharvest/src/main/resources/html/index.html.in +++ b/ivoaharvest/src/main/resources/html/index.html.in @@ -90,7 +90,7 @@ OAI interface. XXXXX XXXXX - + diff --git a/ivoaharvest/src/main/resources/net/ivoa/registry/validate/registrySchemaLocation.txt b/ivoaharvest/src/main/resources/net/ivoa/registry/validate/registrySchemaLocation.txt index 868c349..1673911 100644 --- a/ivoaharvest/src/main/resources/net/ivoa/registry/validate/registrySchemaLocation.txt +++ b/ivoaharvest/src/main/resources/net/ivoa/registry/validate/registrySchemaLocation.txt @@ -24,6 +24,3 @@ http://www.ivoa.net/xml/VOSIAvailability/v1.0 schemas/VOSIAvailability-v1.0.xsd http://www.ivoa.net/xml/VOSICapabilities/v1.0 schemas/VOSICapabilities-v1.0.xsd http://www.ivoa.net/xml/VOSITables/v1.0 schemas/VOSITables-v1.1.xsd http://www.ivoa.net/xml/VOApplication/v1.0rc1 schemas/VOApplication-v1.0rc1.xsd -http://www.ivoa.net/xml/CEA/base/v1.1 schemas/CEABase-v1.0.xsd -http://www.ivoa.net/xml/CEA/v1.0rc1 schemas/CEAService-v1.0rc1.xsd -http://www.ivoa.net/xml/CEA/v1.0 schemas/CEA-v1.0.xsd diff --git a/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEA-v1.0.xsd b/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEA-v1.0.xsd deleted file mode 100644 index 7f3bf98..0000000 --- a/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEA-v1.0.xsd +++ /dev/null @@ -1,163 +0,0 @@ - - - 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 - - - - VOCEA - xs - cea - - - An extension to the core resource metadata (VOResource) for - describing applications and server within the Common Execution Architecture - - - - - - - - - - - - The definition of a CEA compliant application - - - - - - - - - ensures that the parameter identifiers are not duplicated for a particular application - - - - - ensures that the interface identifiers are not duplicated for a particular application - - - - - - - ensures that the parameter references do point to a parameter id - - - - - - - - - ensures that the constants also point to valid parameter ids - - - - - - - - - - - - - - - - The definition of a capability conforming to the CEA - specification, capable of running one or more - CeaApplications - - - - - - - - - - - - - - - A reference to an application description of type CeaApplication that can be invoked via this interface. - - - - Reference to a CeaApplication resource entry - - - - - - - - - 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. - - - - - - - - - - point to the ApplicationDefinition to extend - - - - - - - - - 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. - - - - - - - - - - - - - - - this is an interface that implements the - CommonExecutionConnector SOAP web service It has no special - elements of its own - - - - - - - an interface that implements the - UWS-PA pattern. It has no special - elements of its own - - - - \ No newline at end of file diff --git a/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEABase-v1.0.xsd b/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEABase-v1.0.xsd deleted file mode 100644 index a5134be..0000000 --- a/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEABase-v1.0.xsd +++ /dev/null @@ -1,775 +0,0 @@ - - - - - A group where only one of the members is active at any one time - - equivalent to the same construct in HTML - - - - - - 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 name for the interface to displace in UI - - - - - - - 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 - - - - - - - - The kind of CEA application. This mostly affects how a service implementing the application should be discovered. - - - - - - - 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. - - - - - - - application is a legacy http form style POST/GET that has been wrapped by the CEA. - - - - - - - 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. - - - - - - - the application is a facade onto a grid computing system. - - - - - - - - - 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. - - - - - - - - - - - - - - - - - - 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. - - should this be a minimum of 2? - - - - - - - - this is a name for the pgroup that can be used by UI - software - - - - - - - - A grouping of several parameters - where only one should be active at any one time. - - - - - - - - These are the elements that occur anywhere that there - is a parameter reference possible in an interface. - - should this be a minimum of 2? - - - - - - - - this is a name for the pgroup that can be used by UI - software - - - - - - - - - - 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 an angular - coordinate measurement, e.g. RA, Dec - - - - - - Modified Julian date - - - - - - ISO Date representation - - - - - - - the full version of the 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?... - - - - - - Data formatted in a tabular fashion - - An image - A spectrum - - - - - - 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 mime type this can be - overridden in the actual parameter passed - - - - - - - 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 - - - - - - - - - - - taken from the votable definition - the first index varies - most rapidy, and the last index may be specified as '*' to - mean unbounded. - - - - - - - - - - - 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. - - - - - - - - - - - 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. - - - - - - - - - \ No newline at end of file diff --git a/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEABase-v1.0rc1.xsd b/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEABase-v1.0rc1.xsd deleted file mode 100644 index 4c3f8c5..0000000 --- a/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEABase-v1.0rc1.xsd +++ /dev/null @@ -1,1097 +0,0 @@ - - - - - - - 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. - - - - - - - - - - - Extra description necessary for describing the case where - CEA acts as proxy to underlying service - - - - - - - - A direct reference to a url of the underlying - service - - - - - - - A query using the registry query language to - reference one or more registered resources that - provide the underlying http GET/POST service. - - - - - - - - - - Description of an HTTP Application - - - - - - - - - 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. - - - - - - - This script can be used to post process the - result returned by the http application. e.g. to - perform a 'screen-scrape' - - - - - - - - - - - - Description of an HTTP get or post service - - - - - - - - - - - The URL for an http get or post service - - - - - - - - the http method to be used to send parameters to - the service. - - - - - - - - - - http method type: get or post - - - - - - - - - - - a snippet of code to massage the inputs and outputs - - - - - - - - - - - Scripting language - - - - - - - - - - - Description of WebService - - - - - - - - - - - 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 . - - - - - - - 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. - - - - - - - - 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. - - - - - - - - used to specify that a parameter value should lie in a - particular range. - - - - - - - the minimum 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. - - - - - - \ No newline at end of file diff --git a/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEAService-v1.0rc1.xsd b/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEAService-v1.0rc1.xsd deleted file mode 100644 index f97fc91..0000000 --- a/ivoaharvest/src/main/resources/net/ivoa/registry/validate/schemas/CEAService-v1.0rc1.xsd +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - 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 - - - - VOCEA - xs - cea - - - An extension to the core resource metadata (VOResource) for - describing applications and server within the Common Execution Architecture - - - - - - - - - - - - The definition of a CEA compliant application - - - - - - - - - ensures that the parameter identifiers are not duplicated for a particular application - - - - - ensures that the interface identifiers are not duplicated for a particular application - - - - - - - ensures that the parameter references do point to a parameter id - - - - - - - - - ensures that the constants also point to valid parameter ids - - - - - - - - - - - - - - - The definition of a capability conforming to the CEA - specification, capable of running one or more - CeaApplications - - - - - - - - - - - - - A reference to an application description of type CeaApplication that can be invoked via this interface. - - - - Reference to a CeaApplication resource entry - - - - - - - - - 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. - - - - - - - - - - point to the ApplicationDefinition to extend - - - - - - - - - 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. - - - - - - - - - - - - - - - this is an interface that implements the - CommonExecutionConnector SOAP web service It has no special - elements of its own - - - - - - - an interface that implements the - UWS-PA pattern. It has no special - elements of its own - - - - \ No newline at end of file diff --git a/rofrtar/antlib/ivy.jar b/rofrtar/antlib/ivy.jar index 14ff88e..eb7569f 100644 Binary files a/rofrtar/antlib/ivy.jar and b/rofrtar/antlib/ivy.jar differ