$Id: digir.xsd,v 1.8 2004/06/14 20:24:07 rdg Exp $ XML Schema specifying the DiGIR (http://digir.sourceforge.net) protocol. In specific, request and response message formats are defined, as well as some base datatypes to be used when defining a federation (or content schema) that defines the data to be exchanged. A simpleType to represent a URL that does a pattern match to verify a full URL without whitespace. A simpleType to represent an email address. Inline request header used in request and response documents. Version of the software running, as in beta3 or release 1.0. The time the request is being sent. The source of the request or response. For search requests, it is the IP of the original requestor. For all other requests and for responses, its the accessPoint of the host machine. The optional resource attibute should be set to the provider's resource code, in necessary. The destination of the request or response. This will be the provider accesspoint for requests and the portal for responses. The optional resource attibute should be set to the provider's resource code, in necessary. Type of operation being requested or being responded to. Request message format. Must always contain and header and may or maynot contain a payload, based on the type of request being made. A search operation, specifying query conditions and result details. Essentially, a representation of the "where" clause. An empty filter is prohibited in a search request. Specifies the columns and rows of the results to be returned. The element is optional because some requests may simply be for the count, which is specified by setting the count element to true. An inventory operation, which is to seek a count of all unique occurrences of a single concept. Query conditions can optionally be applied. Essentially, a representation of the "where" clause. The element is optional in an inventory request. The concept on which inventory information will be returned. For example, <darwin:Genus/>. The concept should always be left empty in the request. Essentially, a representation of the "where" clause as a tree. An abstract element provided as a base to group all types of data. It is not expected that a concrete element of this level will ever be made. An abstract element provided as a base to group all types of searchableData. The element is to be substituted by concrete elements that are searchable (but not also returnable), in federation/conceptual schema documents. An abstract element provided as a base to group all types of returnableData. The element is to be substituted by concrete elements that are returnable (but not also searchable), in federation/conceptual schema documents. An abstract element provided as a base to group all types of searchableReturnableData. The element is to be substituted by concrete elements that are both searchable and returnable, in federation/conceptual schema documents. An abstract element provided as a base to group all comparitive operator elements. An abstract type provided as a base from which to derive all comparitive operator types. The equals (=) comparator element. The equals (=) comparator type. Can take any type of searchableData for an exact match. The not equals (!=) comparator element. The not equals (!=) comparator type. Can take any type of searchableData. The less than (<) comparator element. The less than (<) comparator type. Can take any numericSearchableData. The less than or equals (<=) comparator element. The less than or equals (<=) comparator type. Can take any numericSearchableData. The greater than (>) comparator element. The greater than (>) comparator type. Can take any numericSearchableData. The greater than or equals (>=) comparator element. The greater than or equals (>=) comparator type. Can take any numericSearchableData. The like (LIKE) comparator element. The like (LIKE) comparator type. Can take any alphaSearchableData. An abstract type provided as a base from which to derive all multi-element comparitive operator types. The in (IN) comparator element. The in (IN) comparator type. Can take list, as defined within a federation schema as a choice of concrete searchableData. A logical operator clause. This is an abstract element to be substituted by concrete logical operator elements. The logical operator defined type. An LOP can contain 2 of either COPs or LOPs (i.e. LOPs can be nested). The and logical operator. The and logical operator type. The and not logical operator. The and not logical operator type. The or logical operator. The or logical operator type. The or not logical operator. The or not logical operator type. A type to be used to denote a contact, as in a administrative or technical contact for a provider or a resource. Full preferred name of the contact. Optional title of the contact. Valid email address of the contact. Full international phone number of the contact. A type to be used to denote a contact person. Contacts may be administative, technical, or other. Administrative contacts are those to whom questions and feedback about data, or restrictions on use of the data should be directed. Technical contacts are those to whom questions about accessibility of a provider or resource should be directed. A container for provider metadata used in a response element. A DiGIR provider. The common name of the provider. The URL at which the provider can be accessed. If the provider is registered in the central registy, this value corresponds to the value in the registry. The implementation, as in Java 2 SDK 1.4.0 or PHP 0.3.1. Location where the software is run. Common name of the host. For example, Museum of Vertabrate Zoology. Known code/abbreviation for the host. For example, MVZ. Location of information about the host. Should be a full URL. For example, http://www.mip.berkeley.edu/mvz/. Contact(s) for the host. This information may be made publically available by the portal. A description of the host. An individual resource (collection) hosted by the provider. Two highly desired elements under resource that have not been included are taxonomicScope and geographicScope. They should be added once a systematic way to generate and index their values is discovered. The common name of the resource. For example, "Mammal Specimen Collection". Identifier/abbreviation for the resource. For example, Mammals Location of information about the resource. Should be full URL. For example, http://www.mip.berkeley.edu/mvz/collections/SpecialCollections.htm. Contact(s) for the resource. This information may be made publically available by the portal. A description of the resource. Keywords for the resource. For example, "vertebrates, photographs, field notebooks, correspondence". How to cite information retrieved from the resource. Any restrictions regarding the use of information retrieved from the resource. The namespace, and corresponding schemaLocation the resource understands/supports. A resource can support N schemas, including multiple versions of the same schema. In any case, the host of the resource must be able to understand them as well. An identifying code that can be recognized in the records of the resource. Often this is the combination of the hostCode and resourceCode. For example, "MVZ Hild". The type of records available. For example, voucher or observation. The number of records available. The dateTime the resource was last updated. The minimum number of characters that can appear in a query term. The maximum number of records that can be returned in a search response. The maximum number of records that can be returned in an inventory (scan) response. Response message format. The content of the response, as in the search results or status information. We use xsd:any because the content will be some XML that we do not know yet or that we will not know. The element is optional because certain types of request deliver all their response by way of the diagnostics. The diagnostics element can contain many diagnostic pieces of information. Should the possible diagnostic codes/messages be defined more granularly in a seperate XML Schema? Holds N response elements.