RSS 3.0 Lite Specifications

RSS 3 Lite Specifications

In this page the RSS 3 Lite Specifications are detailed as a stand-alone part of the RSS Version 3 Standard.

This version:

Intermediate Version (Post 'First Draft', last updated August 19, 2005)
(The First Call for Comments stage is now taking place, please see under Status of this Document)

Latest version:

The latest version can always be found at the following link

Intermediate versions:
(Intermediate versions are edited specifications on their way to become a certain draft)

See the Intermediate Version file

Previous versions:

Initial Draft.
For further archived versions, see the Archive section or the Archive directory.

Editor and contributors:

Jonathan Avidan

Sections in this document:

Requirements and Terminology
Abstract
Status Of This Document
Table of Contents
Specification
Appendices

See the Errata appendix for corrections in the current and previous versions.

This specification is in normative XHTML form, best viewed in Mozilla Firefox 1.0+ (or any Gecko 1.7+ based browser), Microsoft Internet Explorer 6.0+, Opera 7.0+ and Apple Safari 1.0+. A non-normative PDF form is available here.

Please note that any content on this page or any other page linked here is subject to change (until finalized upon publication of the Final Specification).

Finally, please review the Terminology and Requirements pages before reading this document.

©2005 Jonathan Avidan - distributed under the Attribution/Share Alike Common License. This is a derivative work based on RSS 2.0.1 by Dave Winer and others, and to their work and efforts we are indebted.

Requirements and Terminology

This section is normative.

It is imperative for anyone who wishes to read the following specification to read the Terminology page which describes the terms used in this document.

It is also highly recommended to read the Requirements page, upon which the current document is based and to which it complies.

Further notice the normative application of the following semantics in this specification:

