Taken from w3c schema for maxOccurs at: http://www.w3.org/2001/XMLSchema.xsd A simpleType to represent an email address. A simpleType to represent an xpath-type used for querying. A simpleType to represent an xpath-type used for querying. A simpleType to represent a URL that does a pattern match to verify a full URL without whitespace. Request message format. Must always contain and header and may or maynot contain a payload, based on the type of request being made. See if a resource is online. Request technical details about a resource/provider. Request human readable metadata about a resource or provider. A BioCASE scan. List of distinct value (pairs) Multiple concepts allowed to return a list of distinct combinations of values. SELECT DISTINCT A, B FROM ... A choice between the different subtypes of a search. Define a list of concepts to be treated as the base of a record. Use this concept if its repeatable or the closest repeatable parental element. Define a list of concepts to be treated as the base of a record. Use this concept if its repeatable or the closest repeatable parental element. Define your own structur how the data should be returned refering to known concepts of another schema. Inline request header used in request and response documents. Version and name of the software involed in editing the protocol document. E.g provider software, portal, proxy, ... Name and version of the software component being used by the software. The source of the request or response. Repeatable to trace back all servers of the cascading request. For search requests, it starts with the original requestor, the client. For all other requests and for responses, its the accessPoint of the host machine. Holds the IP of the source with the timestamp as an attribute in ISO format. The attribute-flag "original" can be used to indicate the first, original source in case the sequence is not reliable enough. The destination of the request or response. This will be the potentially multiple provider accesspoint(s) for requests and the single client for responses. Holds the IP of the destination. Information about the used content compression method. This will allow to compress the "content" part of a response but leave the protocol envelope readable. software without decompression routines can still pass the data on and read its desitnation and source. Define a list of concepts to be treated as the base of a record. Use this concept if its repeatable or the closest repeatable parental element. Define a custom structure for the returned content starting with a root element. An abstract element provided as a base to group all comparitive operator elements. The equals (=) comparator element. The less than (<) comparator element. The less than or equals (<=) comparator element. The greater than (>) comparator element. The greater than or equals (>=) comparator element. compares if concept(xpath) is null. use equal element to compare for empty strings ''. The like (LIKE) comparator element. The in (IN) comparator element. A logical operator clause. This is an abstract element to be substituted by concrete logical operator elements. The or logical operator. Response message format. The content of the response as requested. We use xsd:any as one choice because the content will be some XML that we do not know yet or that we will not know. Optionally (for all search and scan requests) the "recordCount" attribute should be set. It counts all records delivered in the XML document, while totalMatchedRecords refers to the records in the database that matched the request. If a DB record could not be converted to a valid XML "record", it might have been dropped completely and shows up in the attribute "recordDropped". 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? Information about supported featrures, methods and configurations parameters of a software (provider/resource/portal?) Information about the provider configuration for a resource. Information about the supported protocols this service understands. Information about the supported filter operators of this service. Information about the supported request types of this service. Information about the supported content compression methods. This will allow to compress the "content" part of a response but leave the protocol envelope readable. software without decompression routines can still pass the data on and read its desitnation and source. information about the supported and mapped conceptual schemas. holds the namespace of a supported schema. Each mapped/configured concept of a schema of this resource is listed here as a single concept returning a boolean flag if it is searchable. what security related capabilities does the provider have? encryption, access restriction, etc. or acronym ? another more general name for all rights related things? The inventory result for an inventory response. Envelope to list all concepts that have been used for the inventory response. Uses xml ID to reference them from the value element within a record. header row giving the concept for each value of the sequence within record below. A distinct combination of values for all "inventoried" concepts. The optional attribute "count" is used to count the number of occurences for this distinct combination and will only be set if the count flag was used when requesting an inventory. A single value for a single concept. The sequence of the values should correspond to the one given in the concept header row above. In case this cannot be guaranteed, the xml IDREF mechanism can be used to refer to a specific concept.