This is an IVOA Working Draft for review by IVOA members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use IVOA Working Drafts as reference materials or to cite them as other than "works in progress".
Early versions of this document were known as RegSimpleDAL. The short name is now SimpleDALRegExt.
A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.
This document has been developed with support from the National Science Foundation's Information Technology Research Program under Cooperative Agreement AST0122449 with The Johns Hopkins University, from the UK Particle Physics and Astronomy Research Council (PPARC), and from the Eurpean Commission's Sixth Framework Program via the Optical Infrared Coordination Network (OPTICON).
The Virtual Observatory (VO) is general term for a collection of federated resources that can be used to conduct astronomical research, education, and outreach. The International Virtual Observatory Alliance (IVOA) is a global collaboration of separately funded projects to develop standards and infrastructure that enable VO applications.
XML document validation is a software process that checks that an XML document is not only well-formed XML but also conforms to the syntax rules defined by the applicable schema. Typically, when the schema is defined by one or more XML Schema [schema] documents (see next section), validation refers to checking for conformance to the syntax described in those Schema documents. This document describes additional syntax constraints that cannot be enforced solely by the rules of XML Schema; thus, in this document, use of the term validation includes the extra checks that goes beyond common Schema-aware parsers which ensure conformance with this document.
The eXtensible Markup Language, or XML, is document syntax for marking textual information with named tags and is defined by the World Wide Web Consortium (W3C) Recommendation, XML 1.0 [XML]. The set of XML tag names and the syntax rules for their use is referred to as the document schema. One way to formally define a schema for XML documents is using the W3C standard known as XML Schema [schema].
This document defines the VOResource schema using XML Schema. The full Schema document is listed in Appendix A. Parts of the schema appear within the main sections of this document; however, documentation nodes have been left out for the sake of brevity.
Reference to specific elements and types defined in the VOResource
schema include the namespaces prefix, vr
, as in
vr:Resource
(a type defined in the VOResource schema).
Reference to specific elements and types defined in the VODataService
extension schema include the namespaces prefix, vs
, as in
vs:ParamHTTP
(a type defined in the VODataService schema).
Use of the vs
prefix in compliant instance documents is
strongly recommended, particularly in the applications that involve
IVOA Registries (see [RI], section 3.1.2).
Elsewhere, the use is not required.
Four data access service protocols play a key role in discovering data in the VO:
They are called "simple" because a typical query can be formed using only a few search parameters encoded into a URL (i.e. an HTTP GET request). Their power for data discovery comes from the ability of an application to form a single query according to the rules of one of these protocols and send it to all known services which support that protocol. The results collected from all those services, in effect then, represent all matching data of that type known to the VO. Thus, the key for an application wishing to do a comprehensive search of the VO is to discover all of the services that support the particular standard protocol.
Service discovery in the VO is done via a searchable registry [RI]--i.e., a searchable repository of descriptions of resources in VO. These descriptions are comprised of common standard metadata [RM] that capture information about what a resource contains or does and who provides it. A standard registry encodes these descriptions using the VOResource XML Schema [VOR]. Service resources in particular include capability metadata that describe the functionality it supports along with interface metadata that describe how to access that functionality. It is within the capability metadata that it is possible to indicate support for a particular standard protocol.
Capability metadata play an important role beyond just identifying support for a standard interface. More generally, they describe how the service behaves, and if applications are to make use of this information in an automated way, the behavior must be described using standardized metadata. In general, the metadata necessary for describing that behavior will be specific to the particular kind of service. In the case of a standard protocol, in which it is common that some variation in behavior is allowed while still being in compliance, it can be important to an application to know how a service complies with the standard for two reasons:
It is important to note that the relevent behavioral differences between separate services that support a common protocol--and thus the metadata used to describe those behaviors--will be specific to that protocol. That is, the ability to create image cut-outs is irrelevent to the Simple Cone Search protocol. Consequently, it is necessary to define protocol-specific metadata to adequately describe a service's support for that protocol. This document defines such capability metadata for SCS, SIA, SSA, and SLA.
This document describes, for each of the standard data access protocols--SCS, SIA, SSA, and SLA--precisely how to describe a service that supports one of the protocol using the VOResource XML encoding standard [VOR]. This specification is intended to be applicable whereever VOResource records are used, but in particular, it is intended as the standard for encoding resource descriptions within an IVOA-compliant registry [RI] and for encoding capability metadata available through the VO Standard Interface [VOSI].
The IVOA Architecture [Arch] provides a high-level view of how IVOA standards work together to connect users and applications with providers of data and services, as depicted in the diagram in Fig. 1.
Figure 1. SimpleDALExt in the IVOA Architecture. The Registry enables applications in the User Layer to discover archives in the Resource Layer and the services they provide for accessing data, particularly those that support the standard data access protocols like SIAP, SCS, SSAP, and SLAP (illustrated on the right). The registry metadata model standards (in blue text and boxes on the left) give structure to the information that enables that discovery. In particular, the SimpleDALExt standard defines the metadata used to describe standard data access services of the types listed on the right.
In this architecture, data access protocols provide the means for users (via the User Layer) to access data from archives. Of particular importance are the standard protocols, SCS, SIA, SSA, and SLA, which allow a generic user tool to find data in any archive that supports those protocols. Registries provide to tools in the User Layer a means to discover which archives support the standard protocols. A registry is a repository of descriptions of resources, such as standard services, that can be searched based on the metadata in those descriptions.
Resource descriptions have a well-defined structure: the core concepts are defined in the Resource Metadata standard [RM], and the format is defined by the VOResource XML standard [VOR]. Additional metadata specialized to describe a specific kind of service are defined via extensions to the VOResource core XML Schema. SimpleDALExt is one such extension specifically for describing SCS, SIA, SSA, and SLA services in the registry.
vs:ParamHTTP
, which is defined in the
VODataService XML Schema, an extension to VOResource. This
document also recommends describing the service using
VODataService resource type,
vs:CatalogDataService
.
Except where noted in subsequent sections, this specification does not imply support for any other versions (including later versions) than the ones noted above.
This specification refers to other IVOA standards:
Unlike with the previously mentioned specifications, this specification may apply to later versions of the RI and VOSI standards.
This section describes common requirements for describing the target DAL services as VOResource records.
To be recognized as a service, the DAL service resource must be
described as a resource type of vr:Service
(defined in
the VOResource schema [VOR]) or one of its legal
sub-types. As specified in the VOResource specification
[VOR], the resource type is set by setting the
xsi:type
attribute on the element representing the root
of the VOResource record to the namespace-qualified resource type
name. As the DAL services respond to queries with tables of available
data products, the resource should set the resource type to
vs:CatalogService
(defined in the VODataService extension
schema [VDS]. In this case, record authors are
encouraged to include a full description of the columns in the table
returned in query response (assuming full verbosity). The
vs:CatalogService
resource type also allows the record to
provide sky coverage information which authors are also encouraged to
provide; an exception to this would be for pure SLA services as the
spectral line catalogs they serve are not strictly sky observations.
- Note:
- In the future, a more appropriate resource type may be defined for describing DAL services; thus, the loose requirement on the resource type allows for this. At the time of this writing, the
vs:CatalogService
is recommended as the most appropriate type and represents current practice with IVOA registries.
The VOResource record must include a <capability>
element that describes the services support for the DAL protocol. The
contents of the element is described in the next
section. In all cases, the value of the
<capability>
element's standardID
unambiguosly identifies the service's support for the particular DAL
protocol. The resource may include other
<capability>
elements to describe support for other
protocols.
The <capability>
element describing support for the
DAL protocol must include a child <interface>
element that describes support for the required DAL interface; the
xsi:type
attribute on that element must be set to
vs:ParamHTTP
, and the role
attribute must be
set to "std". A <accessURL>
element within that
<interface>
must be set to the base URL, as defined
in the DAL protocol specification, that provides access to the standard
DAL protocol. It is not necessary to provide the use
attribute to the <accessURL>
element (as its value
can be assumed); however, when it is provided, it must be set to
"base". Similarly, it is not necessary to provide the
<interface>
element with
<queryType>
or <resultType>
elements; however, when provided, their values should be "GET" and
"application/x-votable+xml", respectively. The
vs:ParamHTTP
allows one to describe input parameters
supported by the service; description authors are encouraged to list
the optional parameters and any custom parameters supported by the
instance of the service.
<interface xsi:type="vs:ParamHTTP" role="std"> <accessURL use="base"> http://adil.ncsa.uiuc.edu/cgi-bin/voimquery?survey=f& </accessURL> <!-- here is a standard, optional parameter --> <param use="optional" std="true"> <name>CFRAME</name> <description>request to shift to a given coordinate frame.</description> <dataType>string</dataType> </param> <!-- here is a site-specific parameter that this service supports --> <param use="optional" std="false"> <name>FREQ</name> <description>Frequency of observation.</description> <unit>Hz</unit> <dataType>real</dataType> </param> </interface>
This section describes the specific VOResource metadata extension
schemas used to describe support for the target DAL protocols. The
purpose of these schemas are to provide the vr:Capability
sub-type that identifies the specific protocol. These are defined
employing the recommendations for vr:Capability
extensions given in the VOResource standard [VR].
In particular, each extension schema have the following features:
xsi:schemaLocation
attribute.
- Note:
- The IVOA Registry Interface standard [RI] actually requires that the VOResource records it shares with other registries provide location URLs via
xsi:schemaLocation
for the VOResource schema and all legal extension schemas that are used in the records. This rule would apply to the extension schemas defined in this standard.
vr:Capability
sub-type
defined in the schema. Generally instance documents may use
any prefix; however, in applications where common and
consistent use of prefixes is recommended (such as with the
Registry Interface specification [RI], use of
the prefixes recommended in this document can be used.
elementFormDefault="unqualified"
.
This means that it is not necessary to qualify element names
defined in the schema with a namespace prefix (as there are no
global elements defined). The only place it is usually needed
is as a qualifier to a Capability
sub-type name
given as the value of an xsi:type
attribute on the
<capability>
element (see the examples in the
subsections below). vr:Capability
sub-type fixes the value its standardID
attribute
to the URI that is intended to uniquely identify the standard
DAL protocol whose support the type describes. vr:Capability
sub-type includes a
<testQuery>
element for encoding parameters
that together can be used to test the service. The format for
encoding the individual parameters is customized for each of
the four simple services covered in this specification.
- Note:
- It is also possible to encode test queries as part of the
vs:ParamHTTP
interface via its<testQuery>
element [VDS]; this query is encoded as a single string that can be appended to the service's base URL. This specification does not recommend one over the other. Use of thevr:Capability
-based<testQuery>
pre-dates thevs:ParamHTTP
-based one and has been kept for backward-compatibility purposes. It might be easier for some clients to use since each parameter is individually tagged and perhaps easier to parse, manipulate, and enter automatically into an interface. Thevs:ParamHTTP
-based one has an advantage in that it can be applied to any REST-like service, standard or not.
This section describes the ConeSearch VOResource metadata extension schema which is used to describe services that comply with the Simple Cone Search protocol [SCS].
The namespace associated with the ConeSearch extension schema is
"http://www.ivoa.net/xml/ConeSearch/1.0". The namespace prefix,
cs
, should be used in applications where common use of
prefixes improves interoperability (e.g. in the IVOA registries
[RI]). Furthermore, we use the cs
prefix in this document to refer to types defined as part of the
ConeSearch extension schema.
The cs:ConeSearch
type is vr:Capability
sub-type that should be used to describe a service's support for the
Simple Cone Search protocol [SCS]; it is defined
as follows:
CSCapRestriction
is to fix the value of
standardID
.) <xs:complexType name="CSCapRestriction" abstract="true" > <xs:complexContent > <xs:restriction base="vr:Capability" > <xs:sequence > <xs:element name="validationLevel" type="vr:Validation" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="description" type="xs:token" minOccurs="0" /> <xs:element name="interface" type="vr:Interface" minOccurs="0" maxOccurs="unbounded" /> </sequence> <xs:attribute name="standardID" type="vr:IdentifierURI" use="required" fixed="ivo://ivoa.net/std/ConeSearch" /> </restriction> </complexContent> </complexType> <xs:complexType name="ConeSearch" > <xs:complexContent > <xs:extension base="cs:CSCapRestriction" > <xs:sequence > <xs:element name="maxSR" type="xs:float" /> <xs:element name="maxRecords" type="xs:int" /> <xs:element name="verbosity" type="xs:boolean" /> <xs:element name="testQuery" type="cs:Query" /> </sequence> </extension> </complexContent> </complexType>
The cs:CSCapRestriction
is defined to fix the value of
the standardID
attribute; thus, all uses of the
cs:ConeSearch
type must set standardID
to
"ivo://ivoa.net/std/ConeSearch". Because the
cs:CSCapRestriction
is marked as abstract, instance
documents can not use it directly as a value for the
xsi:type
attribute.
The custom metadata that the sia:ConeSearch
type
provides is given in the table below. For the elements whose semantics
map directly to service profile metadata called for in the SCS standard [SCS, section 3], there is an entry labeled "SCS
Name"; this indicates the metadata name given in the SCS specification
that the element in this schema corresponds to. The profile metadata
listed in the SCS specification that is not covered by the elements
below are covered by other metadata that are part of the core
VOResource schema.
cs:ConeSearch Extension Metadata Elements | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Element | Definition | ||||||||||
maxSR |
| ||||||||||
maxRecords |
| ||||||||||
verbosity |
| ||||||||||
testQuery |
|
The <testQuery>
element is intended to help other VO
components (e.g. registries, validation services, services that
monitor the VO's operational health--but typically not end users) test
that the service is up and operating correctly. It provides a set of
legal input parameters that should return a legal response that
includes at least matched record. Since this query is intended for
testing purposes, the size of the result set should be small.
The cs:Query
type captures the different components of
the query into separate elements, as defined below:
<xs:complexType name="Query" > <xs:sequence > <xs:element name="ra" type="xs:double" /> <xs:element name="dec" type="xs:double" /> <xs:element name="sr" type="xs:double" /> <xs:element name="verb" type="xs:positiveInteger" minOccurs="0" /> <xs:element name="catalog" type="xs:string" minOccurs="0" /> <xs:element name="extras" type="xs:string" minOccurs="0" /> </sequence> </complexType>
The individual sub-elements are defined as follows:
cs:Query Metadata Elements | |||||||||
---|---|---|---|---|---|---|---|---|---|
Element | Definition | ||||||||
ra |
| ||||||||
dec |
| ||||||||
sr |
| ||||||||
verb |
| ||||||||
catalog |
| ||||||||
extras |
|
This section describes the SIA VOResource metadata extension schema which is used to describe services that comply with the Simple Image Access protocol [SIA].
The namespace associated with the SIA extension schema is
"http://www.ivoa.net/xml/SIA/1.0". The namespace prefix,
sia
, should be used in applications where common use of
prefixes improves interoperability (e.g. in the IVOA registries
[RI]). Furthermore, we use the sia
prefix in this document to refer to types defined as part of the
SIA extension schema.
The sia:SimpleImageAccess
type is a vr:Capability
sub-type that should be used to describe a service's support for the
Simple Image Access protocol [SIA]; it is defined
as follows:
SIACapRestriction
is to fix the value of
standardID
.) <xs:complexType name="SIACapRestriction" abstract="true" > <xs:complexContent > <xs:restriction base="vr:Capability" > <xs:sequence > <xs:element name="validationLevel" type="vr:Validation" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="description" type="xs:token" minOccurs="0" /> <xs:element name="interface" type="vr:Interface" minOccurs="0" maxOccurs="unbounded" /> </sequence> <xs:attribute name="standardID" type="vr:IdentifierURI" use="required" fixed="ivo://ivoa.net/std/SIA" /> </restriction> </complexContent> </complexType> <xs:complexType name="SimpleImageAccess" > <xs:complexContent > <xs:extension base="sia:SIACapRestriction" > <xs:sequence > <xs:element name="imageServiceType" type="sia:ImageServiceType" /> <xs:element name="maxQueryRegionSize" type="sia:SkySize" /> <xs:element name="maxImageExtent" type="sia:SkySize" /> <xs:element name="maxImageSize" type="sia:ImageSize" /> <xs:element name="maxFileSize" type="xs:int" /> <xs:element name="maxRecords" type="xs:int" /> <xs:element name="testQuery" type="sia:Query" minOccurs="0" maxOccurs="1" /> </sequence> </extension> </complexContent> </complexType>
The sia:SIACapRestriction
is defined to fix the value of
the standardID
attribute; thus, all uses of the
sia:SimpleImageAccess
type must set standardID
to
"ivo://ivoa.net/std/SIA". Because the
cs:SIACapRestriction
is marked as abstract, instance
documents can not use it directly as a value for the
xsi:type
attribute.
The custom metadata that the sia:SimpleImageAccess
type
provides is given in the table below. For the elements whose semantics
map directly to metadata called for in the SIA standard [SIA, section 7], there is an entry labeled "SIA
Name"; this indicates the metadata name given in the SIA specification
that the element in this schema corresponds to.
sia:SimpleImageAccess Extension Metadata Elements | |||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Element | Definition | ||||||||||||||||||||||
imageServiceType |
| ||||||||||||||||||||||
maxQueryRegionSize |
| ||||||||||||||||||||||
maxImageExtent |
| ||||||||||||||||||||||
maxImageSize |
| ||||||||||||||||||||||
maxFileSize |
| ||||||||||||||||||||||
maxRecords |
| ||||||||||||||||||||||
testQuery |
|
The sia:ImageServiceType
type is provided to restrict the
values of the <imageServiceType>
element to those
allowed by the SIA standard:
<xs:simpleType name="ImageServiceType" > <xs:restriction base="xs:string" > <xs:enumeration value="Cutout" /> <xs:enumeration value="Mosaic" /> <xs:enumeration value="Atlas" /> <xs:enumeration value="Pointed" /> </restriction> </simpleType>
- Note:
- The SIA specification defines the image service types as follows:
- Image Cutout Service
- This is a service which extracts or "cuts out" rectangular regions of some larger image, returning an image of the requested size to the client. Such images are usually drawn from a database or a collection of survey images that cover some large portion of the sky. To be considered a cutout service, the returned image should closely approximate (or at least not exceed) the size of the requested region; however, a cutout service will not normally resample (rescale or reproject) the pixel data. A cutout service may mosaic image segments to cover a large region but is still considered a cutout service if it does not resample the data. Image cutout services are fast and avoid image degredation due to resampling.
- Image Mosaicing Service
- This service is similar to the image cutout service but adds the capability to compute an image of the size, scale, and projection specified by the client. Mosaic services include services which resample and reproject existing image data, as well as services which generate pixels from some more fundamental dataset, e.g., a high energy event list or a radio astronomy measurement set. Image mosaics can be expensive to generate for large regions but they make it easier for the client to overlay image data from different sources. Image mosaicing services which resample already pixelated data will degrade the data slightly, unlike the simpler cutout service which returns the data unchanged.
- Atlas Image Archive
- This category of service provides access to pre-computed images that make up a survey of some large portion of the sky. The service, however, is not capable of dynamically cutting out requested regions, and the size of atlas images is predetermined by the survey. Atlas images may range in size from small cutouts of extended objects to large calibrated survey data frames.
- Pointed Image Archive
- This category of service provides access to collections of images of many small, "pointed" regions of the sky. "Pointed" images normally focus on specific sources in the sky as opposed to being part of a sky survey. This type of service usually applies to instrumental archives from observatories with guest observer programs (e.g., the HST archive) and other general purpose image archives (e.g., the ADIL). If a service provides access to both survey and pointed images, then it should be considered a Pointed Image Archive for the purposes of this specification; if a differentiation between the types of data is desired the pointed and survey data collections should be registered as separate image services.
Several of the sia:SimpleImageAccess
metadata use complex
types to capture their values; the subsequent sections below define
those special types.
The sia:SkySize
type is used to capture simple
rectangular extents on the sky along longitudinal and latitudinal
directions. It is defined as follows:
<xs:complexType name="SkySize" > <xs:sequence > <xs:element name="long" type="xs:float" /> <xs:element name="lat" type="xs:float" /> </sequence> </complexType>
The coordinate system for the region is intended to be implied by the context of its use--i.e. the definition of the element defined with this type. In this SIA case, the longitudinal and latitudinal values represent the extents along right ascension and declination in the ICRS system (the system assumed by the SIA interface).
sia:SkySize Metadata Elements | |||||||
---|---|---|---|---|---|---|---|
Element | Definition | ||||||
long |
| ||||||
lat |
|
The sia:ImageSize
type is used to capture an image size
in pixel widths along the longitudinal and latitudinal directions of
the image. It is defined as follows:
<xs:complexType name="ImageSize" > <xs:sequence > <xs:element name="long" type="xs:int" /> <xs:element name="lat" type="xs:int" /> </sequence> </complexType>
The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with.
sia:ImageSize Metadata Elements | |||||||
---|---|---|---|---|---|---|---|
Element | Definition | ||||||
long |
| ||||||
lat |
|
As with the other DAL vr:capability
types, the
<testQuery>
element is intended to help other VO
components (e.g. registries, validation services, services that
monitor the VO's operational health--but typically not end users) test
that the service is up and operating correctly. It provides a set of
legal input parameters that should return a legal response that
includes at least matched record. Since this query is intended for
testing purposes, the size of the result set should be small.
The sia:Query
type captures the different components of
the query into separate elements, as defined below:
<xs:complexType name="Query" > <xs:sequence > <xs:element name="pos" type="sia:SkyPos" minOccurs="0" /> <xs:element name="size" type="sia:SkySize" minOccurs="0" /> <xs:element name="verb" type="xs:positiveInteger" minOccurs="0" /> <xs:element name="extras" type="xs:string" minOccurs="0" /> </sequence> </complexType>
The individual sub-elements are defined as follows:
sia:Query Metadata Elements | |||||||||
---|---|---|---|---|---|---|---|---|---|
Element | Definition | ||||||||
pos |
| ||||||||
size |
| ||||||||
verb |
| ||||||||
extras |
|
The sia:SkyPos
type is used to encode the
<testQuery>
's <pos>
element, the
center position of the test region of interest.
<xs:complexType name="SkyPos" > <xs:sequence > <xs:element name="long" type="xs:double" /> <xs:element name="lat" type="xs:double" /> </sequence> </complexType>
sia:SkyPos Metadata Elements | |||||||
---|---|---|---|---|---|---|---|
Element | Definition | ||||||
long |
| ||||||
lat |
|
This section describes the SSA VOResource metadata extension
schema which is used to describe services that comply with the Simple
Spectral Access protocol. This differs from the other Simple DAL
extensions in that it defines two vr:Capability
types:
ssa:SimpleSpectralAccess
and
ssa:ProtoSpectralAccess
.
The former is intended for services that are intended to be compliant
with published SSA Recommendation [SSA]. The
latter is intended for services that were deployed prior to the
publication of the SSA Recommendation (see
section 3.3.3, below).
The namespace associated with the SSA extension schema is
"http://www.ivoa.net/xml/SSA/1.0". The namespace prefix,
ssa
, should be used in applications where common use of
prefixes improves interoperability (e.g. in the IVOA registries
[RI]). Furthermore, we use the ssa
prefix in this document to refer to types defined as part of the
SSA extension schema.
The ssa:SimpleSpectralAccess
type is vr:Capability
sub-type that should be used to describe a service's support for the
Simple Spectral Access protocol [SSA]; it is defined
as follows:
<xs:complexType name="SSACapRestriction" abstract="true" > <xs:complexContent > <xs:restriction base="vr:Capability" > <xs:sequence > <xs:element name="validationLevel" type="vr:Validation" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="description" type="xs:token" minOccurs="0" /> <xs:element name="interface" type="vr:Interface" minOccurs="0" maxOccurs="unbounded" /> </sequence> <xs:attribute name="standardID" type="vr:IdentifierURI" use="required" fixed="ivo://ivoa.net/std/SSA" /> </restriction> </complexContent> </complexType> <xs:complexType name="SimpleSpectralAccess" > <xs:complexContent > <xs:extension base="ssa:SSACapRestriction" > <xs:sequence > <xs:element name="complianceLevel" type="ssa:ComplianceLevel" /> <xs:element name="dataSource" type="ssa:DataSource" minOccurs="1" maxOccurs="unbounded" /> <xs:element name="creationType" type="ssa:CreationType" minOccurs="1" maxOccurs="unbounded" /> <xs:element name="maxSearchRadius" type="xs:double" /> <xs:element name="maxRecords" type="xs:int" /> <xs:element name="defaultMaxRecords" type="xs:int" /> <xs:element name="maxAperture" type="xs:double" minOccurs="0" /> <xs:element name="maxFileSize" type="xs:int" maxOccurs="1" minOccurs="0" /> <xs:element name="testQuery" type="ssa:Query" minOccurs="0" maxOccurs="1" /> </sequence> </extension> </complexContent> </complexType>
The ssa:SSACapRestriction
is defined to fix the value of
the standardID
attribute; thus, all uses of the
ssa:SimpleSpectralAccess
type must set standardID
to
"ivo://ivoa.net/std/SSA". Because the
cs:SSACapRestriction
is marked as abstract, instance
documents can not use it directly as a value for the
xsi:type
attribute.
The custom metadata that the ssa:SimpleSpectralAccess
type
provides is given in the table below. Note that some of these
elements derive from the SSA standard [SSA];
others, from the RM standard [RM]. The "Semantic
Meaning" entry provides the reference to the original definition.
ssa:SimpleSpectralAccess Extension Metadata Elements | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Element | Definition | ||||||||||||||||||||||||
complianceLevel |
| ||||||||||||||||||||||||
dataSource |
| ||||||||||||||||||||||||
creationType |
| ||||||||||||||||||||||||
maxSearchRadius |
| ||||||||||||||||||||||||
maxRecords |
| ||||||||||||||||||||||||
defaultMaxRecords |
| ||||||||||||||||||||||||
maxAperture |
| ||||||||||||||||||||||||
maxFileSize |
| ||||||||||||||||||||||||
testQuery |
|
The controlled vocabulary given for the above elements are set by their respective simple types:
<xs:simpleType name="ComplianceLevel" > <xs:restriction base="xs:string" > <xs:enumeration value="query" /> <xs:enumeration value="minimal" /> <xs:enumeration value="full" /> </restriction> </simpleType>
<xs:simpleType name="DataSource" > <xs:restriction base="xs:string" > <xs:enumeration value="survey" /> <xs:enumeration value="pointed" /> <xs:enumeration value="custom" /> <xs:enumeration value="theory" /> <xs:enumeration value="artificial" /> </restriction> </simpleType>
<xs:simpleType name="CreationType" > <xs:restriction base="xs:string" > <xs:enumeration value="archival" /> <xs:enumeration value="cutout" /> <xs:enumeration value="filtered" /> <xs:enumeration value="mosaic" /> <xs:enumeration value="projection" /> <xs:enumeration value="specialExtraction" /> <xs:enumeration value="catalogExtraction" /> </restriction> </simpleType>
As with the other DAL vr:capability
types, the
<testQuery>
element is intended to help other VO
components (e.g. registries, validation services, services that
monitor the VO's operational health--but typically not end users) test
that the service is up and operating correctly. It provides a set of
legal input parameters that should return a legal response that
includes at least matched record. Since this query is intended for
testing purposes, the size of the result set should be small.
The ssa:Query
type captures the different components of
the query into separate elements, as defined below:
<xs:complexType name="Query" > <xs:sequence > <xs:element name="pos" type="ssa:PosParam" minOccurs="0" /> <xs:element name="size" type="xs:double" minOccurs="0" /> <xs:element name="queryDataCmd" type="xs:string" minOccurs="0" /> </sequence> </complexType>
The individual sub-elements are defined as follows:
ssa:Query Metadata Elements | |||||||||
---|---|---|---|---|---|---|---|---|---|
Element | Definition | ||||||||
pos |
| ||||||||
size |
| ||||||||
queryDataCmd |
|
The ssa:PosParam
type is used to encode the
<testQuery>
's <pos>
element, the
center position of the test region of interest; it is defined as follows:
<xs:complexType name="PosParam" > <xs:sequence > <xs:element name="long" type="xs:double" minOccurs="0" /> <xs:element name="lat" type="xs:double" minOccurs="0" /> <xs:element name="refframe" type="xs:token" minOccurs="0" /> </sequence> </complexType>
This type differs from the corresponding test position types used by the other DAL extensions in that it allows one to specify a coordinate reference frame supported by SSA's POS input parameter (see [SSA], section 4.1.1.1).
ssa:PosParam Metadata Elements | |||||||
---|---|---|---|---|---|---|---|
Element | Definition | ||||||
long |
| ||||||
lat |
| ||||||
refframe |
|
The ssa:ProtoSpectralAccess
type is provided for a
special class of SSA services that were historically deployed prior to
the publication of the SSA Recommendation [SSA].
An SSA service should describe its support for the protocol using this
capability type if it was implemented against an earlier draft of the
protocol specification and, therefore, is not expected to be compliant
with the actual SSA Recommendation.
This type is defined exactly as the
ssa:SimpleSpectralAccess
type:
<xs:complexType name="ProtoSpectralAccess" > <xs:complexContent > <xs:extension base="ssa:SSACapRestriction" > <xs:sequence > <xs:element name="dataSource" type="ssa:DataSource" minOccurs="1" maxOccurs="unbounded" /> <xs:element name="creationType" type="ssa:CreationType" minOccurs="1" maxOccurs="unbounded" /> <xs:element name="maxSearchRadius" type="xs:double" /> <xs:element name="maxRecords" type="xs:int" /> <xs:element name="defaultMaxRecords" type="xs:int" /> <xs:element name="maxAperture" type="xs:double" minOccurs="0" /> <xs:element name="maxFileSize" type="xs:int" maxOccurs="1" minOccurs="0" /> <xs:element name="testQuery" type="ssa:Query" minOccurs="0" maxOccurs="1" /> </sequence> </extension> </complexContent> </complexType>
Use of this type is intended to be temporary: providers whose SSA
service falls into this category are encouraged to up-date the service
for compliance final SSA Recommendation. A VOResource resource description must
not include both a ssa:SimpleSpectralAccess
capability and a
ssa:ProtoSpectralAccess
capability that describe the same
service base URL, as given by the <interface>
's
<accessURL>
.
This section describes the SLA VOResource metadata extension schema which is used to describe services that comply with the Simple Line Access protocol [SLA].
The namespace associated with the SIA extension schema is
"http://www.ivoa.net/xml/SLAP/1.0". The namespace prefix,
sia
, should be used in applications where common use of
prefixes improves interoperability (e.g. in the IVOA registries
[RI]). Furthermore, we use the slap
prefix in this document to refer to types defined as part of the
SLA extension schema.
The sia:SimpleLineAccess
type is a vr:Capability
sub-type that should be used to describe a service's support for the
Simple Line Access protocol [SLA]; it is defined
as follows:
<xs:complexType name="SLAPCapRestriction" abstract="true" > <xs:complexContent > <xs:restriction base="vr:Capability" > <xs:sequence > <xs:element name="validationLevel" type="vr:Validation" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="description" type="xs:token" minOccurs="0" /> <xs:element name="interface" type="vr:Interface" minOccurs="0" maxOccurs="unbounded" /> </sequence> <xs:attribute name="standardID" type="vr:IdentifierURI" use="required" fixed="ivo://ivoa.net/std/SLAP" /> </restriction> </complexContent> </complexType> <xs:complexType name="SimpleLineAccess" > <xs:complexContent > <xs:extension base="slap:SLAPCapRestriction" > <xs:sequence > <xs:element name="complianceLevel" type="slap:ComplianceLevel" /> <xs:element name="dataSource" type="slap:DataSource" /> <xs:element name="maxRecords" type="xs:int" /> <xs:element name="testQuery" type="slap:Query" minOccurs="0" maxOccurs="1" /> </sequence> </extension> </complexContent> </complexType>
The custom metadata that the slap:SimpleLineAccess
type
provides is given in the table below.
slap:SimpleLineAccess Extension Metadata Elements | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Element | Definition | ||||||||||||||||
complianceLevel |
| ||||||||||||||||
dataSource |
| ||||||||||||||||
maxRecords |
| ||||||||||||||||
testQuery |
|
The controlled vocabulary given for the above elements are set by their respective simple types:
<xs:simpleType name="ComplianceLevel" > <xs:restriction base="xs:string" > <xs:enumeration value="minimal" /> <xs:enumeration value="full" /> </restriction> </simpleType>
<xs:simpleType name="DataSource" > <xs:restriction base="xs:string" > <xs:enumeration value="observational/astrophysical" /> <xs:enumeration value="observational/laboratory" /> <xs:enumeration value="theoretical" /> </restriction> </simpleType>
As with the other DAL vr:capability
types, the
<testQuery>
element is intended to help other VO
components (e.g. registries, validation services, services that
monitor the VO's operational health--but typically not end users) test
that the service is up and operating correctly. It provides a set of
legal input parameters that should return a legal response that
includes at least matched record. Since this query is intended for
testing purposes, the size of the result set should be small.
The slap:Query
type captures the different components of
the query into separate elements, as defined below:
<xs:complexType name="Query" > <xs:sequence > <xs:element name="wavelength" type="slap:WavelengthRange" minOccurs="0" /> <xs:element name="queryDataCmd" type="xs:string" minOccurs="0" /> </sequence> </complexType>
The individual sub-elements are defined as follows:
slap:Query Metadata Elements | |||||||||
---|---|---|---|---|---|---|---|---|---|
Element | Definition | ||||||||
wavelength |
| ||||||||
queryDataCmd |
|
The slap:WavelengthRange
type is used to encode the
<testQuery>
's <wavelength>
element, the range of wavelengths to search.
<xs:complexType name="WavelengthRange" > <xs:sequence > <xs:element name="minWavelength" type="xs:double" minOccurs="0" /> <xs:element name="maxWavelength" type="xs:double" minOccurs="0" /> </sequence> </complexType>
slap:WavelengthRange Metadata Elements | |||||||
---|---|---|---|---|---|---|---|
Element | Definition | ||||||
minWavelength |
| ||||||
maxWavelength |
|
http://www.ietf.org/rfc/rfc2119.txt
http://www.w3.org/TR/xmlschema-0/
http://www.ivoa.net/Documents/REC/DAL/ConeSearch-20080222.html
.
http://www.ivoa.net/Documents/WD/SIA/sia-20040524.html
.
http://www.ivoa.net/Documents/cover/SSA-20080201.html
.
http://www.ivoa.net/Documents/SLAP/20101209/
. http://www.ivoa.net/Documents/latest/ResourceInterface.html
http://www.ivoa.net/Documents/REC/ResMetadata/RM-20040426.htm
http://www.ivoa.net/Documents/REC/ReR/VOResource-20080222.html
http://www.ivoa.net/Documents/VODataService/20090903/