complexType "ssap:SimpleSpectralAccess"
Namespace:
http://www.ivoa.net/xml/SSA/v1.1
Content:
complex, 1 attribute, 20 elements
Defined:
globally in SSA-v1.3.xsd; see XML source
Includes:
definitions of 11 elements
Used:
never
XML Representation Summary
<...
    standardID
 = 
 xs:anyURI
    >
   
Content: 
 validationLevel*, description?, interface*, complianceLevel, productType*, dataSource+, creationType+, supportedFrame+, maxSearchRadius?, maxRecords?, defaultMaxRecords?, maxAperture?, maxFileSize?, testQuery?
</...>
Content Model Elements (14):
complianceLevel (type ssap:ComplianceLevel),
creationType (type ssap:CreationType),
dataSource (type ssap:DataSource),
defaultMaxRecords (type xs:positiveInteger),
description (type xs:string),
interface (type vr:Interface),
maxAperture (type xs:double),
maxFileSize (type xs:positiveInteger),
maxRecords (type xs:positiveInteger),
maxSearchRadius (type xs:double),
productType (type xs:token),
supportedFrame (type xs:token),
testQuery (type ssap:Query),
validationLevel (type vr:Validation)
Annotation
The capabilities of an SSA service implementation.
Type Definition Detail
Type Derivation Tree
vr:Capability (extension)
  ssap:SimpleSpectralAccess
