complexType "vr:Interface"

Namespace:	http://www.ivoa.net/xml/VOResource/v1.0
Content:	complex, 2 attributes, 4 elements
Abstract:	(cannot be assigned directly to elements used in instance XML documents)
Defined:	globally in VOResource-v1.1.xsd; see XML source
Includes:	definitions of 2 attributes, 4 elements
Used:	at 12 locations

XML Representation Summary

<...

role

xs:NMTOKEN

version

xs:string

Content:

accessURL+, mirrorURL*, securityMethod*, testQueryString?

</...>

Content Model Elements (4):

Known Direct Subtypes (11):

Known Indirect Subtypes (1):

All Direct / Indirect Based Elements (1):

Known Usage Locations

In derivations of other global types (11):

OAIHTTP (as extension base),

ParamHTTP (as extension base),

StreamEndpoint (as extension base),

vr:WebBrowser (as extension base),

vr:WebService (as extension base),

vr:WebService (as extension base)

As direct type of elements (1):
interface (type vr:Interface)

A description of a service interface.

Since this type is abstract, one must use an Interface subclass to describe an actual interface.

Additional interface subtypes (beyond WebService and WebBrowser) are defined in the VODataService schema.

XML Source (see within schema source)

<xs:complexType abstract="true" name="Interface">

<xs:annotation>

<xs:documentation>

A description of a service interface.

</xs:documentation>

<xs:documentation>

Since this type is abstract, one must use an Interface subclass
to describe an actual interface.

</xs:documentation>

<xs:documentation>

Additional interface subtypes (beyond WebService and WebBrowser) are
defined in the VODataService schema.

</xs:documentation>

</xs:annotation>

<xs:sequence>

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

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

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

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

</xs:sequence>

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

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

</xs:complexType>

Attribute Detail (all declarations; 2)

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

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.

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>

</xs:documentation>

<xs:documentation>

</xs:documentation>

</xs:annotation>

</xs:attribute>

Type:	xs:string
Use:	optional
Defined:	locally within (this) 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>

</xs:documentation>

</xs:annotation>

</xs:attribute>

Content Element Detail (all declarations; 4)

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

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

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>

</xs:documentation>

</xs:annotation>

</xs:element>

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

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

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>

</xs:documentation>

</xs:annotation>

</xs:element>

Type:	vr:SecurityMethod, empty content
Defined:	locally within (this) vr:Interface complexType

The mechanism the client must employ to authenticate to the service.

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>

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

Test data for exercising the service.

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>

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