Namespace: |
|
Content: |
complex, 2 attributes, 13 elements |
Defined: |
globally in VORegistry-v1.0.xsd; see XML source |
Used: |
never |
XML Representation Summary | |||||
<... | |||||
role | = |
xs:NMTOKEN | |||
version | = |
xs:string : "1.0" | |||
> | |||||
|
|||||
</...> |
Type Derivation Tree vr:WebService (extension) vg:OAISOAP |
<xs:complexType name="OAISOAP"> <xs:annotation> <xs:documentation> a description of the standard OAI PMH interface using a SOAP Web Service interface. </xs:documentation> <xs:documentation> the accessURL child element is the service port location URL for the OAI SOAP Web Service. </xs:documentation> </xs:annotation> <xs:complexContent> <xs:sequence/> </xs:extension> </xs:complexContent> </xs:complexType> |
Type: |
|
Use: |
optional |
Defined: |
<xs:attribute name="role" type="xs:NMTOKEN"> <xs:annotation> <xs:documentation> A tag name the 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 match 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> |
Type: |
|
Use: |
optional |
Default: |
"1.0" |
Defined: |
<xs:attribute default="1.0" name="version" type="xs:string"> <xs:annotation> <xs:documentation> The version of a standard interface specification that this interface complies with. When the interface is provided in the context of a Capability element, then the standard being refered to is the one identified by the Capability's standardID element. If the standardID is not provided, the meaning of this attribute is undefined. </xs:documentation> </xs:annotation> </xs:attribute> |
Type: |
vr:AccessURL, simple content |
Defined: |
<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 “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. </xs:documentation> </xs:annotation> </xs:element> |
Type: |
vr:AccessURL, simple content |
Defined: |
<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 “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. </xs:documentation> </xs:annotation> </xs:element> |
Type: |
vr:AccessURL, simple content |
Defined: |
<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> When more than one URL is given, each represents an alternative (i.e. mirror) endpoint whose behavior is identical to all the other accessURLs listed. </xs:documentation> <xs:documentation> Editor's note: this element assumes that all registered services are inherently web based. </xs:documentation> </xs:annotation> </xs:element> |
Type: |
vr:MirrorURL, simple content |
Defined: |
<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> |
Type: |
vr:MirrorURL, simple content |
Defined: |
<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> |
Type: |
vr:SecurityMethod, empty content |
Defined: |
<xs:element maxOccurs="unbounded" minOccurs="0" name="securityMethod" type="vr:SecurityMethod"> <xs:annotation> <xs:documentation> the mechanism the client must employ to gain secure access to the service. </xs:documentation> <xs:documentation> when more than one method is listed, each one must be employed to gain access. </xs:documentation> </xs:annotation> </xs:element> |
Type: |
vr:SecurityMethod, empty content |
Defined: |
<xs:element maxOccurs="unbounded" minOccurs="0" name="securityMethod" type="vr:SecurityMethod"> <xs:annotation> <xs:documentation> the mechanism the client must employ to gain secure access to the service. </xs:documentation> <xs:documentation> when more than one method is listed, each one must be employed to gain access. </xs:documentation> </xs:annotation> </xs:element> |
Type: |
vr:SecurityMethod, empty content |
Defined: |
<xs:element maxOccurs="unbounded" minOccurs="0" name="securityMethod" type="vr:SecurityMethod"> <xs:annotation> <xs:documentation> the mechanism the client must employ to gain secure access to the service. </xs:documentation> <xs:documentation> when more than one method is listed, each one must be employed to gain access. </xs:documentation> </xs:annotation> </xs:element> |
Type: |
xs:token, simple content |
Defined: |
<xs:element maxOccurs="unbounded" 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> |
Type: |
xs:token, simple content |
Defined: |
<xs:element maxOccurs="unbounded" 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> |
Type: |
xs:anyURI, simple content |
Defined: |
<xs:element maxOccurs="unbounded" minOccurs="0" name="wsdlURL" type="xs:anyURI"> <xs:annotation> <xs:documentation> The location of the WSDL that describes this Web Service. If not provided, the location is assumed to be the accessURL with "?wsdl" appended. </xs:documentation> <xs:documentation> Multiple occurrences should represent mirror copies of the same WSDL file. </xs:documentation> </xs:annotation> </xs:element> |
Type: |
xs:anyURI, simple content |
Defined: |
<xs:element maxOccurs="unbounded" minOccurs="0" name="wsdlURL" type="xs:anyURI"> <xs:annotation> <xs:documentation> The location of the WSDL that describes this Web Service. If not provided, the location is assumed to be the accessURL with "?wsdl" appended. </xs:documentation> <xs:documentation> Multiple occurrences should represent mirror copies of the same WSDL file. </xs:documentation> </xs:annotation> </xs:element> |
Type: |
xs:anyURI, simple content |
Defined: |
<xs:element maxOccurs="unbounded" minOccurs="0" name="wsdlURL" type="xs:anyURI"> <xs:annotation> <xs:documentation> The location of the WSDL that describes this Web Service. If not provided, the location is assumed to be the accessURL with "?wsdl" appended. </xs:documentation> <xs:documentation> Multiple occurances should represent mirror copies of the same WSDL file. </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:
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/ |