Difference: SsaResourceSchema (1 vs. 10)

Revision 102012-06-26 - root

 
META TOPICPARENT name="SsaInterface"

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 VOResource schema.

Working Draft Schemas

Two working draft versions are currently available.

SSA-wd.xsd: This is the version for Working Group discussion.
an example

Note

this version is under final internal review; barring further comments, it will be released as an external working draft schema.

Recent changes:

  • add clone of SimpleSpectralAccess capability type called ProtoSpectralAccess
  • lots of clarified documentation
  • removed complianceLevel, defaultMaxRecords, maxAperture from ProtoSpectralAccess
  • reinstated supportedFrame element
  • fixed typo in value for creationType: specialExtraction -> spectralExtraction
  • maxFileSize: required units changed from bytes to kilobytes for consistency with SSA interface

SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
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 "query", "minimal", and "full":

query
The service supports all of the capabilities and features of the SSA protocol identified as "must" in the specification, except that it does not support returning data in at least one SSA-compliant format.

This level represents the lowest level of compliance.

minimal
The service supports all of the capabilities and features of the SSA protocol identified as "must" in the specification.

This level represents the middle level of compliance.

full
The service supports all of the capabilities and features of the SSA protocol identified as "must" or "should" in the specification.

This level represents the highest level of compliance.

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,

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

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

-- RayPlante - 24 Sep 2007


META FILEATTACHMENT attr="" comment="" date="1190646303" name="SSA-v0.1.xsd" path="SSA-v0.1.xsd" size="20811" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="Revised SSA resource schema (v0.4)" date="1204074445" name="SSA-wd.xsd" path="SSA-wd.xsd" size="30809" user="DougTody" version="1.4"
META FILEATTACHMENT attr="" comment="" date="1201711273" name="ssavor.xml" path="ssavor.xml" size="8869" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="undid previous change made by mistake" date="1201711019" name="ssa.xml" path="ssa.xml" size="5989" user="RayPlante" version="1.5"

Revision 92008-02-28 - RayPlante

 
META TOPICPARENT name="SsaInterface"

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 VOResource schema.

Working Draft Schemas

Two working draft versions are currently available.

SSA-wd.xsd: This is the version for Working Group discussion.
an example

Note

this version is under final internal review; barring further comments, it will be released as an external working draft schema.

Recent changes:

  • add clone of SimpleSpectralAccess capability type called ProtoSpectralAccess
Changed:
<
<
    • clarified documentation for complianceLevel
    • removed complianceLevel from ProtoSpectralAccess
>
>
    • lots of clarified documentation
    • removed complianceLevel, defaultMaxRecords, maxAperture from ProtoSpectralAccess
Added:
>
>
    • reinstated supportedFrame element
    • fixed typo in value for creationType: specialExtraction -> spectralExtraction
    • maxFileSize: required units changed from bytes to kilobytes for consistency with SSA interface

 
SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
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 "query", "minimal", and "full":

query
The service supports all of the capabilities and features of the SSA protocol identified as "must" in the specification, except that it does not support returning data in at least one SSA-compliant format.

This level represents the lowest level of compliance.

minimal
The service supports all of the capabilities and features of the SSA protocol identified as "must" in the specification.

This level represents the middle level of compliance.

full
The service supports all of the capabilities and features of the SSA protocol identified as "must" or "should" in the specification.

This level represents the highest level of compliance.

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,

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

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

-- RayPlante - 24 Sep 2007


<--  
-->

META FILEATTACHMENT attr="" comment="" date="1190646303" name="SSA-v0.1.xsd" path="SSA-v0.1.xsd" size="20811" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="Revised SSA resource schema (v0.4)" date="1204074445" name="SSA-wd.xsd" path="SSA-wd.xsd" size="30809" user="DougTody" version="1.4"
META FILEATTACHMENT attr="" comment="" date="1201711273" name="ssavor.xml" path="ssavor.xml" size="8869" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="undid previous change made by mistake" date="1201711019" name="ssa.xml" path="ssa.xml" size="5989" user="RayPlante" version="1.5"

Revision 82008-02-27 - DougTody

 
META TOPICPARENT name="SsaInterface"

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 VOResource schema.

Working Draft Schemas

Two working draft versions are currently available.

SSA-wd.xsd: This is the version for Working Group discussion.
an example

