This specification describes two kinds of ESS Documents:
- ESS Documents (ess).
- ESS Feed entry (ess:feed).
An ESS Document is a representation of an ESS feed, including metadata about the feed, and some or all of the entries associated with it. Its root is the "ess:feed"
Both kinds of ESS Documents are specified in terms of the XML Information-set, serialized as XML 1.0 RFC: W3C.REC-xml-20040204 and identified with the "application/ess+xml" media type, (more information about how to integrate ESS in a website).
ESS Documents must be well-formed XML. This specification does not define a DTD for ESS Documents, and hence does not require them to be valid (in the sense used by XML). All ESS Document's structure is recommanded to be written in lowercase: XML elements, XML attribute (names and values).
ESS Documents must be encoded respecting the charset defined by the XML Document description [RFC 3023].
Any element defined by this specification may have an xml:base attribute (RFC: W3C.REC-xmlbase-20010627). When xml:base is used in an ESS Document, it serves the function described in [RFC 3986], establishing the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute. By default the xml:base name-space is : https://eventstandardsyndication.org/history/0.9
root XML element may have a "lang" attribute whitch content describes the language of the Document resource whose value must be a language tag [RFC 3066].
root XML element may also have a "version" attribute that define the current ESS version that have been used to generate the Feed and the version that have to be used by ESS:Processors to analysed and proceed the Feed.
root XML element may also have as root Name-Space
https://eventstandardsyndication.org/history/0.9 to identify the Document structure through IETF - RFC Documentation.
xmlns="https://eventstandardsyndication.org/history/0.9" version="0.9" lang="en"> >... > >
"IRI" and "URI" content
- When an IRI that is not also a URI is given for dereferencing, it MUST be mapped to a URI using the steps in [Section 3.1 of RFC 3987]
- When an IRI is serving as an ess:id value, it must not be so mapped, so that the comparison works.
ESS allows the use of Dates at it is discribe in [RFC 3339] - [ISO 8601]
A Date construct is an element whose content must conform to the "date-time". In addition, an uppercase "T" character must be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset. Note that there must not be any white space in a Date construct or in any IRI. Some XML-emitting implementations erroneously insert white space around values by default, and such implementations will emit invalid ESS Documents.
xmlns="https://eventstandardsyndication.org/history/0.9" version="0.9" lang="en"> > >2011-12-13T18:30:02Z> OR >2011-12-13T18:30:02.25Z> OR >2011-12-13T18:30:02+01:00> OR >2011-12-13T18:30:02.25+01:00> ... > >
Textual "String" content
Some ESS Feed elements provide textual contents, experience teaches that feeds that contain textual content are in general more useful than those that do not. Some applications (one example is full-text indexers) require a minimum amount of text. Feed producers should be aware of these issues. It is recommanded that each ess:feed entry element contain a non-empty "ess:feed:title" element, a non-empty "ess:feed:subtitle" element (when that element is present), and a non-empty "ess:feed:description" element. However, the absence of "ess:feed:description" is not an error, and ESS Processors must not fail to function correctly as a consequence of such an absence, like any absence of any elements that are not mandatory. The mandatory elements are defined in each element section in this website.
- XML elements
ESS Documents contain some "item" XML elements that can be repeated. "item" element may have two kind of attributes "type" and "priority". "item" elements can be repeated an infinit of time within its container. Each and all "item" elements MAY have in commun two similare element as child: "name" and "description" with Language-Sensitive String content.
childrens share a common structures. When an element is identified as being a particular kind of construct, it inherits the corresponding requirements from that construct's definition,
XML element can be present in every
elements, but it alway inheritate to the same type of content construct definition: String.
xmlns="https://eventstandardsyndication.org/history/0.9" version="0.9" lang="en"> >... [ categories | dates | places | prices | people | medias | relations | authos ]>
>This is always a String content. ]]> > > [ categories | dates | places | prices | people | medias | relations | authos ]> ... > >
ESS Processors may keep state sourced from ESS Feed Documents and combine them with other ESS Feed Documents, in order to facilitate a contiguous view of the contents of a feed. The manner in which ESS Feed Documents are combined in order to reconstruct a feed (e.g., updating entries and metadata, dealing with missing entries) is out of the scope of this specification.
- [RFC 3023] : XML Media Types
- [RFC 3066] : Tags for the Identification of Languages
- [RFC 3076] : Canonical XML Version 1.0
- [RFC 3339] : Date and Time on the Internet: Timestamps
- [RFC 3986] : Uniform Resource Identifier (URI): Generic Syntax
- [RFC 3987] : Internationalized Resource Identifiers (IRIs)
- [ISO 8601] : Wikipedia ISO 8601