| <?xml version="1.0" encoding="UTF-8"?> <xs:schema attributeFormDefault="unqualified" elementFormDefault="unqualified" targetNamespace="http://www.ivoa.net/xml/TAPRegExt/v1.0" version="1.0" xmlns:tr="http://www.ivoa.net/xml/TAPRegExt/v1.0" 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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/2001/XMLSchema http://vo.ari.uni-heidelberg.de/docs/schemata/XMLSchema.xsd"> <xs:annotation> <xs:appinfo> <vm:schemaName>TAPRegExt</vm:schemaName> <vm:schemaPrefix>xs</vm:schemaPrefix> <vm:targetPrefix>tr</vm:targetPrefix> </xs:appinfo> <xs:documentation> A description of the capabilities metadata for TAP services. </xs:documentation> </xs:annotation> <xs:import namespace="http://www.ivoa.net/xml/VOResource/v1.0" schemaLocation="http://docs.g-vo.org/schemata/VOResource.xsd"/> <xs:annotation> <xs:documentation> The capabilities of a TAP server. </xs:documentation> <xs:documentation> The capabilities attempt to define most issues that the TAP standard leaves to the implementors ("may", "should"). </xs:documentation> </xs:annotation> <xs:complexContent> <xs:sequence> <xs:annotation> <xs:documentation> Identifier of IVOA-approved data model supported by the service. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Language supported by the service. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Output format supported by the service. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Upload method supported by the service. </xs:documentation> <xs:documentation> The absence of upload methods indicates that the service does not support uploads at all. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Limits on the time between job creation and destruction time. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Limits on executionDuration. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Limits on the size of data returned. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Limits on the size of uploaded data. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:annotation> <xs:documentation> An interface for a complex, multi-endpoint interfaces as regulated by DALI. </xs:documentation> <xs:documentation> In addition to the standard vr:Interface elements, DALIInterfaces have endpoints, listed by name; that name doubles as a path segment to append to the interface's access URL, yielding the URI at which the endpoint is operated. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:sequence> <xs:annotation> <xs:documentation> An endpoint accessible through this interface. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:annotation> <xs:documentation> An endpoint of a complex interface. </xs:documentation> <xs:documentation> An endpoint is characterised and addrssed by its name; they can further be defined through RDF triples. This is a generic extension mechanism for endpoint-specific metadata, primarily intended for custom, vendor-specific extensions. </xs:documentation> </xs:annotation> <xs:sequence> <xs:annotation> <xs:documentation> The endpoint name, which is also the last component of the path of its URI. </xs:documentation> <xs:documentation> Names without dashes are reserved for IVOA use and are expected to work the same way on all services. Well-known examples for such endpoint names include sync, async, and tables. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Auxiliary information on this endpoint. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:annotation> <xs:documentation> A container for an RDFa triple giving information related to an endpoint. </xs:documentation> </xs:annotation> <xs:simpleContent> <xs:annotation> <xs:documentation> The subject of the statement. </xs:documentation> <xs:documentation> If missing, the endpoint itself is assumed as the subject. </xs:documentation> </xs:annotation> </xs:attribute> <xs:annotation> <xs:documentation> The property of the statement. </xs:documentation> <xs:documentation> This is a reference to an RDF resource. IVOA standards may define semantics for scheme-less URI; non-IVOA properties must use full URIs with at least scheme and authority; in this version, no vocab attributes are supported. </xs:documentation> </xs:annotation> </xs:attribute> <xs:annotation> <xs:documentation> The object of the statement. </xs:documentation> <xs:documentation> If missing, the text content of the element is used as the object. </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:annotation> <xs:documentation> An IVOA defined data model, identified by an IVORN intended for machine consumption and a short label intended for human consumption. </xs:documentation> </xs:annotation> <xs:simpleContent> <xs:annotation> <xs:documentation> The IVOID of the data model. </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:annotation> <xs:documentation> A query language supported by the service. </xs:documentation> <xs:documentation> Each language element can describe one or more versions of a language. Either name alone or name-version can be used as values for the server's LANG parameter. </xs:documentation> </xs:annotation> <xs:sequence> <xs:annotation> <xs:documentation> The name of the language without a version suffix. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> A version of the language supported by the server. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> A short, human-readable description of the query language. </xs:documentation> </xs:annotation> </xs:element> <xs:element maxOccurs="unbounded" minOccurs="0" name="languageFeatures" type="tr:LanguageFeatureList"> <xs:annotation> <xs:documentation> Optional features of the query language, grouped by feature type. </xs:documentation> <xs:documentation> This includes listing user defined functions, geometry support, or similar concepts. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:annotation> <xs:documentation> One version of the language supported by the service. </xs:documentation> <xs:documentation> If the service supports more than one version of the language, include multiple version elements. It is recommended that you use a version numbering scheme like MAJOR.MINOR in such a way that sorting by ascending character codes will leave the most recent version at the bottom of the list. </xs:documentation> </xs:annotation> <xs:simpleContent> <xs:annotation> <xs:documentation> An optional IVOID of the language. </xs:documentation> <xs:documentation> To more formally define a language supported by a service, a resource record for the language can be created, either centrally on the Registry of Registries or by other registry operators. When such a record exists, the ivo-id attribute of language should point to it. </xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:annotation> <xs:documentation> An enumeration of non-standard or non-mandatory features of a specific type implemented by the language. </xs:documentation> <xs:documentation> A feature type is a language-dependent concept like "user defined function", "geometry support", or possibly "units supported". A featureList gives all features of a given type applicable for the service. Multiple featureLists are possible. All feature in a given list are of the same type. This type is declared using the mandatory type attribute, the value of which will typically be an IVOID. To see values defined in TAPRegExt, retrieve the ivo://ivoa.net/std/TAPRegExt resource record and look for keys starting with "features-". </xs:documentation> </xs:annotation> <xs:sequence> <xs:annotation> <xs:documentation> A language feature of the type given by the type attribute. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> <xs:annotation> <xs:documentation> The type of the features given here. </xs:documentation> <xs:documentation> This is in general an IVOID. TAPRegExt itself gives IVOIDs for defining user defined functions and geometry support. </xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> <xs:annotation> <xs:documentation> A non-standard or non-mandatory feature implemented by the language.. </xs:documentation> </xs:annotation> <xs:sequence> <xs:annotation> <xs:documentation> Formal notation for the language feature. </xs:documentation> <xs:documentation> The syntax for the content of this element is defined by the type attribute of its parent language list. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Human-readable freeform documentation for the language feature. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:annotation> <xs:documentation> An output format supported by the service. </xs:documentation> <xs:documentation> All TAP services must support VOTable output, with media types as requested by the FORMAT parameter if applicable (cf.~section 2.7.1 of the TAP standard). The primary identifier for an output format is the RFC 2046 media type. If you want to register an output format, you must use a media type (or make one up using the x- syntax), although the concrete media syntax is not enforced by the schema. For more detailed specification, an IVOID may be used. </xs:documentation> </xs:annotation> <xs:sequence> <xs:annotation> <xs:documentation> The media type of this format. </xs:documentation> <xs:documentation> The format of this string is specified by RFC 2046. The service has to accept this string as a value of the FORMAT parameter. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> Other values of FORMAT ("shorthands") that make the service return documents with the media type. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> <xs:annotation> <xs:documentation> An optional IVOID of the output format. </xs:documentation> <xs:documentation> When the media type does not uniquely define the format (or a generic media type like application/octet-stream or text/plain is given), the IVOID can point to a key or StandardsRegExt document defining the format more precisely. To see values defined in TAPRegExt, retrieve the ivo://ivoa.net/std/TAPRegExt resource record and look for keys starting with "output-". </xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> <xs:annotation> <xs:documentation> An upload method as defined by IVOA. </xs:documentation> <xs:documentation> Upload methods are always identified by an IVOID. Descriptions can be obtained by dereferencing this IVOID. To see values defined in TAPRegExt, retrieve the ivo://ivoa.net/std/TAPRegExt resource record and look for keys starting with "upload-". You can register custom upload methods, but you must use the standard IVOIDs for the upload methods defined in the TAP specification. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:annotation> <xs:documentation> The IVOID of the upload method. </xs:documentation> </xs:annotation> </xs:attribute> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:annotation> <xs:documentation> Time-valued limits, all values given in seconds. </xs:documentation> </xs:annotation> <xs:sequence> <xs:annotation> <xs:documentation> The value of this limit for newly-created jobs, given in seconds. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> The value this limit cannot be raised above, given in seconds. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:annotation> <xs:documentation> Limits on data sizes, given in rows or bytes. </xs:documentation> </xs:annotation> <xs:sequence> <xs:annotation> <xs:documentation> The value of this limit for newly-created jobs. </xs:documentation> </xs:annotation> </xs:element> <xs:annotation> <xs:documentation> The value this limit cannot be raised above. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:annotation> <xs:documentation> A limit on some data size, either in rows or in bytes. </xs:documentation> </xs:annotation> <xs:simpleContent> <xs:annotation> <xs:documentation> The unit of the limit specified. </xs:documentation> </xs:annotation> <xs:simpleType> <xs:enumeration value="byte"/> <xs:enumeration value="row"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:schema> |
| 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:
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/ |