Note

this version is under final internal review; barring further comments, it will be released as an external working draft schema.

Recent changes:

  • add clone of SimpleSpectralAccess capability type called ProtoSpectralAccess
  • clarified documentation for complianceLevel
  • removed complianceLevel from ProtoSpectralAccess

SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
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 "query", "minimal", and "full":

query
The service supports all of the capabilities and features of the SSA protocol identified as "must" in the specification, except that it does not support returning data in at least one SSA-compliant format.

This level represents the lowest level of compliance.

minimal
The service supports all of the capabilities and features of the SSA protocol identified as "must" in the specification.

This level represents the middle level of compliance.

full
The service supports all of the capabilities and features of the SSA protocol identified as "must" or "should" in the specification.

This level represents the highest level of compliance.

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,

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

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

-- RayPlante - 24 Sep 2007


<--  
-->

META FILEATTACHMENT attr="" comment="" date="1190646303" name="SSA-v0.1.xsd" path="SSA-v0.1.xsd" size="20811" user="RayPlante" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="" comment="" date="1201711358" name="SSA-wd.xsd" path="SSA-wd.xsd" size="28391" user="RayPlante" version="1.3"
>
>
META FILEATTACHMENT attr="" comment="Revised SSA resource schema (v0.4)" date="1204074445" name="SSA-wd.xsd" path="SSA-wd.xsd" size="30809" user="DougTody" version="1.4"
 
META FILEATTACHMENT attr="" comment="" date="1201711273" name="ssavor.xml" path="ssavor.xml" size="8869" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="undid previous change made by mistake" date="1201711019" name="ssa.xml" path="ssa.xml" size="5989" user="RayPlante" version="1.5"

Revision 72008-01-30 - RayPlante

 
META TOPICPARENT name="SsaInterface"

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 VOResource schema.

Working Draft Schemas

Two working draft versions are currently available.

Changed:
<
<
SSA-wd.xsd: This is the version for Working Group discussion.
an example Note
this version is under final internal review; barring further comments, it will be released as an external working draft schema.
>
>
SSA-wd.xsd: This is the version for Working Group discussion.
an example

Note

this version is under final internal review; barring further comments, it will be released as an external working draft schema.

Recent changes:

Added:
>
>
    • add clone of SimpleSpectralAccess capability type called ProtoSpectralAccess
    • clarified documentation for complianceLevel
    • removed complianceLevel from ProtoSpectralAccess
 
SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
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 "query", "minimal", and "full":

query
The service supports all of the capabilities and features of the SSA protocol identified as "must" in the specification, except that it does not support returning data in at least one SSA-compliant format.

This level represents the lowest level of compliance.

minimal
The service supports all of the capabilities and features of the SSA protocol identified as "must" in the specification.

This level represents the middle level of compliance.

full
The service supports all of the capabilities and features of the SSA protocol identified as "must" or "should" in the specification.

This level represents the highest level of compliance.

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,

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

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

-- RayPlante - 24 Sep 2007


<--  
-->

META FILEATTACHMENT attr="" comment="" date="1190646303" name="SSA-v0.1.xsd" path="SSA-v0.1.xsd" size="20811" user="RayPlante" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="" comment="" date="1201688922" name="SSA-wd.xsd" path="SSA-wd.xsd" size="28202" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="" date="1190886038" name="ssavor.xml" path="ssavor.xml" size="7586" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1201689436" name="ssa.xml" path="ssa.xml" size="8916" user="RayPlante" version="1.2"
>
>
META FILEATTACHMENT attr="" comment="" date="1201711358" name="SSA-wd.xsd" path="SSA-wd.xsd" size="28391" user="RayPlante" version="1.3"
META FILEATTACHMENT attr="" comment="" date="1201711273" name="ssavor.xml" path="ssavor.xml" size="8869" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="undid previous change made by mistake" date="1201711019" name="ssa.xml" path="ssa.xml" size="5989" user="RayPlante" version="1.5"
 

Revision 62008-01-30 - RayPlante

 
META TOPICPARENT name="SsaInterface"

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 VOResource schema.

Working Draft Schemas

Two working draft versions are currently available.

SSA-wd.xsd: This is the version for Working Group discussion.
an example Note
this version is under final internal review; barring further comments, it will be released as an external working draft schema.

SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
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.
Changed:
<
<
Allowed values are "minimal", "query", and "full". (See schema for definitions of values.)
>
>
Allowed values are "query", "minimal", and "full":

Added:
>
>
query
The service supports all of the capabilities and features of the SSA protocol identified as "must" in the specification, except that it does not support returning data in at least one SSA-compliant format.

This level represents the lowest level of compliance.

minimal
The service supports all of the capabilities and features of the SSA protocol identified as "must" in the specification.

This level represents the middle level of compliance.

full
The service supports all of the capabilities and features of the SSA protocol identified as "must" or "should" in the specification.

This level represents the highest level of compliance.

 
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,

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

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

-- RayPlante - 24 Sep 2007


<--  
-->

META FILEATTACHMENT attr="" comment="" date="1190646303" name="SSA-v0.1.xsd" path="SSA-v0.1.xsd" size="20811" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1201688922" name="SSA-wd.xsd" path="SSA-wd.xsd" size="28202" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="" date="1190886038" name="ssavor.xml" path="ssavor.xml" size="7586" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1201689436" name="ssa.xml" path="ssa.xml" size="8916" user="RayPlante" version="1.2"

Revision 52008-01-30 - RayPlante

 
META TOPICPARENT name="SsaInterface"

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 VOResource schema.

Working Draft Schemas

Two working draft versions are currently available.

SSA-wd.xsd: This is the version for Working Group discussion.
an example Note
this version is under final internal review; barring further comments, it will be released as an external working draft schema.

SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
an example

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

Added:
>
>

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,

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

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

-- RayPlante - 24 Sep 2007


<--  
-->

META FILEATTACHMENT attr="" comment="" date="1190646303" name="SSA-v0.1.xsd" path="SSA-v0.1.xsd" size="20811" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1201688922" name="SSA-wd.xsd" path="SSA-wd.xsd" size="28202" user="RayPlante" version="1.2"
META FILEATTACHMENT attr="" comment="" date="1190886038" name="ssavor.xml" path="ssavor.xml" size="7586" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1201689436" name="ssa.xml" path="ssa.xml" size="8916" user="RayPlante" version="1.2"

Revision 42008-01-30 - RayPlante

 
META TOPICPARENT name="SsaInterface"

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 VOResource schema.

Working Draft Schemas

Two working draft versions are currently available.

Changed:
<
<
SSA-wd.xsd
This is the version for Working Group discussion.
an example
>
>
SSA-wd.xsd: This is the version for Working Group discussion.
an example Note
this version is under final internal review; barring further comments, it will be released as an external working draft schema.
 
SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
an example
Changed:
<
<
The reason for two versions is that there are several issues regarding details of the schema represented in SSA-wd.xsd that still need to be discussed and worked out. However, there is demand to represent current SSA implementations in the registry ASAP; thus, SSA-v0.1.xsd represents an interim schema that is to be adopted right away. WG approval of this interim schema will be sought at the Fall 2007 Interop in Cambridge.
>
>
Barring any further comments, the top schema will become SSA-v0.2.xsd and supercede the top one.
 

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.

Added:
>
>
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,

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

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

-- RayPlante - 24 Sep 2007


<--  
-->

META FILEATTACHMENT attr="" comment="" date="1190646303" name="SSA-v0.1.xsd" path="SSA-v0.1.xsd" size="20811" user="RayPlante" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="" comment="" date="1190646377" name="SSA-wd.xsd" path="SSA-wd.xsd" size="25739" user="RayPlante" version="1.1"
>
>
META FILEATTACHMENT attr="" comment="" date="1201688922" name="SSA-wd.xsd" path="SSA-wd.xsd" size="28202" user="RayPlante" version="1.2"
 
META FILEATTACHMENT attr="" comment="" date="1190886038" name="ssavor.xml" path="ssavor.xml" size="7586" user="RayPlante" version="1.1"
Changed:
<
<
META FILEATTACHMENT attr="" comment="" date="1190886085" name="ssa.xml" path="ssa.xml" size="5989" user="RayPlante" version="1.1"
>
>
META FILEATTACHMENT attr="" comment="" date="1201689436" name="ssa.xml" path="ssa.xml" size="8916" user="RayPlante" version="1.2"
 

Revision 32007-09-27 - RayPlante

 
META TOPICPARENT name="SsaInterface"

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 VOResource schema.