[Definition: "informative"] Anything marked as "informative" is presented for the sake of further detail or general knowledge and does not stand to describe applicable features or suggested behaviors
[Definition: "normative"] Anything marked as "normative" presents a section to whose rules and descriptions implementors have to adhere (whether optionally or obligatorily is marked using words described below in this list)
[Definition: "non-normative"] Anything marked as "non-normative" presents a section which is not informative but descriptive of either "recommending" nature or changing nature; Take notice that all "comment" and "note" sections are non-normative unless pointed otherwise
[Definition: "required"] A "required" feature of the format is one that must be present at any time within the RSS document, unless it is a feature of another one which is optional, in which case it must appear as long as the optional feature appears as well
[Definition: "optional"] An "optional" feature of the format is one that may be present when needed thus supplying further metadata
The key words (normally, but not always, appearing in italic) "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", "may not" and "optional" are to be interpreted as described in RFC 2119
When discussing a feature or behavior, the word "should" implies that the feature or behavior in discussion is basically optional but very warmly suggested for the sake of usability (especially when discussing implementor behavior)
Also notice that though the word "section" is used to refer to several measures of text (from the smallest sub-section such as "the isEmpty Attribute" below to the greatest section such as "Specification"; However, the words "this section" or "the current section" will always refer to the smallest part of the document from its title to (and not including) the next section

Abstract

This section is informative.

The following section describes the abstract purpose of the format in general and this specification in particular. It is divided into three parts: "General" describing the theoretical purpose of the format; "Unique" describing the RSS format throughout its stages and "Specific" describing the current format and specification in particular.

General: RSS, which stands for Really Simple Syndication, is a standardized way to broadcast metadata via the Internet. Its purpose is to create easily understandable pieces of written information for processing into human-readable form by "Aggregators" and other applications of the sort.

Unique: The RSS Version 3 Class of Standards (which includes the RSS Category Declaration Language (RCDL) 1.0, RSS Rating Description Language (RRDL) 1.0, RSS 3 Full and the one of this specification: RSS 3 Lite) is hereby proposed in order to standardize the different available versions and formats of RSS (namely, the 0.9x class [where x is a number between and including 1 to 4] and the 2.0 class - other standards being irrelevant). The deprecated 0.90 format is disregarded here. The RSS format is similar in purpose and manner to the currently in progress Atom standard and the RSS 1.0 standard, both of which are outside of this specification's scope. RSS Version 3, the version proposed here to replace the 2.0 format (due to its under-documented and outdated state) is designed to be comprehensive, efficient and backwards-compatible when possible. For a full set of requirements to which the standards must comply, see the Requirements page. In conclusion: RSS Version 3 is meant to completely replace the outdated 0.9x and 2.0 classes of standards, while politely competing with or complimenting others such as RSS 1.0 and Atom.

Specific: RSS 3 Lite is a reduced form of the RSS Version 3 standard, intended to be used by low-end aggregators or similar applications. Its purpose is to be an efficiently succinct form of RSS 3, engulfing new useful features even to aggregators who only require a handful of metadata, while disposing of features irrelevant to low-end clients by either removing them entirely or placing them under the RSS 3 Full Specification. For example, software which only needs to receive basic information about a certain link will use the RSS 3 Lite standard for its analysis of the RSS feed. A full-featured aggregator would be able to process most or all of the features described in the RSS 3 Full standard. As a result of complete interoperability, an RSS feed in Lite type could be processed by a RSS 3 Full-compatible processor as the Full type features are not obligatory, while a Lite-type processor is still perfectly capable of processing a Full-type feed by simply ignoring the Full-type features. RSS 3 Full is a highly expanded version of this specifications which consists of features intended for use by high-end aggregators or any processor which requires further metadata.

On further note: The RSS Category Declaration Language (RCDL) 1.0 is an XML-based standard specifically designed to declare the different categories used in an RSS feed or channel and its support is only required in the RSS 3 Full specification, thus irrelevant to the current document, as is the RSS Rating Description Language (RRDL) Version 1.0 which depicts the rating given to an item.

Status of this Document

This section is non-normative.

This document is in First Draft status. This is the first publicly released version of this specification, intended for review by a broad spectrum of readers. Despite the use of the word "normative" to describe different sections of this specification, it is to be considered "non-normative" (or "informative") at its entirety until the publication of the Final Standard.

It is not to be considered as a finalized standard nor it is to be implemented in any public manner, excluding research and experiment purposes.

The First Call For Comments stage is now taking place!

Upon reading the following document, readers are encouraged to contact the editor to inform of the followings:

Spelling error or other errors of editorial sort
Suggestion of new features or behaviors
Suggestion of alteration of existing features or behaviors
Suggestion of removal of existing features or behaviors
Anything important not described here of which the editor should be informed

Inform the editor by sending a mail with the title "RSS 3 Lite" to this address: , or otherwise leave a message in the appropriate board. To contact the site team concerning the site itself send a mail to . We appreciate all help.

This document may be withdrawn at any given moment without notice; Though it is distributed under the Attribution/Share Alike Common Licence, it is strongly urged not to make derivative works of it yet and not implement it in any way until its final version is published. The content of this document is subject to change or removal. The right to refuse any suggestion of any form is reserved.

Table of Contents

This section is non-normative.

This is the specification's table of contents. In order to skip to a desired section, simply click on one of the links below:

Specification:

Introduction
The RSS Document
RSS Version 3.0 Lite-type Specifications
1. Cascading Elements
2. Common Elements and Attributes
 1. Common Attributes
 1. The "isEmpty" Attribute
 2. The "isUpdated" and "updateNum" Attributes
 2. Common Required Elements
 1. The Element</a></li> <li><a href="#spec_common_required_elements_link">The <link> Element</a></li> <li><a href="#spec_common_required_elements_description">The <description> Element</a></li> </ol> </li> <li> <a href="#spec_common_optional_elements">Common Optional Elements</a> <ol> <li><a href="#spec_common_optional_elements_guid">The <guid> Element</a></li> <li><a href="#spec_common_optional_elements_language">The <language> Element</a></li> <li><a href="#spec_common_optional_elements_icon">The <icon> Element</a></li> <li><a href="#spec_common_optional_elements_copyrights">The <copyright> Element</a></li> </ol> </li> </ol> </li> <li> <a href="#spec_rss">The <rss> Root Element</a> <ol> <li> <a href="#spec_rss_req_att">Required Attributes</a> ("version") </li> <li> <a href="#spec_rss_opt_att">Optional Attributes</a> <ol> <li><a href="#spec_rss_opt_att_type">The "type" Attribute</a></li> <li><a href="#spec_rss_opt_att_source">The "source" Attribute</a></li> </ol> </li> <li> <a href="#spec_rss_req_ele">Required Sub-Elements</a> (<channel>) </li> </ol> </li> <li> <a href="#spec_channel">The <channel> Element</a> <ol> <li> <a href="#spec_channel_opt_att">Optional Attributes</a> ("isEmpty", "isUpdated" and "updateNum") </li> <li> <a href="#spec_channel_req_ele">Required Sub-Elements</a> (<title>, <link>, <description> and <item>) </li> <li> <a href="#spec_channel_opt_ele">Optional Sub-Elements</a> <ol> <li><a href="#spec_channel_opt_ele_managingEditor">The <managingEditor> Element</a></li> <li><a href="#spec_channel_opt_ele_webMaster">The <webMaster> Element</a></li> <li><a href="#spec_channel_opt_ele_lastBuildDate">The <lastBuildDate> Element</a></li> <li><a href="#spec_channel_opt_ele_ttl">The <ttl> Element</a></li> <li><a href="#spec_channel_opt_ele_generator">The <generator> Element</a></li> <li><a href="#spec_channel_opt_ele_docs">The <docs> Element</a></li> </ol> </li> </ol> </li> <li> <a href="#spec_item">The <item> Element</a> <ol> <li> <a href="#spec_item_opt_att">Optional Attributes</a> ("isEmpty", "isUpdated" and "updateNum") </li> <li> <a href="#spec_item_req_ele">Required Sub-Elements</a> (<title>, <link> and <description>) </li> <li> <a href="#spec_item_opt_ele">Optional Sub-Elements</a> <ol> <li><a href="#spec_item_opt_ele_comments">The <comments> Element</a></li> <li><a href="#spec_item_opt_ele_pubDate">The <pubDate> Element</a></li> <li><a href="#spec_item_opt_ele_author">The <author> Element</a></li> <li><a href="#spec_item_opt_ele_field">The <field> Element</a></li> </ol> </li> </ol> </li> <li> <a href="#spec_linking">HTML and XHTML RSS Linking Guidelines</a> <ol> <li><a href="#spec_linking_general">General Linking</a></li> <li><a href="#spec_linking_hypertext">Hypertext Linking</a></li> <li><a href="#spec_linking_xml">XML Linking</a></li> </ol> </li> <li><a href="#spec_extending">Expanding An RSS Document</a></li> </ol> </li> </ol> <a href="#appendices">Appendices</a>: <ol class="NormalText AppendixList"> <li><a href="#appendices_differences">Differences from The Previous Format</a></li> <li><a href="#appendices_dtd">The RSS Lite-type DTD</a></li> <li><a href="#appendices_schema">Validation XML-Schema</a></li> <li><a href="#appendices_xslt">XSLT for Display of RSS 3 Lite-type Feeds</a></li> <li><a href="#appendices_sample">Sample Feeds</a></li> <li><a href="#appendices_errata">Errata</a></li> </ol> <hr> Specification<a name="spec" id="spec"></a> Introduction<a name="spec_introduction" id="spec_introduction"></a> This section is informative. This document is a specification detailing the Really Simple Syndication (RSS) format version 3, specifically the RSS 3 Lite-type format. This specification strives to compile an official standard for the next generation of RSS formats while remaining as backwards-compatible as possible, thus virtually replacing older formats (namely RSS 0.91, 0.92, 0.93, 0.94 and 2.0 - excluding all other syndication formats). Please note, however, that it may or may not contradict some features of 0.9x standards (for example, the <description> element is optional in 0.91 but required in 2.0) and therefore the 3.0 format strives to be backwards-compatible solely with the 2.0 format. RSS is a concise and modularized way to relay summarized metadata via the Internet or similar connection. Essentially, it is a way to transmit information of changing nature (updates, news etc.) from an originating website or web service to a subscribing client in computer-readable form, in theory to be transformed into human-readable form. For example, a news site may provide an RSS feed providing titles, description and links to different news items. However, an application subscribing to a feed may choose to process the contents of an RSS document for its own specific needs rather than transforming it into human-readable form. The "RSS" acronym has been given several interpretations, the most dominant being "Rich Site Summary". However, since RSS is no longer used just to summarize contents of websites (as it is used in many kinds of web services) the interpretation "Really Simple Syndication" has been chosen to represent the current level of the standard; RSS is, most basically, a way to syndicate information - really simply. This specification must comply with the requirements described <a href="../requirements.html">here</a>, using terminology described <a href="../terminology.html">here</a> using semantics detailed under <a href="#req_term">Requirements and Terminology</a> above. For informative purposes, the RSS Version 2.0.1 specification can be found here and is attributed to Dave Winer, amongst others. This is a derivative work and is indebted to their genius and efforts. Whenever a feature is first described, a DTD line is provided detailing the different aspects of the feature. Due to restraints in the DTD language, these lines do not represents the full description of the feature in discussion; please refer to the (non-normative) XML Schema in the <a href="#appendices_schema">appendices</a> for a fuller description. Comment: UAs who are already capable of processing RSS Version 2.0 documents should update their application so that feeds with the version mark "3.0" will be processed by the same processor (if not one complying to this, or the RSS 3 Full, specification); This stems from the imperative requirement that all RSS 3 documents must aspire to be as backwards-compatible as possible and so no fatal differences are made. The RSS Document<a name="spec_rss_doc" id="spec_rss_doc"></a> This section is normative. This section describes the type, form and structure of any RSS feed complying with the current specification and thus considered "valid". XML Structure<a name="spec_xml_structure" id="spec_xml_structure"></a> All RSS feeds must comply with the XML version 1.0 standard and be a valid XML document. Comment: This does not concern partially transmitted parts of an RSS feed, such as a service requesting a particular item from the feed owner/generator, in which case the service will be provided with the full item transmitted under the RSS content-type (see below). Therefore, all RSS feeds must begin with the XML declaration syntax: <div class="code"> <?xml version="1.0" encoding="UTF-8" ?> </div> Comment: Notice that the formal encoding for RSS feeds is "UTF-8". <ul class="NormalText"> <li>An RSS document must not contain any DTD declaration and must not rely on an XML Schema.</li> <li>An RSS document may have a related CSS file, XSL file or any other form of representing its content.</li> <li>An RSS document need not have further XML built-in features, such as "xml:lang", "xml:base" and "xml:id", and implementors should ignore them as the format provides its own alternatives for consistency's sake.</li> <li>The RSS root element must not contain an XML Namespace, nor must any element or attribute described in this specification.</li> </ul> For information concerning expansion of this standard, see the section titled <a href="#spec_extending">Expanding An RSS Document</a>. Feed Transmission Every RSS feed, whether in file form (see below) or generator produced form (or other) must comply with this entire specification. RSS feed in file form is represented by the feed itself as simple text saved in a file whose suffix should be ".rss". However, for the sake of backwards-compatibility, implementors and user-agents must be able to process any RSS feed in the form of a URL, which may be a local, on-line or other kind of file (with any ending, for example ".xml") or the URI address of the on-line service generating the feed (for example, a website URI containing arguments). The official content-type (i.e. "MIME type") for file-form RSS feeds is "application/rss+xml". However, for the sake of backwards-compatibility, implementors and user-agents should be able to process RSS feeds which are transmitted under the content-types "text/xml" and "application/xml" as long as these are not supposed to be RSS 3 document but rather previous versions. Generic RSS Design<a name="spec_generic_design" id="spec_generic_design"></a> At the base of the RSS document, immediately following the XML declaration syntax, resides the document's root element, namely <rss>. Within this element lies the document which consists of at least one "channel" which contains at least one "item". Comment: This specification only describes documents with one channel. However, a document may have more than one channel as described in the RSS Version 3.0 Full-type Specification. Implementors of the current specification should ignore all but the first <channel> element in the document unless they are able to process multiple channels as described in the RSS 3 Full-type Specification. A "channel" is defined as a common grouping or source of the list of items. For example, a series of items from the same site (or same section within a site) would be placed within the same channel. An "item" is defined as a unique instance of metadata and is considered singular within the document. Note: Several items may contain the same or shared metadata, but two or more items cannot share the same GUID, see below. Thus an RSS feed is structured in the following order: <ol class="NormalText"> <li>XML declaration syntax</li> <li>RSS opening root tag (with its required attribute) <ol> <li>Channel opening tag <ol> <li>Required sub-elements</li> <li>One or more Item element with its closing tags (and its required sub-elements)</li> </ol> </li> <li>Channel closing tag</li> </ol> </li> <li>RSS closing root tag</li> </ol> The following part of the document is the normative specification of the RSS 3 Lite-type format, describing the syntax and usage rules of the RSS features. RSS Version 3.0 Lite-type Specifications<a name="spec_rss_lite" id="spec_rss_lite"></a> This section is normative. This section describes the nature, syntax and structure of the elements and attributes which together form the RSS format. Here follow several rules applying to the entire specification: Temporary note (informative): As this list evolves it should be moved to a more appropriate place) <ol class="NormalText"> <li> Rule: No URI or URL given in an RSS document may be relative</li> <li> Rule: All e-mail addresses must lack the "mailto:" prefix</li> <li>Rule: Upon encountering an element or attribute not described in this specification and not placed under a namespace, the processor must ignore it</li> <li>Rule: No proper or escaped HTML (or XHTML), or any other XML (or SGML) based language, are allowed within an RSS 3 Document; XHTML and other XML based languages are allowed when all of its items are given under their proper namespace. Note however that to transmit an items content a special feature is described in the RSS 3 Full specification, where the process of transmitting its content are described in full.</li> <li>Rule (informative): Though this specification does not use any namespace with its features, when RSS elements need to be used in another XML document, their official namespace is "https://rss3.org/#rss3" (sans the quotes)</li> </ol> Cascading Elements<a name="spec_cascading_elements" id="spec_cascading_elements"></a> The RSS format enjoys the use of Cascading Elements, meaning features that can be placed at different structure levels and by being more deeply placed override the contents of the same tag placed at a higher level, if any. This means that if this kind of feature is placed both directly beneath a certain element and another element who is a child of some level of the prior element, only the second cascading element counts in its level. The RSS 3 Lite-type cascading features are <copyright>, <language> and <icon> (see below). Specifically, all of the above mentioned elements can be placed both directly beneath the <channel> element and under any <item> element, itself placed within the <channel> element. Therefore, upon encountering one of these elements at item-level, the content of the present element is to count concerning the item itself and not according the cascading element placed at channel-level, if at all. For example, if a channel is given the language definition of "en-US" but an item is given the language definition "he", the implementor should consider that item to be in Hebrew and not assumed to be in English. Common Elements and Attributes<a name="spec_common_elements" id="spec_common_elements"></a> Common elements and attributes are those which can be applied at different structure-levels (elements) or to multiple kinds of elements (attributes) with the same syntax. Their syntax is hereby described and these sections are called upon when a description of the necessary element or attribute is required. Common Attributes<a name="spec_common_attributes" id="spec_common_attributes"></a> The "isEmpty" Attribute<a name="spec_common_attributes_isEmpty" id="spec_common_attributes_isEmpty"></a> <div class="code"> <!ATTLIST channel isEmpty (true | false) #IMPLIED "false"> <!ATTLIST item isEmpty (true | false) #IMPLIED "false"> </div> The "isEmpty" attribute's content is boolean, meaning either "true" or "false" and may be applied to the <channel> element as well as any <item> element. The rules of this attribute's implementation are described under the respective descriptions of the above-mentioned elements. The "isUpdated" and "updateNum" Attributes<a name="spec_common_attributes_isUpdated" id="spec_common_attributes_isUpdated"></a> <div class="code"> <!ATTLIST channel isUpdated (true|false) #IMPLIED "false" > <!ATTLIST channel updateNum #IMPLIED "1" > <!ATTLIST item isUpdated (true | false) #IMPLIED "false" > <!ATTLIST item updateNum #IMPLIED "1" > </div> Rule: The "isUpdated" attribute may appear in an element without the companionship of the "updateNum" attribute, in which case the latter attribute's default value may be taken under consideration if necessary, but the "updateNum" attribute has no use and is not to be considered when without the companionship of "isUpdated" in the same element. The "isUpdated" attribute is a boolean attribute, meaning its content can either be "true" or "false". The "isUpdated" attribute is at all times optional and may be placed in the <channel> element to signify that its content has been updated (presumably since the last time the feed refreshed). It may also be placed within an <item> element to signify that item has been updates (meaning that either the item's metadata or the link's content has been changed). The "updateNum" attribute may be present within an element only when the "isUpdated" element is present in the same element. When it is not present, it must be assumed "1". The "updateNum" attribute is at all times an integer, though it may never be "0". It signifies the chronicle numbering of the update instance, meaning how many times the channel of item has been updated. Thus, for example, when an item is set as updated with the update numbering of "3", it is to be understood that this item presents the third version of the item's metadata and/or its link's content. A further note would be that when "updateNum" is set to a negative integer it is to be understood that the channel or item presents a "roll-back" of the content to an earlier version. Common Required Elements<a name="spec_common_required_elements" id="spec_common_required_elements"></a> The <title> Element<a name="spec_common_required_elements_title" id="spec_common_required_elements_title"></a> <div class="code"> <!ELEMENT title (#CDATA) > </div> The <title> element must be present beneath both the <channel> element and beneath any instance of an <item> element. At both occurrences it is required. This element's content is always plain text and is supposed to describe the title of the channel or item under which it resides (further on this topic beneath the <channel> and <item> elements' descriptions below). The <link> Element<a name="spec_common_required_elements_link" id="spec_common_required_elements_link"></a> <div class="code"> <!ELEMENT link (#CDATA) > </div> The <link> element must be present beneath both the <channel> element and beneath any instance of an <item> element. At both occurrences it is required. This element's content must be a valid, non-relative, URL or URI, including the "http://" (or other) prefix. The nature of the link's content is further described beneath the <channel> and <item> elements' descriptions. The <description> Element<a name="spec_common_required_elements_description" id="spec_common_required_elements_description"></a> <div class="code"> <!ELEMENT description (#CDATA) > </div> The <description> element must be present beneath the <channel> element (under which it is required) and may be present beneath any instance of an <item> element (where it is optional). This element's content must be plain text and is supposed to describe the nature of its structure level (specifically either the channel or the item), see more under the <channel> and <item> elements' descriptions. Note (normative): Take notice that this element is #CDATA and may only contain plain text and not escaped HTML, proper HTML or XHTML or any sort of further mark-up and its content should be regarded as text (thus transforming the < and > entities into the "<" and ">" symbols rather than into mark-up). In order to transmit further mark-up the <content> element has been set up in the RSS 3 Full-type specification. Common Optional Elements<a name="spec_common_optional_elements" id="spec_common_optional_elements"></a> The <guid> Element<a name="spec_common_optional_elements_guid" id="spec_common_optional_elements_guid"></a> <div class="code"> <!ELEMENT guid (#CDATA) > <!ATTLIST guid type (code | url) #IMPLIED "url" > </div> The name "guid" stands for Globally Unique Identifier. By its nature, the same GUID must never be given to more than one item or channel. This element is optional both beneath the <channel> element and beneath any instance of an <item> element. It is used to uniquely identify the channel or item on which it is placed. This element may have one attribute, "type", whose content can be either "code" or "url" and is presumed to be "url" when missing. When having no attributes or the "type" attribute set to "url", this element's content must be a valid URI address which uniquely identifies the channel or item. When the "type" attribute set to "code" this element's content must be a GUID numerical value (without the "urn:uuid:" prefix or any other one). The <language> Element<a name="spec_common_optional_elements_language" id="spec_common_optional_elements_language"></a> <div class="code"> <!ELEMENT language (#CDATA) > <!ATTLIST language rel (meta | link | both) #IMPLIED "link" > </div> The <language> elements may be present under the <channel> element and also under the <item> element. This feature is cascading. This means that when present beneath the <channel> element, all the channel's items are to consider having that language specification unless in those under which another <language> element is present, if any, in which case it overrides it. When missing, this element's content is assumed to be "en". It is used to convey what language is being used, either in the RSS document itself or in the provided link's content. For this purpose this elements may have one attribute, "rel", whose content may be "meta", "link" or "both". This attribute is presumed to be "link" when missing. The content "meta" conveys the notion that the element is specifying the language of the metadata in the RSS document itself. The content "link" conveys the notion that the element is specifying the language in which the relevant content of the given link is written. The content "both" makes the two above mentioned interpretations equally relevant. Up to two <language> elements may be placed beneath the same element as long as one's "rel" attribute is set to "meta" and the other is set to "link". In case there are more than two <language> elements, only the last one is to be considered. In case there are two or more <language> elements and one or more of them has the "rel" attribute set to the same content, the last one set so is to be considered. This item's content must be compliant with the RFC 1766, "Tags For The Identification of Languages". This means that the content of this tag is two letters representing a language (as defined in the ISO 639) which may be followed, after a dash, by two more letters signifying a particular country (as defined in the ISO 3166). Implementors should only acknowledge the first letters until the dash, if any (presumably two), though if the specific country is relevant it may regard the country specification. Thus if the element's content is "en-US" it is to be considered as "English", and may choose to regard or disregard the country specification. The <icon> Element<a name="spec_common_optional_elements_icon" id="spec_common_optional_elements_icon"></a> <div class="code"> <!ELEMENT icon (#CDATA)> <!ATTLIST icon width (#CDATA) #IMPLIED > <!ATTLIST icon height (#CDATA) #IMPLIED > </div> The <icon> element may be placed under the <channel> element and also under any <item> element. Note that this feature is cascading. Therefore whenever an <icon> element is present beneath a <channel> element, it is assumed to apply to all its item's unless in those where another <icon> element is present, if any, in which case it overrides it. This element is used to convey the location of a graphical icon, presumably to represent the element under which it is placed. This is not to be confused with the <image> element, which is now a part of the RSS 3 Full format. The content of the <icon> element must be a valid, non-relative, URI pointing to the location of the graphic file to be used as the icon. The permissible types of graphical files to be used as icons are GIF files, ICO files and PNG files. The <icon> element has two more optional attributes, "width" and "height" signifying the width and height of the image to be presented as the icon. When missing, the implementor should not assume any pre-decided figure but rather either use the actual image's size or impose a certain size according to the restrictions of the implementor. The <copyright> Element<a name="spec_common_optional_elements_copyrights" id="spec_common_optional_elements_copyrights"></a> <div class="code"> <!ELEMENT copyright (#CDATA) > </div> The <copyright> element may be placed under the <channel> element and also under any <item> element. Note that this feature is cascading. Therefore whenever a <copyright> element is present beneath a <channel> element it is assumed to apply to all the channel's items, unless in the items in which another <copyright> element is present, if any. This element's content is plain text of no restriction in length. It is to contain a copyright notice of either the metadata of the feed itself or the links provided in an item, see under the <channel> and <item> elements' descriptions. The <rss> Root Element<a name="spec_rss" id="spec_rss"></a> <div class="code"> <!ELEMENT rss (channel+) > <!ATTLIST rss version (#CDATA) #REQUIRED > <!ATTLIST rss type (lite | full) #IMPLIED > <!ATTLIST rss source (#CDATA) #IMPLIED > </div> Every RSS document (excluding the XML declaration syntax) begins with the <rss> root element and ends with its end tag </rss>. Aside from being the document's root element, it is also used to convey more information so as to the format used in the document and also contains the feed's channel. The <rss> element must not be placed under or in relation to an XML namespace or XML schema. Required Attributes<a name="spec_rss_req_att" id="spec_rss_req_att"></a> The <rss> element has one required attribute, namely "version". This attribute is used to convey which format was used in creating the document. This attributes content must be in the form of "x.y" where X and Y represent positive integers from 0 to 9. This specification requires the "version" attributes content to be "3.0". Comment: As the current format is designed to be backwards compatible, a processor designed for RSS version 3 should also be able to process documents whose version is one of the following: "0.91", "0.92", "0.93", "0.94" or "2.0". Comment (normative): Implementors should be able to process any valid RSS document as long as the X figure in the above mentioned pattern of content in the "version" attribute is "3" (as future sub-version of the current format, i.e. 3.1, 3.2 and so on, are to be backwards compatible). It is suggested that when the processor encounters a number in the X position different from "3" that it should compare it to the list of above mentioned versions. Optional Attributes<a name="spec_rss_opt_att" id="spec_rss_opt_att"></a> The <rss> element may contain two optional attribute, namely "type" and "source". The "type" Attribute<a name="spec_rss_opt_att_type" id="spec_rss_opt_att_type"></a> The "type" attribute's content must be either "lite" or "full". Its purpose is to indicate to which specification the document format complies, for informative purposes. For example, a document using some or all the features in the RSS 3 Lite-type specification will have the "type" attribute set to "lite" while a document using one or more features specified in the RSS 3 Full-type specification will have the "type" attribute set to "full". Comment (normative): The purpose of this attribute is informative only and therefore should not be assumed to be anything when missing. Implementors should not decide upon its content whether to process the document or not, as the RSS 3 types are entirely mutually compatible. In theory, a processor of lite-type documents can handle full-type documents by simply ignoring the full-type features. A processor of full-type documents can easily handle lite-type documents as they are valid full-type documents in themselves. The "source" Attribute<a name="spec_rss_opt_att_source" id="spec_rss_opt_att_source"></a> The "source" attribute's content must be a valid, non-relative, URI. The URI contained in this attribute must direct to the originating service or the file itself in which the current RSS document is contained. It is to be used for informative purposes only. Note (informative): This attribute replaces the <source> element of the 2.0 format which was supposed to be placed beneath the <channel> element; The reasoning behind this is that in theory there could be several channels within the RSS 3 document and therefore the "source" should be placed on the <rss> root itself. Required Sub-Elements<a name="spec_rss_req_ele" id="spec_rss_req_ele"></a> The <rss> element must contain at least one <channel> element, the syntax of which is described below. The <channel> Element<a name="spec_channel" id="spec_channel"></a> <div class="code"> <!ELEMENT channel (title | link | description | managingEditor? | webMaster? | icon? | generator? | docs? | ttl? | guid? | copyrights? | language* | item+) > </div> The <channel> element is the placeholder for the feed's items, structure-wise. A channel is a series (sorted or unsorted) of items under some sort of grouping. Though this specification does not intend to set the rules for the grouping of items, it is natural that items are grouped in some logical relation, like all items in some level originating from the same source, or concerning a certain topic and so on. This specification does not concern multiple channels within the same RSS document. However, upon encountering more than one channels within the same document, implementors should process the first instance of this element normally and may choose to process its other instances or not. Optional Attributes<a name="spec_channel_opt_att" id="spec_channel_opt_att"></a> The <channel> element may have the boolean (meaning its content may be either "true" or "false") attribute "isEmpty", which is assumed false when missing. A channel should be defined as empty only on the occasion where it contains only a single <item> element which has been set as empty as well, yet it may also be placed in the <channel> element even if it contains one or more perfectly good items. Upon encountering a channel element set as empty, implementors must not continue to process the channel's content and should inform the user of that situation in some way, rather than continue to process the said channel. Note: A channel containing one or more non-empty items should be set as empty only if its author wishes for it not to be processed, for example in case of defunct links or other outdated metadata. Comment: Implementors which are able to process more than one channel in the same feed should not stop processing the document upon encountering a channel set as empty but rather look for more channels. Also, the <channel> element may have the "isUpdated" and "updateNum" attributes whose syntax and purpose have been described under <a href="#spec_common_elements">Common Elements and Attributes</a>. Required Sub-Elements<a name="spec_channel_req_ele" id="spec_channel_req_ele"></a> The <channel> element must have at least four sub-elements, namely <title>, <link> and <description> and at least one <item> element. The syntax of the first three is described under <a href="#spec_common_elements">Common Elements and Attributes</a>. These elements' content should be derived from the following stances: <ol class="NormalText"> <li>The <title> element's content should perform as the title of the channel itself; therefore if the channel for example is a compilation of items from a certain website, that website's name should be mentioned in the item's title</li> <li>The <link> element's content should in theory provide a URI to the source behind feed, namely the website or other application to which the feed relates Note (normative): this must not be the URI of the source RSS file or service </li> <li>The <description> element should in theory describe the purpose of the feed or rather describe the originating source</li> </ol> A channel must contain at least one <item> element, even if the item is set to be empty. Optional Sub-Elements<a name="spec_channel_opt_ele" id="spec_channel_opt_ele"></a> The <channel> element may have several optional sub-elements. Four of which (namely <icon>, <guid>, <language> and <copyright>) have been described under <a href="#spec_common_elements">Common Elements and Attributes</a> above. Other elements are described in the following sections. The <managingEditor> Element<a name="spec_channel_opt_ele_managingEditor" id="spec_channel_opt_ele_managingEditor"></a> <div class="code"> <!ELEMENT managingEditor (#CDATA) > <!ATTLIST managingEditor name (#CDATA) #IMPLIED > </div> The <managingEditor> element's content must be a valid electronic mail address (hence "e-mail"). It may have one attribute, namely "name" whose content should be the name of the e-mail address' owner. The purpose of this element is to contain the e-mail of the person responsible for the feed's content so as to metadata and link's destination, i.e. the editor of the content's destination and the channel's <description> elements' content. The <webMaster> Element<a name="spec_channel_opt_ele_webMaster" id="spec_channel_opt_ele_webMaster"></a> <div class="code"> <!ELEMENT webMaster (#CDATA) > <!ATTLIST webMaster name (#CDATA) #IMPLIED > </div> The <webMaster> element is very similar to the <managingEditor> element in syntax. Its content must be a valid e-mail address. It may have one attribute, namely "name" whose content should be the name of the e-mail address' owner. The purpose of this element is to contain the e-mail of the person responsible for the technical maintenance of the website in general and the feed in particular. The <lastBuildDate> Element<a name="spec_channel_opt_ele_lastBuildDate" id="spec_channel_opt_ele_lastBuildDate"></a> <div class="code"> <!ELEMENT lastBuildDate (#CDATA) > </div> This element's content must specify an exact date conforming to the IETF RFC822 specification. Its purpose is to specify the exact time when the feed was last produced or generated. For example, at the time of this writing if a feed was produced its content would be "Thu, 30 Jul 2005 16:43:00 GMT". The <ttl> Element<a name="spec_channel_opt_ele_ttl" id="spec_channel_opt_ele_ttl"></a> <div class="code"> <!ELEMENT ttl (#CDATA) > <!ATTLIST ttl span (seconds | minutes | hours | days) #IMPLIED "seconds" > </div> The element's name, "ttl", stands for Time To Live. Its content must be an integer. When this element's missing, its content should be assumed to be "60". It may have one attribute, namely "span", whose content may be "seconds", "minutes", "hours" or "days"; It is assumed to be "seconds" when missing. This attribute specifies what type of time measurement is the content of the element, namely seconds, minutes, hours or days. The purpose of this element is to specify the minimal time that has to pass between refreshing of the feed from its originating source. It is recommended that implementors adhere to this element and refresh the feed according to its content. The <generator> Element<a name="spec_channel_opt_ele_generator" id="spec_channel_opt_ele_generator"></a> <div class="code"> <!ELEMENT generator (#CDATA) > <!ATTLIST generator url (#CDATA) #IMPLIED > </div> The <generator> element's content must be a simple string. Its purpose is to describe or name the application that produced the document. It may have one attribute, namely "url", whose content must be a valid URL, in theory linking to the website of the generator. The <docs> Element<a name="spec_channel_opt_ele_docs" id="spec_channel_opt_ele_docs"></a> <div class="code"> <!ELEMENT docs (#CDATA) > </div> This element's content is a simple string and is supposed to contain the URL of the current specification. Its purpose is to provide further information to readers encountering the RSS document. The <item> Element<a name="spec_item" id="spec_item"></a> <div class="code"> <!ELEMENT item (title | link | description | icon? | guid? | copyrights? | language* | pubDate* | comments* | author* | field*) > </div> Every channel in an RSS document must contain at least one item. An RSS item is a floating point of metadata within the document itself, set into a pre-made structure. An item represents a piece of something bigger than itself, like a summary and link to some piece of writing, application or anything at all. An item contains at least the basic information a processor needs to provide the user a usable headline and address of the piece in question. An item may have one optional attribute, at least three required sub-elements and several optional sub-elements. Optional Attributes<a name="spec_item_opt_att" id="spec_item_opt_att"></a> The <item> element may two or three attributes, all optional. The first two are the "isUpdated" and "updateNum" attributes whose syntax and purpose have been described under <a href="#spec_common_elements">Common Elements and Attributes</a> above. The third one is the "isEmpty" boolean attribute, presumed false when missing. This attribute is set to true to indicate that the entire content of the item's metadata is empty (the three required sub-elements are present but empty), though even if the item's sub-elements do hold content implementors must not process them. Required Sub-Elements<a name="spec_item_req_ele" id="spec_item_req_ele"></a> The <item> element requires three required elements: <title>, <link> and <description>, the syntax of which is described under <a href="#spec_common_elements">Common Elements and Attributes</a>. They should be used in the following fashion: <ol class="NormalText"> <li>The <title> element should contain the title of the item in question</li> <li>The <link> element should contain a valid URI pointing to the full item or the item's destination</li> <li>The <description> element should contain a theoretically brief (though unrestricted in length) description of the item (but not the content of the item's destination in any form)</li> </ol> Optional Sub-Elements<a name="spec_item_opt_ele" id="spec_item_opt_ele"></a> The <item> element may have four of the common optional elements, namely <guid>, <language>, <icon> and <copyright>, the syntax of which has been described under <a href="#spec_common_elements">Common Elements and Attributes</a>. Aside from the ones mentioned above, these are the other optional elements permitted beneath the <item> element: The <comments> Element<a name="spec_item_opt_ele_comments" id="spec_item_opt_ele_comments"></a> <div class="code"> <!ELEMENT comments (#CDATA) > <!ATTLIST comments type (post | read | both) #IMPLIED "both" > </div> The <comments> element is used to link to a URL relating to comments concerning the item in question. This element's content must be a valid URI. It has one optional attribute, "type", whose content may be either "post", "read" or "both" and is presumed to be "both" when missing. In theory, when this element's "type" attribute is set as "post" it is to be thought as a webpage in which the user can post a comment; When it is set to "read" it is to be thought as a webpage in which the user can read the comments and when it is set to "both" it is to be though as a webpage containing either or both of the methods. There may be two <comments> elements within the <item> element only if one has the "type" attribute set as "read" and the other as "post". The multiple elements rules<a name="multiple_ele_algo" id="multiple_ele_algo"></a>: <ul class="NormalText"> <li>There may be up to two <comments> elements as long as each of their "type" attribute has a different content which is not "both", specifically "read" and "post"</li> <li>Upon encountering more than one <comments> element of which the "type" attribute is set to "both" only the last one set so is to be processed</li> <li>Upon encountering two more or more <comments> elements whose "type" attribute is set to the same content only the latest one is to be considered</li> </ul> These rules apply, with change of the element, attribute and attribute's content (except for "both") to the <language> element and the <pubDate> elements. The <pubDate> Element<a name="spec_item_opt_ele_pubDate" id="spec_item_opt_ele_pubDate"></a> <div class="code"> <!ELEMENT pubDate (#CDATA) > <!ATTLIST pubDate rel (meta | link | both) #IMPLIED "both" > </div> Similarly to the <lastBuildDate> element, the <pubDate> element's content is a date complying with the IETF RFC822. It may have one attribute, namely "rel" whose content may be "meta", "link" or "both" and is presumed to be "both" when missing. This attribute's content is set according to whether the date describes the date on which the item was added to the feed (in which case its content is "meta") or when the item's link destination published (in which case the its content is "content") or "both", implying that the date is relevant to both the above notions. The purpose of this element is to specify the date of the publication of the item, whether within the feed document, the item's link destination itself or both. Similarly to the <comments> element above, there may be up to two <pubDate> elements present as long as in both the "rel" attribute is present, one set to "meta" and the to "link". The "<a href="#multiple_ele_algo">multiple elements algorithm</a>" described above applies here. The <author> Element<a name="spec_item_opt_ele_author" id="spec_item_opt_ele_author"></a> <div class="code"> <!ELEMENT author (#CDATA) > <!ATTLIST author name (#CDATA) #IMPLIED > <!ATTLIST author type (writer | co-writer | provider | contributor | editor | translator) #IMPLIED "writer" > </div> The <author> element is similar in syntax to the <webMaster> and <managingEditor> elements; It must contain a valid e-mail address and may have the string-type attribute "name" indicating the name of the owner of the provided e-mail. There may be as many <author> elements beneath the <item> element as needed. This element has an additional attribute, namely "type", whose content may be "writer", "co-writer", "provider", "contributor", "editor" or "translator", each describing the role of the author in question if needed; This attribute is assumed to be "writer" when missing. The <field> Element<a name="spec_item_opt_ele_field" id="spec_item_opt_ele_field"></a> <div class="code"> <!ELELEMT field (#CDATA) > <!ATTLIST field name (#CDATA) #REQUIRED > <!ATTLIST field guid (#CDATA) #IMPLIED > <!ATTLIST field type (string | boolean | float | integer | time | date | anyURI) #IMPLIED "string" > </div> The <field> element is designed to help implementors spare the work of expanding the document with new elements by providing this new element which may fulfill these needs. The <field> element may contain any form of content, as long as it not parsible (meaning, only plain text and no mark-up or escaped mark-up) and may appear as many times as needed within any given <item> element. It has one required attribute, "name", which is supposed to name the field, theoretically according to its purpose. Implementors can, for example, use the content of this attribute to describe the <field> element's content. There may be more than one <field> elements with the "name" attribute having the same content. The <field> element has two optional attributes, the first being "guid". Similarly to the <guid> element, this is a string given to uniquely identify the <field> element and therefore there may be no other <field> element with the same GUID in the document. Its content must be a numerical identifier rather than a URI. The second optional attribute is "type". Its content specifies the nature of the <field> element's content. The possible values for this attribute are detailed in the XML Schema Part 2 W3C Recommendation, specifically Appendix C. However, implementors may choose to ignore all datatypes except for "string", "boolean", "float", "integer", "time", "date", or "anyURI". It is assumed to be "string" when missing. HTML and XHTML RSS Linking Guidelines<a name="spec_linking" id="spec_linking"></a> This section describes how RSS 3 documents should be linked to in HTML and XHTML document (henceforth "(X)HTML"), for purposes of autodiscovery of feeds by user-agents (henceforth, "UAs") and also provides an XML element to be used in XML documents and even XHTML to be autodiscovered by UAs. General Linking<a name="spec_linking_general" id="spec_linking_general"></a> General linking of RSS 3 documents is defined by having a link present in the (X)HTML's <head> element's <link> element, thus linking the RSS 3 document to the (X)HTML page in general as opposed to a certain presentable element in that page in particular. A UA wishing to detect a linked RSS 3 document in the <link> element must conform to the following rules: <ol class="NormalText"> <li>The <link> element's syntax must conform to its specification; The current specification only describes its required content</li> <li>The <link> element's "rel" attribute must be present and must be set to "alternate"</li> <li>The <link> element's "href" attribute must be present and must contain the URI of the RSS 3 document, whether in file or service form Note (normative): In this particular case the content of this attribute may be a relative URI </li> <li>The <link> element's "title" attribute must be present and must begin with the content "RSS 3.x" where "x" is some integer, ideally the one of this specification, i.e. "RSS 3.0" yet it may have any other characters and words after these first seven characters</li> </ol> Normally the <link> element's "title" attribute is not required. However, in order to identify the item in question as an RSS 3 document its first five characters must be "RSS 3". UAs in attempt to decide what is the standard used in the linked item must not compare the entire content string given to the "title" attribute but rather retrieve its first five characters and compare it to "RSS 3". UAs attempting to decide what is the feed's subversion (i.e., 3.0, 3.1 etc.) should retrieve directly the seventh character (thus returning the subversion itself) or the fifth to seventh characters (thus returning the entire version). In order to title the link, its title must follow directly after the "RSS 3.x" string in the "title" attribute, separated by a space, as all characters after the above-mentioned ones are not to be considered by UAs unless for purposes of titling (in which case they may decide to drop the "RSS 3.x" beginning part of the attribute's content). Hypertext Linking<a name="spec_linking_hypertext" id="spec_linking_hypertext"></a> Hypertext linking is defined by a (X)HTML hypertext link, meaning the <a> element, which points to an RSS 3 document (whose purpose is outside of this specification's scope). A UA wishing to decide whether a certain hypertext link points to a feed must follow this rules: <ol class="NormalText"> <li>The <a> element's syntax must conform to its specifications; The current specification only describes its required content</li> <li>In attempting to decide whether a hypertext link points to a feed the UA should disregard all attributes whose content is not described here (such as "name", "target" etc.); Also, the UA must disregard the element's content if any</li> <li>The <a> element's "href" attribute must be present and must contain the URI of the RSS 3 document, whether in file or service form Note (normative): In this particular case the content of this attribute may be a relative URI </li> <li>The <a> element's "title" attribute must be present and must begin with the characters "RSS 3" (or "RSS 3.0")</li> </ol> The behavior of the UA towards the content of the "title" attribute is the same as the one described in the <a href="#spec_linking_general">above section</a>. XML Linking<a name="spec_linking_xml" id="spec_linking_xml"></a> The following element and its features may be present at any XML based document and is supposed to point to an RSS feed for the purposes of autodiscovery. For example, if this element is present in an XHTML document, a UA aware of this syntax will detect the RSS feed. <!ELEMENT rss:feed #EMPTY > <!ATTLIST rss:feed version (#CDATA) #REQUIRED > <!ATTLIST rss:feed url (#CDATA) #REQUIRED> <!ATTLIST rss:feed desc (#CDATA) #IMPLIED> Here are the rules for the interpretation and syntax of this element: <ol class="NormalText"> <li>This element will always be preceded by the "rss:" namespace and will always contain the xmlns:rss="https://rss3.org" attribute</li> <li>This element's destination will always be assumed to be an RSS feed</li> <li>The "version" attribute must be present and must contain at least the first number of the format's version (i.e., "0", "2" and "3") and may be formatted after the RSS 3 x.y version numbering conventions</li> <li>The "url" attribute must be present and must contain the URL pointing to the RSS feed; Note that this may be a relative URL</li> <li>The "desc" attribute is optional and is used to briefly describe the purpose of the linked feed</li> <li>Though there isn't any particular significance to the position of this element, when it is used in the XHTML format it is suggested to be placed under the <head> element</li> </ol> Exemplary element: <rss:feed xmlns:rss="https://rss3.org" version="3.0" url="https://rss3.org/official_blog/?feed=rss3lite" desc="The RSS 3 blog RSS 3 Lite-type feed " /> Expanding An RSS Document<a name="spec_extending" id="spec_extending"></a> Though the RSS format makes use of no namespaces, any element or attribute put into the document which is not a part of neither the lite-type nor the full-type specifications must be put under a namespace. It is further recommended that the namespace be declared using the "xmlns:" attribute-prefix on the <rss> element itself instead of the extended elements themselves. In relation to this specification a document detailing a select number of RSS function-specific extensions is available <a href="../extensions.html">here</a>. Temporary note (informative): While this specification is in drafts, any feature addition or alterations an implementor sees feat to perform should be sent to the editor of the current document for consideration. <hr> Appendices<a name="appendices" id="appendices"></a> The following sections are informative. A. Differences from The Previous Format<a name="appendices_differences" id="appendices_differences"></a> These are the differences in RSS 3 from the RSS 2.0.1 format. Note that elements present in the RSS 2.0.1 format but only present in the RSS 3 Full-type specification are not noted in the following lists. <ol class="NormalText"> <li>A list of alterations of the RSS 2.0.1 format: <ol> <li>There must be at least one channel containing at least one item in any RSS document</li> <li>The RSS document MIME type is "application/rss+xml"</li> <li>The content of the <language> element is now not specified by the W3C or Netscape documents but rather a compilation according to the RFC1766 (using the ISO639 required language prefix and the ISO3166 optional country suffix)</li> <li>The content of the <rss> element's "version" attribute is now set to "3.0" and the rules for its interpretation have been set</li> <li>The <language> and <copyright> element can be placed under the <item> element as well</li> <li>The <guid> element can be placed under the <channel> element as well</li> <li>The <pubDate> element has been moved under the <item> element and has been given a new purpose</li> </ol> </li> <li>A list of additions to the RSS 2.0.1 format: <ol> <li>The common "isEmpty" optional attribute</li> <li>The common "isUpdated" and "updateNum" attributes</li> <li>The <rss> element's optional "type" attribute</li> <li>The <rss> element's optional "source" attribute (which replaces the deprecated <source> element)</li> <li>The <managingEditor>, <webMaster> and <author> elements' optional "name" attribute</li> <li>The <author> element's optional "type" attribute</li> <li>The <generator> element's optional "url" attribute</li> <li>The <comments> element's optional "type" attribute</li> <li>The <pubDate> element's optional "type" attribute</li> <li>The <ttl> element's optional "span" attribute</li> <li>There may be, under certain circumstances, up to two <comments> elements</li> <li>There may be, under certain circumstances, up to two <pubDate> elements</li> <li>There may be, under certain circumstances, up to two <language> elements</li> <li>There may be as many <author> elements as needed</li> <li>The common <icon> optional element</li> <li>The <field> optional element</li> <li>The grounds for autodiscovery and hypertext linking of RSS 3 documents have been set</li> </ol> </li> <li>A list of removals from the RSS 2.0.1 format: <ol> <li>The <clouds> element</li> <li>The <skipHours> element</li> <li>The <skipDays> element</li> <li>The <textInput> element</li> <li>The <source> element</li> <li>The <pics> element</li> <li>The <guid> element's optional "isPermaLink" attribute</li> </ol> </li> </ol> B. The RSS Lite-type DTD<a name="appendices_dtd" id="appendices_dtd"></a> For informative purposes only here is presented the RSS Lite-type DTD. The reader is reminded that the RSS document itself must not rely on or direct to a DTD file.   <!ELEMENT rss (channel+) > <!ATTLIST rss version (#CDATA) #REQUIRED > <!ATTLIST rss type (lite | full) #IMPLIED > <!ATTLIST rss source (#CDATA) #IMPLIED >  <!ELEMENT channel (title | link | description | managingEditor? | webMaster? | icon? | generator? | docs? | ttl? | guid? | copyrights? | language* | item+) > <!ATTLIST channel isEmpty (true | false) #IMPLIED "false" > <!ATTLIST channel isUpdated (true | false) #IMPLIED "false" > <!ATTLIST channel updateNum #IMPLIED "1" > <!ELEMENT managingEditor (#CDATA) > <!ATTLIST managingEditor name (#CDATA) #IMPLIED > <!ELEMENT webMaster (#CDATA) > <!ATTLIST webMaster name (#CDATA) #IMPLIED > <!ELEMENT lastBuildDate (#CDATA) > <!ELEMENT docs (#CDATA) > <!ELEMENT generator (#CDATA) > <!ATTLIST generator url (#CDATA) #IMPLIED > <!ELEMENT ttl (#CDATA) > <!ATTLIST ttl span (seconds | minutes | hours | days) #IMPLIED "seconds" >  <!ELEMENT item (title | link | description | icon? | guid? | copyrights? | language* | pubDate* | comments* | author* | field*) > <!ATTLIST item isEmpty (true | false) #IMPLIED "false" > <!ATTLIST item isUpdated (true | false) #IMPLIED "false" > <!ATTLIST item updateNum #IMPLIED "1" > <!ELEMENT pubDate (#CDATA) > <!ATTLIST pubDate rel (meta | link | both) #IMPLIED "both" > <!ELEMENT author (#CDATA) > <!ATTLIST author name (#CDATA) #IMPLIED > <!ATTLIST author type (writer | co-writer | provider | contributor | editor | translator) #IMPLIED "writer" > <!ELEMENT comments (#CDATA) > <!ATTLIST comments type (post | read | both) #IMPLIED "both" > <!ELELEMT field (#CDATA) > <!ATTLIST field name (#CDATA) #REQUIRED > <!ATTLIST field guid (#CDATA) #IMPLIED > <!ATTLIST field type (string | boolean | float | integer | time | date | anyURI) #IMPLIED "string" >  <!ELEMENT title (#CDATA) > <!ELEMENT link (#CDATA) > <!ELEMENT description (#CDATA) >  <!ELEMENT icon (#CDATA)> <!ATTLIST icon width (#CDATA) #IMPLIED > <!ATTLIST icon height (#CDATA) #IMPLIED > <!ELEMENT guid (#CDATA) > <!ATTLIST guid type (code | url) #IMPLIED "url" > <!ELEMENT language (#CDATA) > <!ATTLIST language rel (meta | link | both) #IMPLIED "link" > <!ELEMENT copyright (#CDATA) >  C. Validation XML-Schema<a name="appendices_schema" id="appendices_schema"></a> (Only upon publication of the Final Draft before the Final Standard version) D. XSLT for Display of RSS 3 Lite-type Feeds<a name="appendices_xslt" id="appendices_xslt"></a> (Only upon publication of the Final Draft before the Final Standard version) E. Sample Feeds<a name="appendices_sample" id="appendices_sample"></a> For informative and exemplary purposes only, here are presented samples of RSS documents complying with the specification detailed in this document. An empty feed (basic structure only): <div class="code"> <?xml version="1.0" encoding="UTF-8" ?> <rss version="3.0"> <channel isEmpty="true"> <title>An Empty Channel
 http://www.some-fake.url
 This is an empty channel
 
 
 
 
 
 
 
 A full-fledged features feed:
 
 
 RSS Version 3
 https://rss3.org/
 This is a sample RSS 3 Lite-type feed
 
 Sun, 14 Aug 2005 09:53:59 +0000
 http://no.address/
 en
 https://rss3.org/files/r1.ico
 Jonathan Avidan 2005 (c)
 
 
 7
 https://rss3.org/rss3lite.html
 
 RSS 3 Lite First Draft Now Available
 https://rss3.org/archive/rss3lite/first_draft.html
 The RSS 3 Lite-type specification first publicly available version
 
 Sun, 18 Aug 2005 09:53:59 +0000
 
 6457894357689
 
 
 
 Welcome to the RSS 3 Official Blog!
 https://rss3.org/official_blog/?p=2
 The RSS 3 Official Blog welcome message
 
 https://rss3.org/official_blog/?p=2#comments
 Wed, 27 Jul 2005 14:34:51 +0000
 
 https://rss3.org/official_blog/?p=2
 
 
 
 
 D. Errata
 
 From the First Draft stage (in order of correction):
 1. Appendix A, 'isPemraLink' > 'isPermaLink' (thanks, Mark)
 2. Appendix A, removed entry about removal element
 3. Several errors of phrasing (thanks, Anosh)
 4. Under 'the "isUpdated" and "updateNum" Attributes', under the 'Rule', the last occurence of "updateNum" corrected to "isUpdated" (thanks, Jase and Spud)
 5. All instances of have been corrected to
 End of document.
 
 Navigate: Home | Blog | Message Board | FAQ | Extensions | Specifications | Requirements | Terminology | RSS 3 Lite | Links | Contact Us
 
 ©2005 Jonathan Avidan - Created using Nvu - Distributed under the Attribution/Share Alike Creative Commons License