Describing SSA services as a VO resourcePart 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 SchemasTwo working draft versions are currently available.
SSA Extension metadataHere is a list of the extension metadata that can be included in an SSA schema:
testQuery item above.
Representing v1.0 and pre-1.0 implementationsOne 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 capabilityxsi: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 proposalVOResource 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
|
Describing SSA services as a VO resourcePart 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 SchemasTwo working draft versions are currently available.
| |||||||||
Changed: | |||||||||
< < |
| ||||||||
> > |
| ||||||||
Added: | |||||||||
> > |
| ||||||||
SSA Extension metadataHere is a list of the extension metadata that can be included in an SSA schema:
testQuery item above.
Representing v1.0 and pre-1.0 implementationsOne 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 capabilityxsi: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 proposalVOResource 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 <--
|
Describing SSA services as a VO resourcePart 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 SchemasTwo working draft versions are currently available.
SSA Extension metadataHere is a list of the extension metadata that can be included in an SSA schema:
testQuery item above.
Representing v1.0 and pre-1.0 implementationsOne 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 capabilityxsi: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 proposalVOResource 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 <--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
|
Describing SSA services as a VO resourcePart 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 SchemasTwo working draft versions are currently available. | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
SSA Extension metadataHere is a list of the extension metadata that can be included in an SSA schema:
testQuery item above.
Representing v1.0 and pre-1.0 implementationsOne 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 capabilityxsi: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 proposalVOResource 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 <--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Describing SSA services as a VO resourcePart 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 SchemasTwo working draft versions are currently available.
SSA Extension metadataHere is a list of the extension metadata that can be included in an SSA schema:
| |||||||||
Changed: | |||||||||
< < | Allowed values are "minimal", "query", and "full". (See schema for definitions of values.) | ||||||||
> > | Allowed values are "query", "minimal", and "full": | ||||||||
Added: | |||||||||
> > |
| ||||||||
testQuery item above.
Representing v1.0 and pre-1.0 implementationsOne 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 capabilityxsi: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 proposalVOResource 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 <--
|
Describing SSA services as a VO resourcePart 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 SchemasTwo working draft versions are currently available.
| |||||||||
Added: | |||||||||
> > |
SSA Extension metadataHere is a list of the extension metadata that can be included in an SSA schema:
testQuery item above.
| ||||||||
Representing v1.0 and pre-1.0 implementationsOne 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 capabilityxsi: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 proposalVOResource 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 <--
|
Describing SSA services as a VO resourcePart 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 SchemasTwo working draft versions are currently available. | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
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 implementationsOne 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 <--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Describing SSA services as a VO resourcePart 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 SchemasTwo working draft versions are currently available. | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
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.
Representing v1.0 and pre-1.0 implementationsOne 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 <--
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Deleted: | ||||||||
< < | ||||||||
Describing SSA services as a VO resourcePart 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 SchemasTwo working draft versions are currently available. | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
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 implementationsOne 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: | ||||||||
< < | | |||||||
> > | | |||||||
...
| ||||||||
Added: | ||||||||
> > | -- RayPlante - 24 Sep 2007 | |||||||
Deleted: | ||||||||
< < | ||||||||
<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
Describing SSA services as a VO resourcePart 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 SchemasTwo working draft versions are currently available.
Representing v1.0 and pre-1.0 implementationsOne 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".) <--
|