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.
Latest version:
Intermediate versions:
(Intermediate versions are edited specifications on their way to become a certain draft)
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.
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:
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, a 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.
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:
Inform the editor by sending a mail with the title "RSS 3 Lite" to this address: editor@rss3.org, or otherwise leave a message in a the appropriate board. To contact the site team concerning the site itself send a mail to webmaster@rss3.org. 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.
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:
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 here, using terminology described here using semantics detailed under Requirements and Terminology 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 appendices 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.
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".
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:
Comment: Notice that the formal encoding for RSS feeds is "UTF-8".
For information concerning expansion of this standard, see the section titled Expanding An RSS Document.
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.
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:
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
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)
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 <copyrights>, <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
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.
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
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 "updateNum" 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 time 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.
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 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 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.
<!ELEMENT guid (#CDATA) >
<!ATTLIST guid type (code | url) #IMPLIED "url" >
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> 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 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 <copyrights> element may be placed under the <channel> element and also under any <item> element.
Note that this feature is cascading. Therefore whenever a <copyrights> 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 <copyrights> 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.
<!ELEMENT rss (channel+) >
<!ATTLIST rss version (#CDATA) #REQUIRED >
<!ATTLIST rss type (lite | full) #IMPLIED >
<!ATTLIST rss source (#CDATA) #IMPLIED >
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.
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.
The <rss> element may contain two optional attribute, namely "type" and "source".
The "type" attribute's content must be either "lite" or "full".
It's 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'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.
The <rss> element must contain at least one <channel> element, the syntax of which is described below.
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.
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 Common Elements and Attributes.
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 Common Elements and Attributes.
These elements' content should be derived from the following stances:
A channel must contain at least one <item> element, even if the item is set to be empty.
The <channel> element may have several optional sub-elements. Four of which (namely <icon>, <guid>, <language> and <copyrights>) have been described under Common Elements and Attributes above.
Other elements are described in the following sections.
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 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.
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 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'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.
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.
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.
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 Common Elements and Attributes 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.
The <item> element requires three required elements: <title>, <link> and <description>, the syntax of which is described under Common Elements and Attributes.
They should be used in the following fashion:
The <item> element may have four of the common optional elements, namely <guid>, <language>, <icon> and <copyrights>, the syntax of which has been described under Common Elements and Attributes.
Aside from the ones mentioned above, these are the other optional elements permitted beneath the <item> element:
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".
These rules apply, with change of the element, attribute and attribute's content (except for "both") to the <language> element and the <pubDate> elements.
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 "multiple elements algorithm" described above applies here.
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 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
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 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:
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 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:
The behavior of the UA towards the content of the "title" attribute is the same as the one described in the above section.
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:
Exemplary element:
<rss:feed xmlns:rss="http://www.rss3.org" version="3.0" url="http://www.rss3.org/official_blog/?feed=rss3lite" desc="The RSS 3 blog RSS 3 Lite-type feed " />
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 or 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 here.
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.
The following sections are informative.
A. Differences from The Previous Format
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.
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.
<!-- RSS version 3.0 DTD scheme -->
<!-- Root element -->
<!ELEMENT rss (channel+) >
<!ATTLIST rss version (#CDATA) #REQUIRED >
<!ATTLIST rss type (lite | full) #IMPLIED >
<!ATTLIST rss source (#CDATA) #IMPLIED >
<!-- Channel element -->
<!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" >
<!-- Item element -->
<!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" >
<!-- Common required elements -->
<!ELEMENT title (#CDATA) >
<!ELEMENT link (#CDATA) >
<!ELEMENT description (#CDATA) >
<!-- Common optional elements -->
<!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) >
<!-- End of document -->
(Only upon publication of the Final Draft before the Final Standard version)
D. XSLT for Display of RSS 3 Lite-type Feeds
(Only upon publication of the Final Draft before the Final Standard version)
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):
A full-fledged features feed:
<item>
<title>RSS 3 Lite First Draft Now Available</title>
<link>http://www.rss3.org/archive/rss3lite/first_draft.html</link>
<description>The RSS 3 Lite-type specification first publicly available version</description>
<pubDate>Sun, 18 Aug 2005 09:53:59 +0000</pubDate>
<author name="Jonathan Avidan">jonathan@rss3.org</author>
<guid type="code">6457894357689</guid>
</item>
<item isUpdated="true" updateNum="1">
<title>Welcome to the RSS 3 Official Blog!</title>
<link>http://www.rss3.org/official_blog/?p=2</link>
<description>The RSS 3 Official Blog welcome message</description>
<comments type="both">http://www.rss3.org/official_blog/?p=2#comments</comments>
<pubDate>Wed, 27 Jul 2005 14:34:51 +0000</pubDate>
<author name="Jonathan Avidan" type="writer">jonathan@rss3.org</author>
<guid type="link">http://www.rss3.org/official_blog/?p=2</guid>
</item>
</channel>
</rss>
None.
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