Working Draft Schemas

Two working draft versions are currently available.

Changed:
<
<
SSA-wd.xsd
This is the version for Working Group discussion.
>
>
SSA-wd.xsd
This is the version for Working Group discussion.
an example
 
Changed:
<
<
SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
>
>
SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
an example
  The reason for two versions is that there are several issues regarding details of the schema represented in SSA-wd.xsd that still need to be discussed and worked out. However, there is demand to represent current SSA implementations in the registry ASAP; thus, SSA-v0.1.xsd represents an interim schema that is to be adopted right away. WG approval of this interim schema will be sought at the Fall 2007 Interop in Cambridge.

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.

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,

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

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

-- RayPlante - 24 Sep 2007


<--  
-->

META FILEATTACHMENT attr="" comment="" date="1190646303" name="SSA-v0.1.xsd" path="SSA-v0.1.xsd" size="20811" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1190646377" name="SSA-wd.xsd" path="SSA-wd.xsd" size="25739" user="RayPlante" version="1.1"
Added:
>
>
META FILEATTACHMENT attr="" comment="" date="1190886038" name="ssavor.xml" path="ssavor.xml" size="7586" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1190886085" name="ssa.xml" path="ssa.xml" size="5989" user="RayPlante" version="1.1"
 

Revision 22007-09-24 - RayPlante

 
META TOPICPARENT name="SsaInterface"
Deleted:
<
<
 

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 VOResource schema.

Working Draft Schemas

Two working draft versions are currently available.

Changed:
<
<
SSA-wd.xsd
This is the version for Working Group discussion.
>
>
SSA-wd.xsd
This is the version for Working Group discussion.
 
Changed:
<
<
SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
>
>
SSA-v0.1.xsd
This is a working draft version for current use in the Registry.
 
Changed:
<
<
The reason for two versions is that there are several issues regarding details of the schema represented in SSA-wd.xsd that still need to be discussed and worked out. However, there is demand to represent current SSA implementations in the registry ASAP; thus, SSA-v0.1.xsd represents an interim schema that is to be adopted right away. WG approval of this interim schema will be sought at the Fall 2007 Interop in Cambridge.
>
>
The reason for two versions is that there are several issues regarding details of the schema represented in SSA-wd.xsd that still need to be discussed and worked out. However, there is demand to represent current SSA implementations in the registry ASAP; thus, SSA-v0.1.xsd represents an interim schema that is to be adopted right away. WG approval of this interim schema will be sought at the Fall 2007 Interop in Cambridge.
 

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.

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

Changed:
<
<
attribute. (If version is not provided, "1.0" is to be assumed.) I
>
>
attribute. (If version is not provided, "1.0" is to be assumed.)
Deleted:
<
<
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,
 
Added:
>
>
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,
 
   <ri:Resource ...>
      ...
      <capability xsi:type="ssa:SimpleSpectralAccess">
         <interface xsi:type="vs:ParamHTTP" version="proto">
Changed:
<
<
... </accessURL>
>
>
...
  ... ...

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

Added:
>
>
-- RayPlante - 24 Sep 2007
 

Deleted:
<
<
 
<--  
-->
Added:
>
>
META FILEATTACHMENT attr="" comment="" date="1190646303" name="SSA-v0.1.xsd" path="SSA-v0.1.xsd" size="20811" user="RayPlante" version="1.1"
META FILEATTACHMENT attr="" comment="" date="1190646377" name="SSA-wd.xsd" path="SSA-wd.xsd" size="25739" user="RayPlante" version="1.1"
 

Revision 12007-09-24 - RayPlante

 
META TOPICPARENT name="SsaInterface"

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 VOResource schema.

Working Draft Schemas

Two working draft versions are currently available.

SSA-wd.xsd
This is the version for Working Group discussion.

SSA-v0.1.xsd
This is a working draft version for current use in the Registry.

The reason for two versions is that there are several issues regarding details of the schema represented in SSA-wd.xsd that still need to be discussed and worked out. However, there is demand to represent current SSA implementations in the registry ASAP; thus, SSA-v0.1.xsd represents an interim schema that is to be adopted right away. WG approval of this interim schema will be sought at the Fall 2007 Interop in Cambridge.

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.

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,

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

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


<--  
-->
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback