complexType "vg:OAIHTTP"
Namespace:
http://www.ivoa.net/xml/VORegistry/v1.0
Content:
complex, 2 attributes, 12 elements
Defined:
globally in VORegistry-1.1.xsd; see XML source
Used:
never
XML Representation Summary
<...
    role
 = 
 xs:NMTOKEN
    version
 = 
 xs:string
    >
   
Content: 
 accessURL+, mirrorURL*, securityMethod*, testQueryString?
</...>
Content Model Elements (4):
accessURL (type vr:AccessURL),
mirrorURL (type vr:MirrorURL),
securityMethod (type vr:SecurityMethod),
testQueryString (type xs:token)
Annotation
Annotation 1 [src]:
a description of the standard OAI PMH interface using HTTP (GET or POST) queries.
Annotation 2 [src]:
the accessURL child element is the base URL for the OAI service as defined in section 3.1.1 of the OAI PMH standard.
Type Definition Detail
Type Derivation Tree
vr:Interface (extension)
  vg:OAIHTTP
XML Source (see within schema source)
<xs:complexType name="OAIHTTP">
<xs:annotation>
<xs:documentation>
a description of the standard OAI PMH interface using HTTP
(GET or POST) queries.
</xs:documentation>
<xs:documentation>
the accessURL child element is the base URL for the OAI
service as defined in section 3.1.1 of the OAI PMH
standard.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="vr:Interface">
<xs:sequence/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Attribute Detail (all declarations; 2)
role
Type:
xs:NMTOKEN
Use:
optional
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
A tag name that identifies the role the interface plays in the particular capability. If the value is equal to "std" or begins with "std:", then the interface refers to a standard interface defined by the standard referred to by the capability's standardID attribute.
Annotation 2 [src]:
For an interface complying with some registered standard (i.e. has a legal standardID), the role can be matched against interface roles enumerated in standard resource record. The interface descriptions in the standard record can provide default descriptions so that such details need not be repeated here.
XML Source (see within schema source)
<xs:attribute name="role" type="xs:NMTOKEN">
<xs:annotation>
<xs:documentation>
A tag name that identifies the role the interface plays
in the particular capability. If the value is equal to
"std" or begins with "std:", then the interface refers
to a standard interface defined by the standard
referred to by the capability's standardID attribute.
</xs:documentation>
<xs:documentation>
For an interface complying with some registered
standard (i.e. has a legal standardID), the role can be
matched against interface roles enumerated in standard
resource record. The interface descriptions in
the standard record can provide default descriptions
so that such details need not be repeated here.
</xs:documentation>
</xs:annotation>
</xs:attribute>
version
Type:
xs:string
Use:
optional
Defined:
locally within vr:Interface complexType
The version of a standard interface specification that this interface complies with. Most VO standards indicate the version in the standardID attribute of the capability. For these standards, the version attribute should not be used.
XML Source (see within schema source)
<xs:attribute name="version" type="xs:string">
<xs:annotation>
<xs:documentation>
The version of a standard interface specification that this
interface complies with. Most VO standards indicate the
version in the standardID attribute of the capability. For
these standards, the version attribute should not be used.
</xs:documentation>
</xs:annotation>
</xs:attribute>
Content Element Detail (all declarations; 12)
accessURL
Type:
vr:AccessURL, simple content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
The URL (or base URL) that a client uses to access the service. How this URL is to be interpreted and used depends on the specific Interface subclass
Annotation 2 [src]:
Although the schema allows multiple occurrences of accessURL, multiple accessURLs are deprecated. Each interface should have exactly one access URL. Where an interface has several mirrors, the accessURL should reflect the “primary” (fastest, best-connected, best-maintained) site, the one that non-sophisticated clients will go to. Additional accessURLs should be put into mirrorURLs. Advanced clients can retrieve the mirrorURLs and empirically determine interfaces closer to their network location.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="1" name="accessURL" type="vr:AccessURL">
<xs:annotation>
<xs:documentation>
The URL (or base URL) that a client uses to access the
service. How this URL is to be interpreted and used
depends on the specific Interface subclass
</xs:documentation>
<xs:documentation>
Although the schema allows multiple occurrences of
accessURL, multiple accessURLs are deprecated. Each
interface should have exactly one access URL. Where an
interface has several mirrors, the accessURL should
reflect the &#8220;primary&#8221; (fastest, best-connected,
best-maintained) site, the one that non-sophisticated
clients will go to.

