This specification describes two kinds of ESS Documents:
- ESS Documents (ess).
- ESS Channel (ess:channel).
- 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" XML element.
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 : http://essfeed.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
http://essfeed.org/history/0.9 to identify the Document structure through IETF - RFC Documentation.
xmlns="http://essfeed.org/history/0.9" version="0.9" lang="en"> > >... > > >
ESS documents are composed by various main XML elements.
ESS processors must consider each and every element's description as valid and applicable to each and every other XML element within the same
If this is not the case, then it is the responsibility of another
"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="http://essfeed.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> ... > > >
Sample of valid ISO 8601 Dates
But it is recommended to write the dates under this format
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:title" element, a non-empty "ess:subtitle" element (when that element is present), and a non-empty "ess:description" element. However, the absence of "ess: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" 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,
xmlns="http://essfeed.org/history/0.9" version="0.9" lang="en"> > >... <[ categories | dates | places | prices | people | media | relations ]>
- priority="1" type="xxxxx" unit="xxxxx">
>...> > [ categories | dates | places | prices | people | media | relations ]> ... > > >
|Language-sensitive name. Should not be longer then 64 chars||String||TRUE|
ESS standard under RFC validation process: RFC ESS Draft
- 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