Re: updated SSA schema for the registry

Hi Ray -

> The IVOA twiki page, SsaResourceSchema, has the latest SSA extension
> schema posted as SSA-wd.xsl. If there are no further comments on this,
> we will release it as an external working draft and begin using it
> in our registries.
>
> On advice of the SSA spec editor, this latest version distinguishes
> pre-1.0 implemenatations from truely v1.0 compliant is with different
> capability xsi:types: "SimpleSpectralAcces" for post 1.0 versions
> and "ProtoSpectralAccess." Please review the section labeled,
> "Representing v1.0 and pre-1.0 Implementations".
>
> LAST CHANCE FOR COMMENTS!
>
> thanks!
> Ray

I uploaded a new version of the SSA resource schema to the above TWiki page. I did not change anything else on the page since I imagine you would like to confirm the changes before accepting anything of this.

While there were quite a few edits (see below) they are mostly minor and I doubt if they will affect the ongoning registry implementations. The semantics and document notes though will be important when it comes time for SSA implementors to actually fill in this metadata.

You guys have moved along greatly with this in trying to get getCapabilities defined for SSA V1.1! About all that is left at this point, is adding a set of optional capabilities (the "supports" element), and tweaking how the service parameters are defined.

• Doug
  • summary of changes from V0.3 ----
    • o In maxSearchRadius, noted that this differs from SIZE which specifies the diameter of the search region. o In maxRecords, noted that if not specified there is no predefined hard limit on the size of a query response. o In defaultMaxRecords, noted that if not specified the default maxRecords is undefined (but there might nonetheless be one). o In maxAperture added mention that the units are diameter in decimal degrees, as for the APERTURE parameter (also fixed a typo: "special extraction" -> "spectral extraction". o In maxAperture changed default value (indicating no builtin limit) from 180 to 360 degrees since APERTURE is a diameter not a radius. o Uncommented supportedFrame and modified the definition so that this can be used to specify an allowable frame value to be input via the POS parameter. The type was changed from anyURI to string. Added examples of typical values. Added note that the default if nothing is specified "ICRS". o In maxFileSize changed the units from bytes to kilobytes for consistency with SSA. o In the description of complance level changed "TOME" to "TIME". Noted that a compliant service may also return native data. o In creationType, changed enumeration "specialExtraction" to "spectralExtraction". o In the description of POS in test query, changed "the size of the search radius" to "the diameter of the search region specified in decimal degrees". o In the test query generalized the description of POS from "a position in the sky to search" to "search position" as SSA is not limited to sky coordinate frames. o In the specification of protoSpectralAccess, added a new element "dataModel" to define the data model of the native data returned by the proto service. o In the specification of protoSpectralAccess deleted defaultMaxRecords and maxAperture since proto spectral services do not support SSA features such as MAXRECORDS and spectral extraction with APERTURE (maxRecords is still defined). Also deleted supportedFrame and "supports" as ICRS can be assumed for proto services, and there are no standard optional service capabilities. Overall these changes simplify the description of proto services somewhat to match current practice. o In the specification of protoSpectralAccess changed the maxFileSize units to kilobytes for consistency. o Many small edits throughout in the description comments.