XML Schema "SSA-v1.3.xsd"
Target Namespace:
http://www.ivoa.net/xml/SSA/v1.1
Version:
1.3-wd2
Defined Components:
17 local elements, 3 complexTypes, 3 simpleTypes
Default Namespace-Qualified Form:
Local Elements: unqualified; Local Attributes: unqualified
Schema Location:
/home/msdemlei/gavo/trunk/gavo/resources/schemata/SSA-v1.3.xsd; see XML source
Imports Schema:
VOResource-v1.1.xsd [src]
Annotation
XML Schema used to describe the capabilities of a service instance conforming to the Simple Spectral Access (SSA) protocol.
XML Source
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="unqualified" targetNamespace="http://www.ivoa.net/xml/SSA/v1.1" version="1.3-wd2" xmlns:ssap="http://www.ivoa.net/xml/SSA/v1.1" xmlns:vm="http://www.ivoa.net/xml/VOMetadata/v0.1" xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:annotation>
<xs:appinfo>
<vm:schemaName>SSA</vm:schemaName>
<vm:schemaPrefix>xs</vm:schemaPrefix>
<vm:targetPrefix>ssap</vm:targetPrefix>
</xs:appinfo>
<xs:documentation>
XML Schema used to describe the capabilities of a service instance
conforming to the Simple Spectral Access (SSA) protocol.
</xs:documentation>
</xs:annotation>
<!-- SSA Capabilities -->
<xs:complexType name="SimpleSpectralAccess">
<xs:annotation>
<xs:documentation>
The capabilities of an SSA service implementation.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="vr:Capability">
<xs:sequence>
<xs:element name="complianceLevel" type="ssap:ComplianceLevel">
<xs:annotation>
<xs:documentation>
The category indicating the level to which
this instance complies with the SSA standard.
</xs:documentation>
<xs:documentation>
Allowed values are "query", "minimal", and "full".
See definitions of allowed values for details.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="unbounded" minOccurs="0" name="productType" type="xs:token">
<xs:annotation>
<xs:documentation>
The type of data product served by this
service, with each element declaring one
of http://www.ivoa.net/rdf/product-type.
</xs:documentation>
<xs:documentation>
If no productType is declared, clients can assume
the service serves spectra. Spectral services
should still declare &#8220;spectrum&#8221; here.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="unbounded" minOccurs="1" name="dataSource" type="ssap:DataSource">
<xs:annotation>
<xs:documentation>
The category specifying where the data originally
came from.
</xs:documentation>
<xs:documentation>
Allowed values are "survey", "pointed", "custom",
"theory", "artificial"
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="unbounded" minOccurs="1" name="creationType" type="ssap:CreationType">
<xs:annotation>
<xs:documentation>
The category that describes the process used to
produce the dataset.
</xs:documentation>
<xs:documentation>
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.
</xs:documentation>
<xs:documentation>
Allowed values are "archival", "cutout", "filtered",
"mosaic", "projection", "spectralExtraction",
"catalogExtraction"
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="unbounded" minOccurs="1" name="supportedFrame" type="xs:token">
<xs:annotation>
<xs:documentation>
Identifiers of spatial reference frames that can be used
in the POS parameter. The identifiers must be taken
from the vocabulary http://www.ivoa.net/rdf/refframe.
</xs:documentation>
<xs:documentation>
At least one recognized value must be listed
when the service supports POS.
With SSA v1.1, ICRS must be supported in that
case; thus,
this list must include at least this value.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0" name="maxSearchRadius" type="xs:double">
<xs:annotation>
<xs:documentation>
The largest search radius, in degrees, that will be
accepted by the service without returning an error
condition. Not providing this element or
specifying a value of 180 indicates that there
is no restriction.
</xs:documentation>
<xs:documentation>
Not providing a value is the prefered way to indicate
that there is no restriction.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0" name="maxRecords" type="xs:positiveInteger">
<xs:annotation>
<xs:documentation>
The hard limit on the largest number of records that
the query operation will return in a single response.
Not providing this value means that there is no
effective limit.
</xs:documentation>
<xs:documentation>
This does not refer to the total number of spectra in
the archive but rather maximum number of records the
service is capable of returning. A limit that is
greater than the number of spectra available in the
archive is equivalent to their being no effective
limit. (See RM, Hanisch 2007.)
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0" name="defaultMaxRecords" type="xs:positiveInteger">
<xs:annotation>
<xs:documentation>
The largest number of records that the service will
return when the MAXREC parameter not specified
in the query input. Not providing a value means
that the hard limit implied by maxRecords will be
the default limit.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0" name="maxAperture" type="xs:double">
<xs:annotation>
<xs:documentation>
The largest aperture that can be supported upon
request via the APERTURE input parameter by a
service that supports the spectral extraction
creation method. A value of 180 or not providing
a value means there is no theoretical limit.
</xs:documentation>
<xs:documentation>
Not providing a value is the preferred way to
indicate that there is no limit.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0" name="maxFileSize" type="xs:positiveInteger">
<xs:annotation>
<xs:documentation>
The maximum spectrum file size in bytes that will
be returned. Not providing
a value indicates that there is no effective limit
the size of files that can be returned.
</xs:documentation>
<xs:documentation>
This is primarily relevant when spectra are created
on the fly (see creationType). If the service
provides access to static spectra, this should only
be specified if there are spectra in the archive that
can be searched for but not returned because they are
too big.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0" name="testQuery" type="ssap:Query">
<xs:annotation>
<xs:documentation>
a set of query parameters that is expected to
produce at least one matched record which can be
used to test the service.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="ComplianceLevel">
<xs:annotation>
<xs:documentation>
The allowed values for indicating the level at which a
service instance complies with the SSA standard.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:token">
<xs:enumeration value="query">
<xs:annotation>
<xs:documentation>
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.
</xs:documentation>
<xs:documentation>
This level represents the lowest level of compliance.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="minimal">
<xs:annotation>
<xs:documentation>
The service supports all of the capabilities and features
of the SSA protocol identified as "must" in the
specification.
</xs:documentation>
<xs:documentation>
In brief, this includes:
* implementing the GET interface,
* support the parameters POS, SIZE, TOME, BAND, and
FORMAT
* includes all mandatory metadata fields in query
response
* supports getData method retrieval in at least one
SSA-compliant format
* supports the "FORMAT=METADATA" metadata query.
</xs:documentation>
<xs:documentation>
This level represents the middle level of compliance.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="full">
<xs:annotation>
<xs:documentation>
The service supports all of the capabilities and features
of the SSA protocol identified as "must" or "should" in the
specification.
</xs:documentation>
<xs:documentation>
This level represents the highest level of compliance.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="DataSource">
<xs:annotation>
<xs:documentation>
The defined categories that specify where the spectral data
originally came from.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:token">
<xs:enumeration value="survey">
<xs:annotation>
<xs:documentation>
A survey dataset, which typically covers some region of
observational parameter space in a uniform fashion, with
as complete as possible coverage in the region of parameter
space observed.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="pointed">
<xs:annotation>
<xs:documentation>
A pointed observation of a particular astronomical object
or field.
</xs:documentation>
<xs:documentation>
Typically, these are instrumental observations taken as
part of some PI observing program. The data quality and
characteristics may be variable, but the observations of
a particular object or field may be more extensive than
for a survey.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="custom">
<xs:annotation>
<xs:documentation>
Data which has been custom processed, e.g., as part of
a specific research project.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="theory">
<xs:annotation>
<xs:documentation>
Theory data, or any data generated from a theoretical
model, for example a synthetic spectrum.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="artificial">
<xs:annotation>
<xs:documentation>
Artificial or simulated data.
</xs:documentation>
<xs:documentation>
This is similar to theory data but need not be based on
a physical model, and is often used for testing purposes.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="CreationType">
<xs:restriction base="xs:token">
<xs:enumeration value="archival">
<xs:annotation>
<xs:documentation>
The entire archival or project dataset is returned.
Transformations such as metadata or data model mediation
or format conversions may take place, but the content of
the dataset is not substantially modified (e.g., all the
data is returned and the sample values are not modified).
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="cutout">
<xs:annotation>
<xs:documentation>
The dataset is subsetted in some region of parameter
space to produce a subset dataset. Sample values are not
modified, e.g., cutouts could be recombined to reconstitute
the original dataset.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="filtered">
<xs:annotation>
<xs:documentation>
The data is filtered in some fashion to exclude portions
of the dataset, e.g., passing only data in selected regions
along a measurement axis, or processing the data in a way
which recomputes the sample values, e.g., due to
interpolation or flux transformation.
</xs:documentation>
<xs:documentation>
Filtering is often
combined with other forms of processing, e.g., projection.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="mosaic">
<xs:annotation>
<xs:documentation>
Data from multiple non- or partially-overlapping datasets
are combined to produce a new dataset.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="projection">
<xs:annotation>
<xs:documentation>
Data is geometrically warped or dimensionally reduced by
projecting through a multidimensional dataset.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="spectralExtraction">
<xs:annotation>
<xs:documentation>
Extraction of a spectrum from another dataset, e.g.,
extraction of a spectrum from a spectral data cube
through a simulated aperture.
</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="catalogExtraction">
<xs:annotation>
<xs:documentation>
Extraction of a catalog of some form from another dataset,
e.g., extraction of a source catalog from an image, or
extraction of a line list catalog from a spectrum (not
valid for a SSA service).
</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="Query">
<xs:annotation>
<xs:documentation>
A query to be sent to the service
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element minOccurs="0" name="pos" type="ssap:PosParam">
<xs:annotation>
<xs:documentation>
the center position the search cone given in
decimal degrees.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element minOccurs="0" name="size" type="xs:double">
<xs:annotation>
<xs:documentation>
the size of the search radius.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element minOccurs="0" name="queryDataCmd" type="xs:string">
<xs:annotation>
<xs:documentation>
Fully specified test query formatted as an URL
argument list in the syntax specified by the SSA standard.
The list must exclude the REQUEST argument which is
assumed to be set to "queryData".
</xs:documentation>
<xs:documentation>
This value must be in the form of name=value
pairs delimited with ampersands (&amp;). A query
may then be formed by appending to the base URL the
request argument, "REQUEST=queryData&amp;", followed
by the contents of this element.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PosParam">
<xs:annotation>
<xs:documentation>
a position in the sky to search.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="long" type="xs:double">
<xs:annotation>
<xs:documentation>
The longitude (e.g. Right Ascension) of the center of the
search position in decimal degrees.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="lat" type="xs:double">
<xs:annotation>
<xs:documentation>
The latitude (e.g. Declination) of the center of the
search position in decimal degrees.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element minOccurs="0" name="refframe" type="xs:token">
<xs:annotation>
<xs:documentation>
the coordinate system reference frame name indicating
the frame to assume for the given position. If not
provided, ICRS is assumed.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
<!-- vim:et:sta:sw=3
-->

