• • This model reflects the TAP data model
  • "catalog" is an overloaded term, with different connotations in astronomy and database technology.
  • To make searching more straight forward, it is considered important that all table elements are addressable via a single simple XPath location (e.g. tableset/schema/table).
  • The introduction of schema does not address the issue of backward compatibility with VODataService v1.0 in which the CatalogService resource type lists tables at _two levels higher_--i.e. there are no tableset and schema levels. This proposal takes the position that the table set organization is more important than this backward compatibility. Consequently, it would be helpful to users to migrate uses of v1.0 to v1.1 as broadly and quickly as possible.

• • There was the prudent suggestion (by DougTody and supported by others) that these need further prototyping before we lock them into a schema that would be difficult to revise later. (McGlynn noted a similar join feature in HEASARC services that proved not to be useful in practice.) Instead extension mechanisms will provide a way to add these in the future.

• • an xsi:type attribute can added to <tableset>, <schema>, and/or =<table> to allow additional elements to be added. (Note you can pretty much do this anywhere in a VOResource document.)
  • the <dataType> elements feature optional attributes, extendedType and extendedSchema to indicate a column or parameter has an extended type. When present, the element value is the type to assume if the extended type is not recognized or supported.

Previous Discussion of Proposed Changes

Proposed Changes

These changes were proposed in Cambridge and were motivated by recent development work on the Simple Spectral Access (SSA) Protocol. The presentation here reflects the feedback provided during the Registry Working Group Session in Cambridge.

1. Add an optional <testArgs> to the ParamHTTP Interface type
   • Definition: a formatted set of arguments that, when applied to the access URL, can be used to test the service.
   • this mechanism is useful regardless of whether the service complies with a standard or not.
   • the format is a string such that when concatonated after the access URL, it produces a legal URL.
   • the arguments should be chosen such that the resulting query returns a legal, non-empty result.
2. Add an optional <rights> element to the DataService Resource type. DROPPED
   • This proposal has been dropped. When proposed, this was thought to be missing from DataService; however, it is included in the definition of the more general Service Resource type.
3. Add an optional <dataset> element to the DataService and DataCollection Resource types. DROPPED
   • provides a listing of Dataset identifiers that are available for use as input to the service
   • This proposal is being dropped as it does not address the original intended use of dataset IDs within SSA.

This change was motivated by recent work on TAP and VOSI.

1. Add extra elements to describe use of tables and databases.
   • Extra types are RelationalSchema, Function, RelationalJoin.
   • Two possible schema: one with mandatory nesting table in schema in catalog; one with the structure partially flattened.
   • XML schema with deeper nesting
   • XML schema partially flattened
   • The flatter schema allows all resources that validated against VODataService 1.0 to validate against VODataService 1.1.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->