Additional accessURLs should be put into mirrorURLs.
Advanced clients can retrieve the mirrorURLs and
empirically determine interfaces closer to their
network location.
</xs:documentation>
</xs:annotation>
</xs:element>
accessURL
Type:
vr:AccessURL, simple content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
The URL (or base URL) that a client uses to access the service. How this URL is to be interpreted and used depends on the specific Interface subclass
Annotation 2 [src]:
Although the schema allows multiple occurrences of accessURL, multiple accessURLs are deprecated. Each interface should have exactly one access URL. Where an interface has several mirrors, the accessURL should reflect the “primary” (fastest, best-connected, best-maintained) site, the one that non-sophisticated clients will go to. Additional accessURLs should be put into mirrorURLs. Advanced clients can retrieve the mirrorURLs and empirically determine interfaces closer to their network location.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="1" name="accessURL" type="vr:AccessURL">
<xs:annotation>
<xs:documentation>
The URL (or base URL) that a client uses to access the
service. How this URL is to be interpreted and used
depends on the specific Interface subclass
</xs:documentation>
<xs:documentation>
Although the schema allows multiple occurrences of
accessURL, multiple accessURLs are deprecated. Each
interface should have exactly one access URL. Where an
interface has several mirrors, the accessURL should
reflect the &#8220;primary&#8221; (fastest, best-connected,
best-maintained) site, the one that non-sophisticated
clients will go to.

Additional accessURLs should be put into mirrorURLs.
Advanced clients can retrieve the mirrorURLs and
empirically determine interfaces closer to their
network location.
</xs:documentation>
</xs:annotation>
</xs:element>
accessURL
Type:
vr:AccessURL, simple content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
The URL (or base URL) that a client uses to access the service. How this URL is to be interpreted and used depends on the specific Interface subclass
Annotation 2 [src]:
Although the schema allows multiple occurrences of accessURL, multiple accessURLs are deprecated. Each interface should have exactly one access URL. Where an interface has several mirrors, the accessURL should reflect the “primary” (fastest, best-connected, best-maintained) site, the one that non-sophisticated clients will go to. Additional accessURLs should be put into mirrorURLs. Advanced clients can retrieve the mirrorURLs and empirically determine interfaces closer to their network location.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="1" name="accessURL" type="vr:AccessURL">
<xs:annotation>
<xs:documentation>
The URL (or base URL) that a client uses to access the
service. How this URL is to be interpreted and used
depends on the specific Interface subclass
</xs:documentation>
<xs:documentation>
Although the schema allows multiple occurrences of
accessURL, multiple accessURLs are deprecated. Each
interface should have exactly one access URL. Where an
interface has several mirrors, the accessURL should
reflect the &#8220;primary&#8221; (fastest, best-connected,
best-maintained) site, the one that non-sophisticated
clients will go to.

Additional accessURLs should be put into mirrorURLs.
Advanced clients can retrieve the mirrorURLs and
empirically determine interfaces closer to their
network location.
</xs:documentation>
</xs:annotation>
</xs:element>
mirrorURL
Type:
vr:MirrorURL, simple content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
A (base) URL of a mirror of this interface. As with accessURL, how this URL is to be interpreted and used depends on the specific Interface subclass
Annotation 2 [src]:
This is intended exclusively for true mirrors, i.e., interfaces that are functionally identical to the original interface and that are operated by the same publisher. Other arrangements should be represented as separate services linked by mirror-of relationships.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="mirrorURL" type="vr:MirrorURL">
<xs:annotation>
<xs:documentation>
A (base) URL of a mirror of this interface. As with
accessURL, how this URL is to be interpreted and used
depends on the specific Interface subclass
</xs:documentation>
<xs:documentation>
This is intended exclusively for true mirrors, i.e.,
interfaces that are functionally identical to the
original interface and that are operated by the same
publisher. Other arrangements should be represented as
separate services linked by mirror-of relationships.
</xs:documentation>
</xs:annotation>
</xs:element>
mirrorURL
Type:
vr:MirrorURL, simple content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
A (base) URL of a mirror of this interface. As with accessURL, how this URL is to be interpreted and used depends on the specific Interface subclass
Annotation 2 [src]:
This is intended exclusively for true mirrors, i.e., interfaces that are functionally identical to the original interface and that are operated by the same publisher. Other arrangements should be represented as separate services linked by mirror-of relationships.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="mirrorURL" type="vr:MirrorURL">
<xs:annotation>
<xs:documentation>
A (base) URL of a mirror of this interface. As with
accessURL, how this URL is to be interpreted and used
depends on the specific Interface subclass
</xs:documentation>
<xs:documentation>
This is intended exclusively for true mirrors, i.e.,
interfaces that are functionally identical to the
original interface and that are operated by the same
publisher. Other arrangements should be represented as
separate services linked by mirror-of relationships.
</xs:documentation>
</xs:annotation>
</xs:element>
mirrorURL
Type:
vr:MirrorURL, simple content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
A (base) URL of a mirror of this interface. As with accessURL, how this URL is to be interpreted and used depends on the specific Interface subclass
Annotation 2 [src]:
This is intended exclusively for true mirrors, i.e., interfaces that are functionally identical to the original interface and that are operated by the same publisher. Other arrangements should be represented as separate services linked by mirror-of relationships.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="mirrorURL" type="vr:MirrorURL">
<xs:annotation>
<xs:documentation>
A (base) URL of a mirror of this interface. As with
accessURL, how this URL is to be interpreted and used
depends on the specific Interface subclass
</xs:documentation>
<xs:documentation>
This is intended exclusively for true mirrors, i.e.,
interfaces that are functionally identical to the
original interface and that are operated by the same
publisher. Other arrangements should be represented as
separate services linked by mirror-of relationships.
</xs:documentation>
</xs:annotation>
</xs:element>
securityMethod
Type:
vr:SecurityMethod, empty content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
The mechanism the client must employ to authenticate to the service.
Annotation 2 [src]:
Services not requiring authentication must provide at least one interface definition without a securityMethod defined.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="securityMethod" type="vr:SecurityMethod">
<xs:annotation>
<xs:documentation>
The mechanism the client must employ to authenticate
to the service.
</xs:documentation>
<xs:documentation>
Services not requiring authentication must provide
at least one interface definition without a
securityMethod defined.
</xs:documentation>
</xs:annotation>
</xs:element>
securityMethod
Type:
vr:SecurityMethod, empty content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
The mechanism the client must employ to authenticate to the service.
Annotation 2 [src]:
Services not requiring authentication must provide at least one interface definition without a securityMethod defined.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="securityMethod" type="vr:SecurityMethod">
<xs:annotation>
<xs:documentation>
The mechanism the client must employ to authenticate
to the service.
</xs:documentation>
<xs:documentation>
Services not requiring authentication must provide
at least one interface definition without a
securityMethod defined.
</xs:documentation>
</xs:annotation>
</xs:element>
securityMethod
Type:
vr:SecurityMethod, empty content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
The mechanism the client must employ to authenticate to the service.
Annotation 2 [src]:
Services not requiring authentication must provide at least one interface definition without a securityMethod defined.
XML Source (see within schema source)
<xs:element maxOccurs="unbounded" minOccurs="0" name="securityMethod" type="vr:SecurityMethod">
<xs:annotation>
<xs:documentation>
The mechanism the client must employ to authenticate
to the service.
</xs:documentation>
<xs:documentation>
Services not requiring authentication must provide
at least one interface definition without a
securityMethod defined.
</xs:documentation>
</xs:annotation>
</xs:element>
testQueryString
Type:
xs:token, simple content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
Test data for exercising the service.
Annotation 2 [src]:
This contains data that can be passed to the interface to retrieve a non-empty result. This can be used by validators within test suites. Exactly how agents should use the data contained in the testQueryString depends on the concrete interface class. For interfaces employing the HTTP GET method, however, this will typically be urlencoded parameters (as for the application/x-www-form-urlencoded media type).
XML Source (see within schema source)
<xs:element maxOccurs="1" minOccurs="0" name="testQueryString" type="xs:token">
<xs:annotation>
<xs:documentation>
Test data for exercising the service.
</xs:documentation>
<xs:documentation>
This contains data that can be passed to the interface to
retrieve a non-empty result. This can be used by validators
within test suites.

Exactly how agents should use the data contained in
the testQueryString depends on the concrete interface class.
For interfaces employing the HTTP GET method, however,
this will typically be urlencoded parameters (as for
the application/x-www-form-urlencoded media type).
</xs:documentation>
</xs:annotation>
</xs:element>
testQueryString
Type:
xs:token, simple content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
Test data for exercising the service.
Annotation 2 [src]:
This contains data that can be passed to the interface to retrieve a non-empty result. This can be used by validators within test suites. Exactly how agents should use the data contained in the testQueryString depends on the concrete interface class. For interfaces employing the HTTP GET method, however, this will typically be urlencoded parameters (as for the application/x-www-form-urlencoded media type).
XML Source (see within schema source)
<xs:element maxOccurs="1" minOccurs="0" name="testQueryString" type="xs:token">
<xs:annotation>
<xs:documentation>
Test data for exercising the service.
</xs:documentation>
<xs:documentation>
This contains data that can be passed to the interface to
retrieve a non-empty result. This can be used by validators
within test suites.

Exactly how agents should use the data contained in
the testQueryString depends on the concrete interface class.
For interfaces employing the HTTP GET method, however,
this will typically be urlencoded parameters (as for
the application/x-www-form-urlencoded media type).
</xs:documentation>
</xs:annotation>
</xs:element>
testQueryString
Type:
xs:token, simple content
Defined:
locally within vr:Interface complexType
Annotation 1 [src]:
Test data for exercising the service.
Annotation 2 [src]:
This contains data that can be passed to the interface to retrieve a non-empty result. This can be used by validators within test suites. Exactly how agents should use the data contained in the testQueryString depends on the concrete interface class. For interfaces employing the HTTP GET method, however, this will typically be urlencoded parameters (as for the application/x-www-form-urlencoded media type).
XML Source (see within schema source)
<xs:element maxOccurs="1" minOccurs="0" name="testQueryString" type="xs:token">
<xs:annotation>
<xs:documentation>
Test data for exercising the service.
</xs:documentation>
<xs:documentation>
This contains data that can be passed to the interface to
retrieve a non-empty result. This can be used by validators
within test suites.

Exactly how agents should use the data contained in
the testQueryString depends on the concrete interface class.
For interfaces employing the HTTP GET method, however,
this will typically be urlencoded parameters (as for
the application/x-www-form-urlencoded media type).
</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/