XML Source (see within schema source)
<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>
Attribute Detail (all declarations; 1)
standardID
Type:
xs:anyURI
Use:
optional
Defined:
locally within vr:Capability complexType
Annotation 1 [src]:
A URI identifier for a standard service.
Annotation 2 [src]:
This provides a unique way to refer to a service specification standard, such as a Simple Image Access service. The use of an IVOA identifier here implies that a VOResource description of the standard is registered and accessible.
XML Source (see within schema source)
<xs:attribute name="standardID" type="xs:anyURI">
<xs:annotation>
<xs:documentation>
A URI identifier for a standard service.
</xs:documentation>
<xs:documentation>
This provides a unique way to refer to a service
specification standard, such as a Simple Image Access service.
The use of an IVOA identifier here implies that a
VOResource description of the standard is registered and
accessible.
</xs:documentation>
</xs:annotation>
</xs:attribute>
Content Element Detail (all declarations; 20)
complianceLevel
Type:
ssap:ComplianceLevel, simple content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
Annotation 1 [src]:
The category indicating the level to which this instance complies with the SSA standard.
Annotation 2 [src]:
Allowed values are "query", "minimal", and "full". See definitions of allowed values for details.
XML Source (see within schema source)
<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>
creationType
Type:
ssap:CreationType, simple content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
Annotation 1 [src]:
The category that describes the process used to produce the dataset.
Annotation 2 [src]:
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.
Annotation 3 [src]:
Allowed values are "archival", "cutout", "filtered", "mosaic", "projection", "spectralExtraction", "catalogExtraction"
XML Source (see within schema source)
<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>
dataSource
Type:
ssap:DataSource, simple content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
Annotation 1 [src]:
The category specifying where the data originally came from.
Annotation 2 [src]:
Allowed values are "survey", "pointed", "custom", "theory", "artificial"
XML Source (see within schema source)
<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>
defaultMaxRecords
Type:
xs:positiveInteger, simple content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
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.
XML Source (see within schema source)
<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>
description
Type:
xs:string, simple content
Defined:
locally within vr:Capability complexType
Annotation 1 [src]:
A human-readable description of what this capability provides as part of the over-all service
Annotation 2 [src]:
Use of this optional element is especially encouraged when this capability is non-standard and is one of several capabilities listed.
XML Source (see within schema source)
<xs:element minOccurs="0" name="description" type="xs:string">
<xs:annotation>
<xs:documentation>
A human-readable description of what this capability
provides as part of the over-all service
</xs:documentation>
<xs:documentation>
Use of this optional element is especially encouraged when
this capability is non-standard and is one of several
capabilities listed.
</xs:documentation>
</xs:annotation>
</xs:element>
description
Type:
xs:string, simple content
Defined:
locally within vr:Capability complexType
Annotation 1 [src]:
A human-readable description of what this capability provides as part of the over-all service
Annotation 2 [src]:
Use of this optional element is especially encouraged when this capability is non-standard and is one of several capabilities listed.
XML Source (see within schema source)
<xs:element minOccurs="0" name="description" type="xs:string">
<xs:annotation>
<xs:documentation>
A human-readable description of what this capability
provides as part of the over-all service
</xs:documentation>
<xs:documentation>
Use of this optional element is especially encouraged when
this capability is non-standard and is one of several
capabilities listed.
</xs:documentation>
</xs:annotation>
</xs:element>
description
Type:
xs:string, simple content
Defined:
locally within vr:Capability complexType
Annotation 1 [src]:
A human-readable description of what this capability provides as part of the over-all service
Annotation 2 [src]:
Use of this optional element is especially encouraged when this capability is non-standard and is one of several capabilities listed.
XML Source (see within schema source)
<xs:element minOccurs="0" name="description" type="xs:string">
<xs:annotation>
<xs:documentation>
A human-readable description of what this capability
provides as part of the over-all service
</xs:documentation>
<xs:documentation>
Use of this optional element is especially encouraged when
this capability is non-standard and is one of several
capabilities listed.
</xs:documentation>
</xs:annotation>
</xs:element>
interface
Type:
vr:Interface, complex content
Defined:
locally within vr:Capability complexType
Annotation 1 [src]:
a description of how to call the service to access this capability
Annotation 2 [src]:
Since the Interface type is abstract, one must describe the interface using a subclass of Interface, denoting it via xsi:type.
Annotation 3 [src]:
Multiple occurences can describe different interfaces to the logically same capability, i.e. data or functionality. That is, the inputs accepted and the output provides should be logically the same. For example, a WebBrowser interface given in addition to a WebService interface would simply provide an interactive, human-targeted interface to the underlying WebService interface.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="interface" type="vr:Interface">
<xs:annotation>
<xs:documentation>
a description of how to call the service to access
this capability
</xs:documentation>
<xs:documentation>
Since the Interface type is abstract, one must describe
the interface using a subclass of Interface, denoting
it via xsi:type.
</xs:documentation>
<xs:documentation>
Multiple occurences can describe different interfaces to
the logically same capability, i.e. data or functionality.
That is, the inputs accepted and the output provides should
be logically the same. For example, a WebBrowser interface
given in addition to a WebService interface would simply
provide an interactive, human-targeted interface to the
underlying WebService interface.
</xs:documentation>
</xs:annotation>
</xs:element>
interface
Type:
vr:Interface, complex content
Defined:
locally within vr:Capability complexType
Annotation 1 [src]:
a description of how to call the service to access this capability
Annotation 2 [src]:
Since the Interface type is abstract, one must describe the interface using a subclass of Interface, denoting it via xsi:type.
Annotation 3 [src]:
Multiple occurences can describe different interfaces to the logically same capability, i.e. data or functionality. That is, the inputs accepted and the output provides should be logically the same. For example, a WebBrowser interface given in addition to a WebService interface would simply provide an interactive, human-targeted interface to the underlying WebService interface.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="interface" type="vr:Interface">
<xs:annotation>
<xs:documentation>
a description of how to call the service to access
this capability
</xs:documentation>
<xs:documentation>
Since the Interface type is abstract, one must describe
the interface using a subclass of Interface, denoting
it via xsi:type.
</xs:documentation>
<xs:documentation>
Multiple occurences can describe different interfaces to
the logically same capability, i.e. data or functionality.
That is, the inputs accepted and the output provides should
be logically the same. For example, a WebBrowser interface
given in addition to a WebService interface would simply
provide an interactive, human-targeted interface to the
underlying WebService interface.
</xs:documentation>
</xs:annotation>
</xs:element>
interface
Type:
vr:Interface, complex content
Defined:
locally within vr:Capability complexType
Annotation 1 [src]:
a description of how to call the service to access this capability
Annotation 2 [src]:
Since the Interface type is abstract, one must describe the interface using a subclass of Interface, denoting it via xsi:type.
Annotation 3 [src]:
Multiple occurences can describe different interfaces to the logically same capability, i.e. data or functionality. That is, the inputs accepted and the output provides should be logically the same. For example, a WebBrowser interface given in addition to a WebService interface would simply provide an interactive, human-targeted interface to the underlying WebService interface.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="interface" type="vr:Interface">
<xs:annotation>
<xs:documentation>
a description of how to call the service to access
this capability
</xs:documentation>
<xs:documentation>
Since the Interface type is abstract, one must describe
the interface using a subclass of Interface, denoting
it via xsi:type.
</xs:documentation>
<xs:documentation>
Multiple occurences can describe different interfaces to
the logically same capability, i.e. data or functionality.
That is, the inputs accepted and the output provides should
be logically the same. For example, a WebBrowser interface
given in addition to a WebService interface would simply
provide an interactive, human-targeted interface to the
underlying WebService interface.
</xs:documentation>
</xs:annotation>
</xs:element>
maxAperture
Type:
xs:double, simple content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
Annotation 1 [src]:
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.
Annotation 2 [src]:
Not providing a value is the preferred way to indicate that there is no limit.
XML Source (see within schema source)
<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>
maxFileSize
Type:
xs:positiveInteger, simple content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
Annotation 1 [src]:
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.
Annotation 2 [src]:
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.
XML Source (see within schema source)
<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>
maxRecords
Type:
xs:positiveInteger, simple content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
Annotation 1 [src]:
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.
Annotation 2 [src]:
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.)
XML Source (see within schema source)
<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>
maxSearchRadius
Type:
xs:double, simple content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
Annotation 1 [src]:
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.
Annotation 2 [src]:
Not providing a value is the prefered way to indicate that there is no restriction.
XML Source (see within schema source)
<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>
productType
Type:
xs:token, simple content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
Annotation 1 [src]:
The type of data product served by this service, with each element declaring one of http://www.ivoa.net/rdf/product-type.
Annotation 2 [src]:
If no productType is declared, clients can assume the service serves spectra. Spectral services should still declare “spectrum” here.
XML Source (see within schema source)
<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>
supportedFrame
Type:
xs:token, simple content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
Annotation 1 [src]:
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.
Annotation 2 [src]:
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.
XML Source (see within schema source)
<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>
testQuery
Type:
ssap:Query, complex content
Defined:
locally within (this) ssap:SimpleSpectralAccess complexType
a set of query parameters that is expected to produce at least one matched record which can be used to test the service.
XML Source (see within schema source)
<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>
validationLevel
Type:
vr:Validation, simple content
Defined:
locally within vr:Capability complexType
Annotation 1 [src]:
A numeric grade describing the quality of the capability description and interface, when applicable, to be used to indicate the confidence an end-user can put in the resource as part of a VO application or research study.
Annotation 2 [src]:
See vr:ValidationLevel for an explanation of the allowed levels.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="validationLevel" type="vr:Validation">
<xs:annotation>
<xs:documentation>
A numeric grade describing the quality of the
capability description and interface, when applicable,
to be used to indicate the confidence an end-user
can put in the resource as part of a VO application
or research study.
</xs:documentation>
<xs:documentation>
See vr:ValidationLevel for an explanation of the
allowed levels.
</xs:documentation>
</xs:annotation>
</xs:element>
validationLevel
Type:
vr:Validation, simple content
Defined:
locally within vr:Capability complexType
Annotation 1 [src]:
A numeric grade describing the quality of the capability description and interface, when applicable, to be used to indicate the confidence an end-user can put in the resource as part of a VO application or research study.
Annotation 2 [src]:
See vr:ValidationLevel for an explanation of the allowed levels.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="validationLevel" type="vr:Validation">
<xs:annotation>
<xs:documentation>
A numeric grade describing the quality of the
capability description and interface, when applicable,
to be used to indicate the confidence an end-user
can put in the resource as part of a VO application
or research study.
</xs:documentation>
<xs:documentation>
See vr:ValidationLevel for an explanation of the
allowed levels.
</xs:documentation>
</xs:annotation>
</xs:element>
validationLevel
Type:
vr:Validation, simple content
Defined:
locally within vr:Capability complexType
Annotation 1 [src]:
A numeric grade describing the quality of the capability description and interface, when applicable, to be used to indicate the confidence an end-user can put in the resource as part of a VO application or research study.
Annotation 2 [src]:
See vr:ValidationLevel for an explanation of the allowed levels.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="validationLevel" type="vr:Validation">
<xs:annotation>
<xs:documentation>
A numeric grade describing the quality of the
capability description and interface, when applicable,
to be used to indicate the confidence an end-user
can put in the resource as part of a VO application
or research study.
</xs:documentation>
<xs:documentation>
See vr:ValidationLevel for an explanation of the
allowed levels.
</xs:documentation>
</xs:annotation>
</xs:element>
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/