This XML schema documentation has been generated with DocFlex/XML RE 1.8.0 using DocFlex/XML XSDDoc 2.2.0 template set.
DocFlex/XML RE is a reduced edition of DocFlex/XML, which is a tool for programming and running highly sophisticated documentation and reports generators by the data obtained from any kind of XML files. The actual doc-generators are implemented in the form of special templates that are designed visually using a high quality Template Designer GUI basing on the XML schema (or DTD) files describing the data source XML.
DocFlex/XML XSDDoc is a commercial template application of DocFlex/XML that implements a high-end XML Schema documentation generator with simultaneous support of framed multi-file HTML, single-file HTML and RTF output formats. (More formats are planned in the future).
A commercial license for "DocFlex/XML XSDDoc" will allow you:
  • To configure the generated documentation so much as you want. Thanks to our template technology, it was possible to support more than 300 template parameters (working the same as "options" of an ordinary doc-gen), which will give you an unprecedented control over the generated content!
  • To use certain features disabled in the free mode (such as the full documenting of substitution groups).
  • To enable/disable documenting of the initial, imported, included and redefined XML schemas selectively.
  • To document local element components both globally and locally (similar to attributes).
  • To enable/disable reproducing of namespace prefixes.
  • To format your annotations with XHTML tags and reproduce that formatting both in HTML and RTF output.
  • To insert images in your annotations using XHTML <img> tags (supported both in HTML and RTF output).
  • To use PlainDoc.tpl main template to generate all the XML schema documentation in the form of a single HTML file.
  • To use the same template to generate the incredible quality RTF documentation.
  • To document only selected XML schema components specified by name.
  • To remove this very advertisement text
Once having only such a license, you will be able to run the fully-featured XML schema documentation generator both with DocFlex/XML SDK and with DocFlex/XML RE, which is a reduced free edition containing only the template interpretor / output generator. No other licenses will be required!
But this is not all. In addition to it, a commercial license for DocFlex/XML SDK will allow you to modify the XSDDoc templates themselves as much as you want. You will be able to achieve whatever was impossible to do with the template parameters only. And, of course, you could develop any template applications by your own!
Please note: By purchasing a license for this software, you not only acquire a useful tool, you will also make an important investment in its future development, the result of which you could enjoy later by yourself. Every single your purchase matters and makes a difference for us!
To buy a license, please follow this link: http://www.filigris.com/shop/