$Id: esp.xsd.txt,v 1.91 2007/06/04 19:24:27 fasten Exp $ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA http://www.gnu.org/licenses/licenses.html#GPL An identifier for implementation levels, labels and signs. A path of identifiers, separated by slashes. A prefix for a path, usually a namespace selector. A path of identifiers, separated by slashes, with a prefix, separated by a colon. Possible strategies for synonym resolution: "outgoing only" means synonyms can point into other namespaces but synonyms from other namespaces cannot point into the this one. "listed namespaces only" means synonyms from other namespaces can point into this namespaces only if they are referred to by this namespaces (with the element "synonym-ns" to CategoryNamespace) "intransitive" means other namespaces can point into this namespace but the synonyms of entries of other namespaces are not automatically assumed to be synonyms to entries of this namespace. "no amalgamation" means other namespaces can point into this namespace as long as that does not lead to amalgamation of entries in this namespace. "unrestricted" means other namespaces can point into this namespace without restrictions. The result of synonym resolution for other namespaces is that a search for something categorized as B from namespace NS2 may be resolved to something categorized as A from namespace NS1 when A refers to B as a synonym and synonym resolution rules allow it to be resolved; searching for objects categorized as A will always find objects categorized as B because that reference is explicit and synonym resolution only applies to implicit references, e.g. backward resolution and indirect resolution. A two or three letter acronym used for ISO 3166-1 country codes. A non-zero number of digits. A continent name. A trade zone. A currency type. The certification requirement level of different implementation levels of a policy can be "none", "available" or "required", which means no certification is available, certification is available and certification is required at the corresponding implementation level. Possible extension or implementation categories are "free", "revocable", "on request", "certification available", "certification depends on implementation level", "certification required" and "private". "free" means the policy can be extended without pior consent. "revocable" indicates a policy may be freely extended or implemented but is revocable by the authoring group and, possibly, third parties. "on request" means the policy can only be properly implemented with the consent of the authoring group. A certification may not be required but implementation can be denied. "certification available" means a certification is possible but not required. "certification depends on implementation level" means that the policy has implementation levels that require certification. "certification required" means certification is generally required. "private" indicates policies that are not for public re-use. The operator of a PolicyMatchGroup, either "all", "one" or "none". This is equivalent to the common choice "with all of the words", "with at least one of the words" and "without the words" in search engines' input masks but concerning policies here. Possible policy classes are "policy scheme", "extendable policy" and "final policy". Policies can extend policy schemes and policies can extend other policies. Final policies cannot be extended. The geographical latitude of a geographical coordinate (Lat. N + > 0, Lat. S - < 0). The geographical longitude of a geographical coordinate (E + > 0, Long. W - < 0). A revision number of the form "(year).(revision)" The available signature types, currently only OpenPGP. The type of an advertisement: "sale", "sharing pool", "service", "lodging", "auction", "short-term resale", "medium-term resale", "long-term resale" "sale" indicates a first hand sale. "sharing pool" indicates a pool of objects available for lending. "service" indicates a service being advertised. "lodging" indicates the availability of a lodging opportunity. "auction" indicates an object will be auctioned. "short-term resale" indicates intend of resale within 1 month. "medium-term resale" indicates intend of resale within 6 month. "long-term resale" indicates intend of resale after 6 month or more. "long-term resale" may also be used to indicate that an object has been newly acquired with the intend to sell it before its expiration but possibly several years later. The offer can be "private", "commercial", "community". "private" indicates an offer by an individual. "commercial" indicates an offer by a commercial entity. "community" indicates an offer inside a community that may not be available outside the community. The type of keyword match: "all", "exact", "any", "without". This is equivalent to the common choice "with all of the words", "with exactly the words", "with at least one of the words" and "without the words" in search engines' input masks but concerning policies here. see also: PolicyMatchOperator A general classification for the type of organization, one of "coop", "NGO", "LLC", "company", "association", "government agency", "statutory corporation", "working committee", "individual" or "other". A classification for the type of trade register or association register, one of "gov. trade register", "gov. association register", "NGO registry", "chamber of commerce", "chamber of crafts", "tax and revenue office", "membership register", "social security", "health insurance" and "passport registration office" The last three are only applicable for individuals. A list of 2 or 3 letter ISO 639 language codes, e.g.: "br,en,ban,fr,ja,nl,pt,sa,zh" An ISO 3166-2 region code, an esp native region code or an UN location code. The ISO 3166-2 region code cannot be recommended here, as it is not freely available. An UN location code may be used to specify a location within a region as a reference to that region. (see http://www.unece.org/cefact/locode/). Specifying an ISO 3166-2 code requires the prefix "iso:", so an actual code would be "iso:us-ca". An UN location code requires the prefix "locode:", so an actual code would be "locode:de-cgn". A list of valid esp native region codes is available at http://esp.nongnu.org/xml/regions.xml.txt.gz There is no prefix required, e.g.: "de-nrw", "lu-*" or "us-ca". The reason for the presence of region codes in this draft is that the use of mandatory region codes makes address information more redundant and region codes allow more fine grained regional searches than the use of country codes. An UN location code may be used to specify a location or the closest location that does have an UN location code. (see http://www.unece.org/cefact/locode/) A telephone area code in the format: +49-221. Phone numbers within an element that contains an area code attribute may omit the area code, otherwise every phone number has to include an areaCode attribute. This is always required for mobile phones, 0800 numbers and other numbers that do not have an area code prefix. A general classification for a web page: "homepage", "sitemap", "press releases", "history/profile" "rss news feed", "information retrieval", "imprint", "forum" or "3rd party information" This could become a CategoryNamespace in future. A general classification for a phone number: "reception", "office", "hotline", "service", "mobile", "fax", "private" or "other". A general classification for an email address: "general", "customer service", "webmaster", "press contact", "legal department", "complaint", "office", "editorial department", "private", "other". This could become a CategoryNamespace in future. A restricted type that matches email addresses. A base64 encoded secure hash code. Currently only SHA1 is allowed. This is not security relevant, it is supposed to promote immutability of policies. A policy should be considered immutable once published and a successor should receive a different name. An OpenPGP fingerprint. The quality of a geographic coordinate, either one of "exact", "block", "house number approximation", "street", "postal code", "district", "city", "region", "country" or "+-10^[1-9]m". A severity rating for a problem or incident: "critical", "severe", "serious", "noteworthy", "intermediate", "harmless", "insignificant". A similar rating scheme for product quality has been omitted because it is to weak to be of any use as a product rating. The problem to be solved lacks generally accepted units of measurement and is not one-dimensional. The type EvaluationScheme addresses the problem instead. A source element for HTML meta data. The meta data can be inserted into statically and dynamically generated HTML pages generated from a document based on this schema. The element attributes are equivalent to the attributes of the corresponding HTML element. A source element for HTML meta data. The element attributes are equivalent to the attributes of the corresponding HTML element. A header for document meta data and categorization. Categories can be transformed to HTML meta data but the preferred format to specify categories in ESP is to use the "categories" element. Categories encountered in a "Meta" attribute SHOULD be ignored and be replaced with properly specified categories. The following tags SHOULD be generated: "expires", "rfcNNNN.cat" Categories MUST be converted to HTML meta data by converting namespaces to LINK tags and category references to META tags: <link rel="rfcNNNN.ns" id="<prefix>" href="<namespace url>"> <meta name="rfcNNNN.cat" content="<prefix>:<path>"> This may be modified for Dublin Core compatibility in future. The namespaces used for META tags SHOULD be categorized as either "information/content" or "information/meta", according to the category namespace "http://esp.nongnu.org/ns/category/2005.1". A complex type that can contain plain text, HTML formatted text or elements following another XSD schema, that is outside the scope of this draft to define. The "schema" attribute MUST refer to an XSD schema if the content of the message is in XML format. The targetNamespace of the schema referred to by the "schema" attribute may be useful to select applicable xslt stylesheets from local system or user preferences. The "xsltStyleSheet" attribute MAY refer to a recommended stylesheet that can be used to format the content of the message to HTML. The "mimeType" attribute MUST specify the mime type of the content. A type of currency that is accepted. The "url" attribute may refer to the web page of a community currency or other medium of exchange. A telephone number with a separate area code or an internet telephone contact. A web page with name, url and type. A phone contact with type, name, number and an email address to negotiate calls or to avoid calls to this number. An email address with type, name and the actual email address. A reference to translations of the containing document. The URL of a translation is the concatenation of the "baseUrl" attribute and a language code mentioned by the "translations" list. An area can be described as a polygon of coordinates (specified by "point" elements) or it can be described by "region", "country", "continent" or "tradeZone" elements. The "radius" attribute specifies the radius in kilometers around given points that is part of the area, with the perimeters between points shifted outwards by the radius length parallel to the corresponding connecting lines at radius zero. Specifying points and regions (or countries) restricts the area described as a polygon to the given regions (or countries). Specifying either "continent" or "tradeZone" makes the area exactly the area of the specified continent or trade zone. A set of service information. The "area" element describes the area of service. The "group" element describes the services offered. The ReferenceGroup MUST refer to category namespaces of type "offering/service", according to category namespace "http://esp.nongnu.org/ns/category/2005.1". Geographic coordinates. An address with optional contact information and coordinates. The element "supplement" can be used to specify any type of the address that does not fit the standardized fields. The "since" attribute can be used to specify since when the address is valid or will become valid. The "until" attribute can be used to specify when the address becomes invalid or has become invalid. An address pattern. All attributes and elements that are present correspond to attributes and elements of the same name in the Address type but no attribute or element is mandatory. A membership organisation. A range of dates. A ticket search request that may be sent with a HTTP POST request to the URL given as the "view" attribute of a ticket system. All attributes that may be specified more than once match a ticket when one of the specified values matches a given ticket. The "refersTo" element is a list of URIs to be matched against the "uri" elements in a Ticket. A ticket submission interface. The URL given as the "url" attribute to the "ticket" element MUST react to HTTP GET requests by displaying human readable content and MUST be able to receive HTTP POST requests that deliver a properly XML formatted Ticket and MUST respond with an XML formatted Receipt. If more than one "login" element is given all ticket URLs MUST be able to accept any choice of login. The URL given as the "view" attribute MUST react to HTTP GET requests by displaying human readable content and MUST be able to receive HTTP POST requests that deliver an XML formatted TicketSearchRequest and respond with a XML formatted TicketList. If ticket systems share logins a single identity provider can allow to log in to all sites using the same provider. This is only intended to prevent abuse of the ticket system, not necessarily to be very secure. Ticket submission MAY also require a prior login at the url given as the identityProvider attribute of the login element. A login MAY require the use of HTTP cookies. A ticket system MAY offer NNTP access by specifying an additional "nntp" attribute. The "type" attribute MUST be a reference to a CategoryNamespace of type "ticket/type", according to the category namespace "http://esp.nongnu.org/ns/category/2005.1". If posting to the ticket system requires a special editor to fill in the required elements of an XSD schema conveniently the "editor" attribute MUST refer to this editor. A digital identity. Currently the only type of identity supported is an OpenPGP fingerprint. Contacts grouped by region. To specify contacts in more than one region one Contacts element per region MUST be specified. A register, e.g. a trade register. Individuals may specify the registry type "passport registration office" and use their passport number as the registration number. Some registrars, for example health insurance companies in Germany, have an assigned number that is required as a namespace in which the assigned number is unique. (see http://de.wikipedia.org/wiki/Institutionskennzeichen) This number can be specified as the "registrarIdentityNumber" attribute. Sometimes registry numbers include a registry identity number; this number SHOULD be dublicated as the "registrarIdentityNumber" attribute, without removing it from the number attribute. The registrar identity number is usually assigned by a government agency, which SHOULD be specified as a registrar to this registrar, if known. The "search" attribute, if present, MUST contain an url that accepts HTTP POST requests containing SearchParameters and responds with SearchResults. The scope of the search MAY be limited to entities registered with that registry. A search pattern for a register, e.g. a trade register. A certification URL. The URL is expected to refer to a human readable web page or an XML formatted annotation of the type "certificate". An organizational unit. OrganizationalUnits may form hierarchies with the innermost OrganizationalUnit being the organizational unit referred to, e.g.: UN ( orgUnit=ECOSOC ( orgUnit=UNESCO )). An organizational entity search pattern. All attributes and elements that are present correspond to attributes and elements of the same name in the Entity and AuthenticEntity types but no attribute or element is mandatory. An organizational entity with a name, address, any number of service namespaces and certifications. This entity may not have an identity or register number, for example if the entity is a trade register that does not have a register number itself. The "since" attribute and the "birthday" attribute are synonyms. The "imprint" attribute, if present, MUST refer to an imprint following the ESP scheme. When no organization exists an individual can publish an imprint with the register type "passport registration office". Further register types for individuals may be added as required. An organizational entity with a name, address, register number, any number of service namespaces and certifications. This entity MUST have a register number and an identity. The "since" attribute and the "birthday" attribute are synonyms. The "imprint" attribute MUST refer to an imprint following the ESP scheme. A PolicyMatchGroup is a collection of PolicyReferences and further PolicyMatchGroups. Every group can require that all its elements match ("all") or that one of its elements matches ("one"). A group that has a name can be referred to in further groups only by that name, omitting the operator, policies and groups. PolicyMatchGroups specified in a community's SearchProfile may be used by name in a personal SearchProfile, as the Community SearchProfiles referred to are effectively included at the beginning of the personal search profile. This allows a community to specify search criteria for users of the community's profile without making them requirements for all members of the community. A PolicyReference is a reference to a policy, given by the "url" attribute. The content of the URL MUST be a PolicyDocument. The "level" attribute is an implementation level of the PolicyDocument the URL refers to. Specifying a URL that does not refer to a PolicyDocument or a level that is not an implementation level of that PolicyDocument is an error. The "info" and "comment" elements allow to annotate a reference to a policy. The "type" attribute MUST be a reference into a CategoryNamespace, which SHOULD be the default namespace for policy categories. The namespace MUST be categorized as "policy/type" according to the category namespace "http://esp.nongnu.org/ns/category/2005.1". A policy group is a collection of policy statements that have a common topic. The grouping allows to display policies as directory trees and serves only the purpose of navigation by the end user. A policy statement is a reference to a policy, given by the "url" attribute. The content of the URL MUST be a PolicyDocument. The "level" attribute is an implementation level of the PolicyDocument the URL refers to. Specifying a URL that does not refer to a PolicyDocument or a level that is not an implementation level of that PolicyDocument is an error. The "Certification" element, if present, refers to a certificate that documents adherance to the specified policy. The "type" attribute of a policy statement together with the "type" attribute of the enclosing policy group must match the type of the policy it refers to. This is redundant and allows to verify the type safety and integrity of the reference. The "info" and "comment" elements allow to annotate a reference to a policy. The "type" attribute MUST be a reference into a CategoryNamespace, which SHOULD be the default namespace for policy categories. The namespace MUST be categorized as "policy/type" according to the category namespace "http://esp.nongnu.org/ns/category/2005.1". A digital signature. The type of signature MUST be OpenPGP. The signature signs the previous non-signature XML element, starting with the opening angular bracket and ending with the closing angular bracket. An online or offline community that may recommend certain ethical standards. The "profile" element refers to a search profile specifying ethical requirements of the community. A community may have more than one profile. "profile" elements in a Community may refer to further profiles offered by a community. These profiles are for documentation only and are not applied unless referred to by a SearchProfile. The "prefix" attribute specifies a prefix that may be used to prefix any references to PolicyMatchGroups imported from this profile. A prefix is prepended to a name with a separating colon in between: <prefix>:<name>. The "categories" element, if present, specifies a categorization for the community. The default namespace with the empty prefix (":") refers to "http://esp.nongnu.org/ns/community/2005.1". The ReferenceGroup MUST refer to category namespaces of type "community", according to category namespace "http://esp.nongnu.org/ns/category/2005.1". Filters can be applied by the search engine or by the user application to reduce search results. Filtering continues until the search result is reduced below the number of desired maximum matches. Filtering is terminated with the result of the last filter processed as the end result when less than the desired number of minimum matches remains. A reference to a namespace document. The "prefix" attribute is a prefix to be assigned to the namespace referenced by the "ns" attribute. A prefix of length zero is valid and allows a path, that is abbreviated with this prefix, to begin with a colon. The "name" attribute is an arbitrary name that may explain the purpose or context in which the namespace is referred to. A group of references into a namespace. The "ns" element is a URL to a namespace document (containing a CategoryNamespace) and the "path" attribute of the "ref" element is a prefixed path within a document, each Identifier corresponding to a product group, service group or other directory entry. The optional "url" attribute may be used when the context requires a reference to further information, e.g. a reference to a human readable web page inside the ServiceInformation type, further describing a service offered. The "name" attribute is an arbitrary name that may explain the purpose or context in which the group is used. A reference into a namespace. The "ns" attribute is a URL to a namespace document (containing a CategoryNamespace) and the "ref" attribute is a slash separated path of Identifiers within that document, each Identifier corresponding to a product group, service group or other directory entry. A namespace document specifying categories. A namespace provider can be an open service, like dmoz.org, or any other entity that maintains a list of categories. In the case of product group categories these might be standardization organi - zations or consumer protection groups. In the case of service categories these might be yellow pages services, chambers of commerce or trade registers. The last part of the URL of a CategoryNamespace document SHOULD be it's revision number. The revision number of a category namespace SHOULD be changed when structure is removed from the namespace. The revision number of a category namespace SHOULD NOT be changed when structure is added to the namespaces, this includes "deprecated" and "redirect" attributes of categories. The reason for this is that removing structure can invalidate references into the namespace while adding structure cannot. When structure is removed it is beneficial that older references keep referring to the old structure. The "include" element refers to another CategoryNamespace of the same type that is included as a subtree under the root. The "synonym-ns" elements refer to other namespaces that are used to define synonyms for categories (see Category). A category is an element of a CategoryNamespace that can be referred to by a PrefixedPath. The namespace prefix is separated with a colon (":") and category labels use the slash ("/") as the separator character. Path examples could be "<ns>:MyServiceNS:craft/carpentry" for a service category or "<ns>:MyProductNS:power source/solar power/solar cells" for a product category. The "label" attribute specifies the label of the category which forms a path together with the labels of enclosing categories. The "url" attribute may point to a more elaborate description of the category. The "redirect" attribute in connection with a "deprecated" attribute means the category has been moved or replaced by another category. The "redirect" attribute alone means the category is intended as a reference to another category. The "include" element refers to another CategoryNamespace of the same type that is included as a subtree under the Category the include appears in. The "synonym" references refer to categories in other namespaces, given by the "synonym-ns" element of the enclosing CategoryNamespace. A matching URL. The quality is a relative rating that can be defined by the search engine operator. The links attribute gives the number of pages that link to this page. The about attribute gives the number of pages that are about this page, referring to it with a (link rel="about" href="URL") tag in the HTML header. Search engines MAY evaluate the meta tag "(prefix):about/digest/sha1" (see "Header") and expire links that no longer refer to the original content. The annotations attribute gives the number of annotations for this URL. Annotations in this context are only XML formatted objects that follow this XSD Schema and contain an Annotation type. A match contains the matching entity and a service description. Service types are contained in service type namespaces, which are to be specified by service type namespace providers, e.g. a chamber of commerce or a yellow pages service. It may also contain any number of urls that match further search criteria, e.g. textual search criteria or service description criteria. A link to a categorized piece of information or offering. The "uri" attribute contains the url of a web page that a link or annotation refers to. The "productGroup", "serviceType" or "lodgingCategory" attributes indicate that a matching object must be an Avertisement of corresponding type, in which case the "uri" attribute is ignored. The "categories" element specifies further required categories of the object that is being referred to. The "votingScheme" attribute restricts results to Annotations or Advertisements referring to the given VotingScheme. A collection of common web search parameters. All elements that are specified add cumulative restrictions. The search for meta tags is supposed to allow searching for information categories from namespaces of type "information/content" and "information/meta", and searching for pages that specify <link rel="about" href="URL">, <link rel="copyright" href="URL"> (e.g. for http://creativecommons.org/) The elements linksTo and annotates allows to search for pages that link conventionally to the given URL or that annotate the given URL with an ESP Annotation. The element advertisement allows to search for Advertisements. A collection of common organization and service search parameters. All elements that are specified add cumulative restrictions. From each "service" element specified at least one service must match a service offered by an entity in the search result. The "services" ReferenceGroup MUST refer to category namespaces of type "offering/service", according to category namespace "http://esp.nongnu.org/ns/category/2005.1". A set of standard search parameters. The "result" and "restrictions" attributes can specify constraints, like the mininum and maximum numbers of hits, and the regions, countries, languages and sites to be considered. A request to store the result for future retrieval until a given date can be specified by the "keepResultUntil" attribute. If a "destination" attribute is specified either the "searchRadius" attribute MUST by present and specify the search radius in kilometers or the "serviceArea" attribute MUST indicate that only services with a defined service area that contains the destination should be returned. It is allowed to specify both attributes, in which case the searchRadius is a filter for the maximum distance between the service's point of origin and the destination. Specifying web search parameters and organization search parameters restricts the search to web pages of organizations who match the given organization search parameters while organization search parameters alone SHOULD only return the explicitly listed web site addresses of those organizations. The "profile" element allows to specify a search profile. Any search profile retrieved from a URL MAY be cached by the search engine for as long as HTTP expiration rules indicate. The "modified" attribute can be used to indicate that a profile may have been modified within that period. A profile that can be specified as an additional search criterion for search engines that support searching based on esp. The search profile can refer to policy schemes instead of policies, in which case all derived policies will be matched. The "include" element allows to include any number of further profiles into the specified profile. The included profiles MUST be retrieved and SHOULD be cached by a search engine. A SearchProfile that specifies a Community SHOULD only be considered a profile of that community if signed by the community, otherwise the profile SHOULD be considered an anonymous search request. The "url" of a profile SHOULD specify the original URL of the profile, if the profile is publicly available. The "apply" attribute decides wether the criteria specified in the search profile are actually applied or only evaluated to define named PolicyMatchGroups that can be reused by other search profiles. The mime type for esp profiles is application/x-esp-profile. The standard result format for searches based on esp. The number of results is the total number of matches for the given criteria and community, no filters applied. The result may be stored for retrieval by third parties under the URL specified by the attribute "url" and until the date given in the "until" attribute. When an error attribute is present an error occured and the error attribute specifies the error in detail. The "ns" element MUST be used to abbreviate service names in the following match elements. If posting to a Forum or AnnotationSpace requires a special editor to fill in the required elements of an XSD schema conveniently this type MUST refer to an editor implemented as a Java Applet, Java WebStart or similar application. The editor MUST NOT require a remote service to function. The editor MAY interact with services exposed by the web browser, as, for example, the NNTP reader and NNTP posting. Specifying the interface for service exposure is beyond this draft to specify. An internet forum. A forum may share an NNTP server with a TicketSystem and/or AnnotationSpace. A suggested hierarchy for the NNTP server is "(lang.)(name.)ticket.*", "(lang.)(name.)forum.*" and "(lang.)(name.)annotations.*". The "url" attribute refers to a web page that allows to access the forum as a web forum. If posting to the forum requires a special editor to fill in the required elements of an XSD schema conveniently the "editor" attribute MUST refer to this editor. A storage space for Annotations. Annotations can be stored as web pages on a web server, as NNTP messages in an NNTP server or in a dedicated database. The "url" attribute specifies a login web page for visitors of the annotation space. The "nntp" attribute specifies an NNTP server, if available. The "index" attribute specifies an index suitable for search engine crawlers, e.g. a web page of daily indices containing new additions. If posting to the annotationSpace requires a special editor to fill in the required elements of an XSD schema conveniently the "editor" attribute MUST refer to this editor. An AnnotationSpace SHOULD be able to store Advertisements. A voting scheme is a list of votes and possible choices for each vote. If an "until" attribute is given a voting is considered closed at the given date and time. The "info" and "results" pages MAY refer to human readable web pages. If the URL of a voting scheme is changed this creates a new voting. The type evaluation scheme has the same elements and attributes as the type VotingScheme but some attributes have been removed. The different purposes made it seem likely that future additions would further separate both types. The "expire" attribute has been removed from VotingScheme. An evaluation scheme remains valid until its expiration date, given by the "expire" attribute. Annotations referring to an evaluation scheme MUST expire before the evaluation scheme or on the same day as the evaluation scheme. A single vote. The mime type for esp advertisements is application/x-esp-advertisement. The "evaluationScheme" attribute, if given, MUST refer to a EvaluationScheme suitable for product evaluation. The "url" attribute is the URL of this annotation. An annotation that has already been posted to another annotation space SHOULD be posted with the url of its initial posting, an annotation that has not yet been posted MUST be posted without a "url" attribute. The annotated element is a list of URIs of what is annotated, which may be annotations again. The format of the message is outside the scope of this draft but XSD schemata for product reviews or other specific annotations might be a good idea. The "uri" element(s) contain(s) a group of URLs and/or URNs. An annotation or ticket may contain both URLs and URNs if, for example, a product or product group has one or more product description pages of the vendor and one or more URN references (e.g. "URN:EAN:(ean number)"). When the annotation type is "vote" an annotation MUST contain votes according to the voting scheme given by the "votingScheme" attribute, otherwise it MAY have a voting scheme. A product review, for example, may evaluate a product according to a voting scheme. Product reviews MUST have a "productGroup" element and it MUST be a reference into a category namespace of type "offering/product", according to category namespace "http://esp.nongnu.org/ns/category/2005.1". The "type" element MUST be a reference into a category namespace of type "annotation", according to the same super category namespace. The mime type for esp annotations is application/x-esp-annotation. A list of tickets. The tickets in a list SHOULD NOT contain message bodies but all other attributes and elements may be supplied. Tickets in a TicketList MUST contain the attributes "ourSign", "url" "sent", "type", "status", "severity" and "subject". When an error attribute is present an error occured and the error attribute specifies the error in detail. A standard ticket format that can be submitted to all ticket queues specified in esp based imprints. The advantage of posting a ticket over sending an email is that the ticket is digitally signed, a receipt is returned for the ticket and the ticket format allows to add esp related information in their corresponding xml representation in a way that will be human readable for the recipient of the ticket and can be used for further automatic processing at the same time. The format of the message is outside the scope of this draft but the specification of XSD schemata for specific messages seems adequate. The attribute "annotation" is to be used when the ticket refers to an annotation. Annotations can also be forwarded as tickets in which case the "annotated" element is used instead. The url attribute is the url of the ticket, this is decided by the receiving ticket system and MUST NOT be specified when submitting a ticket. The sent and status attributes SHOULD be decided by the receiving ticket system. A history MAY be specified when submitting tickets to indicate that a ticket has already passed another ticket system. A ticket that has been externally forwarded and has the status "ext. forwarded" or "reply pending" SHOULD contain a "forwarded" URL, pointing to the instance of the ticket in the destination ticket system. A ticket that is being forwarded to another ticket system and changed to state "reply pending" MUST contain a "reply" element with the "pleaseReply" attribute set to "true" and the "url" attribute set to a URL of the transfering ticket system where the ticket can be posted to with a HTTP POST request and will be recognized as the returning ticket. The "avoidReply", if set to true, is the request to avoid a reply, if possible. The "uri" element(s) contain(s) a group of URLs and/or URNs. An annotation or ticket may contain both URLs and URNs if, for example, a product or product group has one or more product description pages of the vendor and one or more URN references (e.g. "URN:EAN:(ean number)"). The "ourSign" and "yourSign" attributes of a ticket MUST always be relative to the sender and receiver of a ticket. A ticket that has been externally forwarded will consequently need more than one "yourSign" attribute in the internal data structure of a ticket system. The "status" attribute MUST be a reference into a category namespace of type "ticket/status" and the "type" attribute MUST be a reference into a category namespace of type "ticket/type", according to the category namespace "http://esp.nongnu.org/ns/category/2005.1". The mime type for esp tickets is application/x-esp-ticket. A receipt is a standard reply for a submitted ticket. A receipt is usually returned as a reply to the HTTP request that created a ticket. If a ticket is submitted by email an automatic reply to that ticket may also contain a receipt. The url is the url of the open ticket in the ticket system the ticket was submitted to. A standard format for the XML or XHTML forms of such a ticket system is (currently) not part of this draft. When an error attribute is present the ticket was not created and the error attribute specifies the error in detail. The mime type for esp receipts is application/x-esp-receipt. A multilingual text with common ISO 639 language codes as attributes, each attribute refering to the translation of its language. An exception is the "trs" code for pinyin transcription of chinese text or other transcriptions. A database of country and region codes including names and, in a future release, neighborhood references for all neighboring regions. An imprint is a description of a legal person that operates a web site or offers any other kind of service and has a trade or association register number or a similar unique reference number from a well known registry. A PGP fingerprint to uniquely identify an entity is also required. The standard file name of an imprint SHOULD be "imprint.xml" and it SHOULD be placed in the top level directory of a web site, e.g. http://mysite.org/imprint.xml. The "previous" attribute SHOULD be used to refer to the previous version of the imprint, if one exists. This will allow search engines to recognize changes in imprints that might otherwise be seen as a change of ownership of a web site. The "socialContract" attribute SHOULD be used to refer to the social contract of the organization the imprint refers to. A social contract is a document that specifies the services offered by an entity and the policies it claims to adhere to. The social contract may also list membership organisations that the entity is a member of. The standard file name of a social contract SHOULD be it's revision number and it SHOULD be placed in a directory named "socialcontract". e.g. http://mysite.org/socialcontract/2005.1 Once a social contract is published it SHOULD be considered immutable. A significantly modified version MUST be published under a different revision number. Search engines SHOULD enforce this policy by not accepting changes to the policies a social contract implements once it has been published with the signature of the organisation it refers to and instead to annotate the contract with a warning and/or send a ticket to the publisher. This is recommended as a possible compliance test for search engines. The "policyNamespace" element, if present, specifies one or more namespaces that are used for policy categorization inside PolicyStatements. Policies are categorized by their authors, the category references in a social contract have to conform with that categorization. The default namespace with the empty prefix (":") refers to "http://esp.nongnu.org/ns/policy_category/2005.1". The "previous" attribute SHOULD be used to refer to the previous version of this social contract. A footnote for text contained in a paragraph. "abbr" is the abbreviated literature reference, e.g. "LIT-172". "ref" is a reference to an online version of the paper, if available. "title" is the title of the paper. "publisher" is the name of the publisher. "published" is the publishing date. "author" is a comma separated list of the authors. "urn" is a urn for the paper, if available, e.g. "urn:isbn:0123456789" for ISBN numbers. "page" is the page number of the reference in the printed version. The "level" attribute refers to the implementation level(s) that require(s) adherance to this paragraph. The "label" attribute is to be reproduced as an HTML label in HTML formatted versions of the enclosing document. If the "title" attribute is omitted the label can be used as a title. The "type" attribute(s), if present, MUST refer to a categorization of the content of the paragraph, e.g.: ":liabilities/legal measures/dissuasion/authorized parties". The default namespace with the empty prefix (":") refers to "http://esp.nongnu.org/ns/policy_structure/2005.1". A paragraph with the "final" attribute set to true may not be modified in policies extending this policy. The "level" attribute refers to the implementation level(s) that require(s) adherance to this paragraph. The "label" attribute is to be reproduced as an HTML label. in HTML formatted versions of the enclosing document. The "type" attribute MUST refer to a categorization of the content of the chapter, e.g.: ":liabilities/legal measures/dissuasion/authorized parties". A chapter SHOULD have only one "type" attribute, possibly leaving further distinction to the paragraphs within the chapter. The default namespace with the empty prefix (":") refers to "http://esp.nongnu.org/ns/policy_structure/2005.1". The implementation elements contain a collection of possible levels of implementations. The "chapter" elements contain the actual policy in human readable text. The "type" element is a reference into a CategoryNamespace of type "policy/type", according to the category namespace "http://esp.nongnu.org/ns/category/2005.1". The "issues" element contains a reference to a ticket system, which may require a prior login. The name of a policy document should be its revision number, e.g. "2005.1". Once a policy document is published it SHOULD be considered immutable. A policy document SHALL NOT be accepted without a valid signature from an entity that has published an imprint. Translations of policy documents SHOULD carry the language code as a suffix, e.g. "2005.1-fr". Imprints, PolicyDocuments, SocialContracts, Tickets and Namespaces MUST be signed. If a document is unsigned or the key of the signature for a document is not the key of or signed by the entity given as the originator of a document the authenticity of the document MUST be considered unknown and it should be treated as if it was unsigned. Consequently keys that are used to represent organizations should only be used to sign keys of members of these organisations that may act as representatives. Enclosing an esp element inside an esp element allows to add further signatures and timestamps that confirm the validity of earlier signatures and timestamps, which may have become invalid or insecure.