ESS:Document

From ESS
Jump to: navigation, search
Format ESS
Ess-feed-icon.png
.ess, .xml
application/ess+xml
version 0.9


ESS Document

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

in validation process [RFC ESS Draft] - http://essfeed.org/history/0.9




<ess> Root element

The <ess> 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.
The <ess> 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.
The <ess> 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.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ess PUBLIC "-//ESS//DTD" "http://essfeed.org/history/0.9/index.dtd">
<ess xmlns="http://essfeed.org/history/0.9" version="0.9" lang="en">
   <channel>
      <feed>
        ...
      </feed>
   </channel>
</ess>


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 <feed> (ess:feed) elements.
If this is not the case, then it is the responsibility of another <feed> to describe this event parameter.
Example: every <prices> items must be valid and applicable to every <dates> and <places> items within the same <feed>.



"IRI" and "URI" content

ESS allows the use of IRIs RFC 3987. Every URI RFC 3986 is also an IRI, so a URI may be used wherever below an IRI is named. There are two special considerations:

  1. 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
  2. When an IRI is serving as an ess:id value, it must not be so mapped, so that the comparison works.



"Date" content

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.


Example :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ess PUBLIC "-//ESS//DTD" "http://essfeed.org/history/0.9/index.dtd">
<ess xmlns="http://essfeed.org/history/0.9" version="0.9" lang="en">
    <channel>
       <feed>
          <published>2011-12-13T18:30:02Z</published> 
          OR
          <published>2011-12-13T18:30:02.25Z</published> 
          OR
          <published>2011-12-13T18:30:02+01:00</published>
          OR
          <published>2011-12-13T18:30:02.25+01:00</published>
           ...
       </feed>
   </channel>
</ess>

Sample of valid ISO 8601 Dates

  • 2009-12T12:34
  • 2009
  • 2009-05-19
  • 2009-05-19
  • 20090519
  • 2009123
  • 2009-05
  • 2009-123
  • 2009-222
  • 2009-001
  • 2009-W01-1
  • 2009-W51-1
  • 2009-W511
  • 2009-W33
  • 2009W511
  • 2009-05-19
  • 2009-05-19T00:00
  • 2009-05-19T14
  • 2009-05-19T14:31
  • 2009-05-19T14:39:22
  • 2009-05-19T14:39Z
  • 2009-W21-2
  • 2009-W21-2T01:22
  • 2009-139
  • 2009-05-19T14:39:22-06:00
  • 2009-05-19T14:39:22+0600
  • 2009-05-19T14:39:22-01
  • 20090621T0545Z
  • 2007-04-06T00:00
  • 2007-04-05T24:00


But it is recommended to write the dates under this format
2011-12-13T18:30:02+01:00
YYYY-MM-ddTHH:ii:ss+hh:ii

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.



<item> 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.

Some <item> 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,


Example:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ess PUBLIC "-//ESS//DTD" "http://essfeed.org/history/0.9/index.dtd">
<ess xmlns="http://essfeed.org/history/0.9" version="0.9" lang="en">
    <channel>
       <feed>
           ...
           <[ categories | dates | places | prices | people | media | relations ]>
              <item priority="1" type="xxxxx" unit="xxxxx">
                   <name>...</name>
              </item>
           </[ categories | dates | places | prices | people | media | relations ]>
           ...
        </feed>
    </channel>
</ess>


Recurrent <item> child elements:

Name Description Type Required
<name> Language-sensitive name. Should not be longer then 64 chars String TRUE



Discussions

ESS Forum Discussion > General

Could not find wordpress article with a title like home







External documentation

Ietf logo.png

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

IF EVENTS MATTER TO YOU

Spread the news about ESS
Personal tools
Actions
Standard


Developers


Communication