StandardsRegExt xs vstd This is a core schema for describing IVOA Standards themselves a description of a standard specification. This typically refers to an IVOA standard but is not limited to such. the version of the standard that is recommended for use. More than one version can be listed, indicating that any of these versions are recognized as acceptable for use. when present, this element indicates that all versions of the standard are considered deprecated by the publisher. The value is a human-readable explanation for the designation. The explanation should indicate if another standard should be preferred. a defined key associated with this standard. the IVOA status level of this verison of the standard. an IVOA Recommendation an IVOA Proposed Recommendation an IVOA Working Draft not an IVOA standard or protostandard at this time. A designation of preference for the version compared to other versions in use. the most preferred version. Only one version should have this designation. a versions whose use is now discouraged because a newer version is preferred. a description of a standard service protocol. This typically refers to an IVOA standard but is not limited to such. 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. A registered set of related keys. Each key can be uniquely identified by combining the IVOA identifier of this resource with the key name separated by the URI fragment delimiter, #, as in: ivoa-identifiery#key-name the name and definition of a key--a named concept, feature, or property. The name and definition of a key--a named concept, feature, or property. This key can be identified via an IVOA identifier of the form ivo://authority/resource#name where name is the value of the child name element. This type can be extended if the key has other metadata associated with it. The property identifier which would appear as the fragment (string after the pound sign, #) in an IVOA identifier. A human-readable definition of this property. reference that forces an IVOA ID with a # fragment part appended to match the standard pattern for registering enumeration values with a vstd:StandardKeyList the allowed characters for a fragment identifier taken from rfc2396