(r5) SsaResourceSchema < IVOA

IVOA Web>SsaInterface>SsaResourceSchema (revision 5) (raw view)~~EditAttach~~

---+ Describing SSA services as a VO resource

Part of the standardization of a protocol is defining an XML schema for describing an instance of the service, primarily in a VO registry.  This is done by creating an extension of the [[http://www.ivoa.net/Documents/latest/VOResource.html][VOResource schema]].   

---++ Working Draft Schemas

Two working draft versions are currently available.  

   $ [[%ATTACHURL%/SSA-wd.xsd][SSA-wd.xsd]]: This is the version for Working Group discussion. <br /> [[%ATTACHURL%/ssavor.xml][an example]]  *Note: this version is under final internal review; barring further comments, it will be released as an external working draft schema.*

   $ [[%ATTACHURL%/SSA-v0.1.xsd][SSA-v0.1.xsd]]:  This is a working draft version for current use in the Registry.  <br /> [[%ATTACHURL%/ssa.xml][an example]]

Barring any further comments, the top schema will become SSA-v0.2.xsd and supercede the top one.  

---++ SSA Extension metadata 

Here is a list of the extension metadata that can be included in an SSA schema:

   $ =complianceLevel=: The category indicating the level to which
                        this instance complies with the SSA standard.  
                        Allowed values are "minimal", "query", and "full".  (See schema for definitions of values.)
   $ =dataSource=:                         The category specifying where the data originally 
                        came from.  Allowed values are "survey", "pointed", "custom",
                        "theory", "artificial".  (See schema for definitions of values.)
   $ =creationType=:                         The category that describes the process used to 
                        produce the dataset.  
                        Typically this describes only the processing 
                        performed by the data service, but it could 
                        describe some additional earlier processing as 
                        well, e.g., if data is partially precomputed. 
                        Allowed values are "archival", "cutout", "filtered",
                        "mosaic", "projection", "spectralExtraction", 
                        "catalogExtraction"  (See schema for definitions of values.)
   $ =maxSearchRadius=: The largest search radius, in degrees, that will be
                        accepted by the service without returning an error 
                        condition.
   $ =maxRecords=:  The hard limit on the largest number of records that 
                        the query operation will return in a single response
   $ =defaultMaxRecords=: The largest number of records that the service will
                        return when the MAXREC parameter not specified
                        in the query input.
   $ =maxAperture=: The largest aperture that can be supported upon 
                        request via the APERTURE input parameter by a 
                        service that supports the special extraction 
                        creation method.
   $ =maxFileSize=: The maximum image file size in bytes.
   $ =testQuery=:  a set of query parameters that is expected to
                        produce at least one matched record which can be
                        used to test the service.

Note that there are planned changed to VODataService, including a general test query metdatum that will supercede the =testQuery= item above.


                        

---++ Representing v1.0 and pre-1.0 implementations

One important issue we need to address is how to support the earliest
SSA implementations.  These were built well before v1.0 of the SSA
spec was completed; thus, it is unlikely that they would be compliant
at this time.  Still, several do exist, and it would be good to
recognize these as serving spectra.  

The subsection below gives a proposal for representing the pre-v1.0 services with a special version value on the interface.  However, the editor of the SSA spec voiced a preference for labelling pre-v1.0 implementations using a different capability =xsi:type=, and there were no dissents.  Thus, in the new schema above, there is a second capability type (defined identically to the first one) called ="ProtoSpectralAccess"= (as oppsed to ="SimpleSpectralAccess"=).  

---+++ Previous version proposal

VOResource v1.0 allows one to list in one resource description support
for different versions of a protocol.  For SSA, this means that within
the "SimpleSpectralAccess" capability element, multiple interface
elements may be listed, each with a different value for its version
attribute.  (If version is not provided, "1.0" is to be assumed.)  

I recommend that we encourage the registration of the early SSA services using the "SimpleSpectralAccess" capability but to set the value of the interface element to "proto".  That is,

<verbatim>
   <ri:Resource ...>
      ...
      <capability xsi:type="ssa:SimpleSpectralAccess">
         <interface xsi:type="vs:ParamHTTP" version="proto">
            <accessURL> ... </accessURL>
         </interface>
         ...
      <capability>
      ...
   </ri:Resource>
</verbatim>

(If you don't "proto" as a version string, please suggest an
alternative, e.g "0.5".)

-- IVOA.RayPlante - 24 Sep 2007








<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->

Attachments

Topic attachments
I	Attachment	History	Action	Size	Date	Who
xsd	SSA-v0.1.xsd	r1	manage	20.3 K	2007-09-24 - 15:05	RayPlante
xsd	SSA-wd.xsd	r2 r1	manage	27.5 K	2008-01-30 - 10:28	RayPlante
xml	ssa.xml	r2 r1	manage	8.7 K	2008-01-30 - 10:37	RayPlante
xml	ssavor.xml	r1	manage	7.4 K	2007-09-27 - 09:40	RayPlante

Topic revision: r5 - 2008-01-30 - RayPlante

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema