accessURL (type vr:AccessURL), mirrorURL (type vr:MirrorURL),

securityMethod (type vr:SecurityMethod), testQueryString (type xs:token)

within vstd:ServiceStandard complexType [def]

an abstract description of one of the interfaces defined by this service standard.

This element can provide details about the interface that apply to all implementations. Each interface element should specify a role with a value starting with "std:" or, if there is only one standard interface, is equal to "std".

Applications that, for example, wish to build a GUI to the service on-the-fly would first access this generic description. Site-specific variations, such as supported optional arguments or site specific arguments, would be given in the actual implemented service description and overrides any common information found in this generic description. This generic interface description can be matched with the site-specific one using the role attribute.

Even though the Interface type requires an accessURL child element, this element is intended to describe a service in the abstract--i.e. without reference to a particular installation of the service. Consequently, the accessURL may contain a bogus URL; applications should not expect it to be resolvable.

within vr:Capability complexType [def], within vr:Capability complexType [def], within vr:Capability complexType [def]

a description of how to call the service to access this capability

Since the Interface type is abstract, one must describe the interface using a subclass of Interface, denoting it via xsi:type.

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.

Type:	xs:NMTOKEN
Use:	optional
Defined:	locally within vr:Interface complexType

<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>

Type:	xs:string
Use:	optional
Defined:	locally within vr:Interface complexType

<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>

Type:	vr:AccessURL, simple content
Defined:	locally within vr:Interface complexType

<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>

Type:	vr:MirrorURL, simple content
Defined:	locally within vr:Interface complexType

<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:	locally within vr:Interface complexType

<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>

Type:	xs:token, simple content
Defined:	locally within vr:Interface complexType

<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>