The RSS 3 Requirements Page

This page specifies the requirements to which the RSS 3 standard must comply in the process of its creation which is detailed here for the sake of public transparency.

The terms usages described in the Terminology page are imperative to the understanding of the following document.

Introduction

This section is informative.

The RSS 3 Standard is supposed to replace the outdated RSS 0.9x and RSS 2.0 ones by extensively documenting the RSS language, thereby solving common problems with the existing standards.

The RSS 1.0 is out of this standard's scope, though it's worth mentioning that 1.0 and 3.0 standards exclude each other due to immense structural differences.

Also worth mentioning is that the Atom syndication standard, currently in development, is out of this standard's scope and does not concern it. Due to contradiction in structure, the standards cannot rely on one another, yet an implementing client should support both standards.

RSS, or Really Simple Syndication, is an XML-based method of transmitting online metadata concerning renewing resources. Meaning, it is a way to broadcast items (commonly: updates, news, links etc.) in a simple manner via the Internet. However, the 0.9x standards contradict each other and the RSS 2.0 which was their derivative is useful yet underdocumented, with poor support for modern needs.

RSS 3 is meant to replace the previous standards while complying to the Requirements stated below. The standard will be created using the Process stated below. Please note that the Requirements section is normative is unlikely to be changed after the publication of the First Working Draft, the Process section is informative only and is subject to change, if necessary.

Process

This section is informative.

Note: The section below is relevant to all specifications produced in this site, namely RSS 3 Lite, RSS 3 Full, RRDL and RCDL.

Once the requirements page is set, the creation of the standard, complying to the Requirements stated below, will start with producing the Initial Draft (or the "Community Draft") for private reviews purposes. After the necessary changes, the First Working Draft will be published after which the First Call for Comments will be made public.

A Call for Comments is the stage in which readers of the draft are encouraged to submit their reviews either to the Message Board or by mail to the editor, detailing their opinions about what should be changed, what should be added and what should be removed (hopefully with proper explanations).

There shall be three Working Drafts, followed by a Last Draft which will be proceeded by the Final Call for Comments. Once the new changes, if any, are implemented the Final Standard will be published. At that time it will be considered for submission to a formal standards body, if necessary.

In summary, these are the standard's development stages:

  1. Initial (or "Community") Draft - private reviewing purposes
  2. First Working Draft - including the Call for Comments for revision and refinement
  3. Second Working Draft - likewise
  4. Third Working Draft - likewise
  5. Last Draft - including the Final Call for Comments
  6. Final Standard - the official specification

Once the Final Standard is complete and published, an Errata section will be maintained describing errors in the original standard, in case they are found. When a document after its final stage is revised or in any way corrected, it shall receive the informal version status of x.y.z, in which X represents the standard level (i.e. RSS 3 would have the number 3.y.z), Y represents a revision if any (i.e. the Final Stage document would be RSS 3.0.z) and Z represents a correction if any (i.e. RSS 3.0.1 would represent a document which refers to the 3.0 standard but has one or more corrections within it). Errata are correction pertaining solely to the wording of the specification and must not change any behavior or feature describe in it.

Furthermore, once the RSS 3 final standard starts to be implemented in different clients, a Call for Revision stage will take place, and if necessary, produce a 3.1 standard and specification (though it is aspired to avoid a 3.2 revision).

The right to refuse implementing requested changes, additions or removals is reserved to the editor. In case a requirement is to be changed or removed, it will be noted in a new section of the current page, the Archive, noting the change and explaining it.

Requirements

This section is normative.

Here follow the requirements to which the RSS 3 standard (henceforth "the Standard") must comply.

RSS Version 3 Standards:

  1. General RSS 3 Requirements:
  2. The Standard must not contradict any relevant existing W3C recommendation
  3. The Standard must rely on XML 1.0 and its documents must be valid XML documents
  4. The Standard must not require the use of any form of scripting within the standard itself (i.e., no scripting within the XML file, though scripting to handle it is naturally allowed)
  5. The Standard must not rely on either a DTD or an XML Schema or any sort of validation mechanism
  6. The Standard must not rely on the use of any XML extension, such as xml:id, xml:lang, etc.
  7. The Standard should strive to remain as backwards compatible as possible with the RSS 2.0 standard
  8. As a result of striving towards backwards compatibility, the Standard must not rely on XML Namespaces
  9. If and when the Standard does contradict the RSS 2.0, it should be noted once where that feature is first explained and also in a special appendix
  10. Also required is an appendix consisting of a summary of all the changes, additions and removals from the RSS 2.0 standard
  11. The Standard must not rely on the RRDL and RCDL standards which are offered as further extensions
  12. The different versions of the Standard (Initial Draft up to Last Draft, excluding the Final Standard) must be archived and publically available

    RSS 3 Separate Standards Requirements:
  13. The Standard is to be split into two separate but highly related specifications:
  14. The RSS 3 Full and RSS 3 Lite specifications must not contradict each other in any form or manner
  15. RSS 3 Lite should be designed with minimal, lightweight features to be implemented, in theory, in a client which does not require the full functionality of the complete (i.e. RSS 3 Full) standard
  16. RSS 3 Full must consist of all the RSS 3 Lite features, including other, more complex features, in theory designed for high-end clients
  17. The Standard is to be designed with the ability to make transparent to the client which current RSS-type is used, though in theory a client which can process either or both of the types can process any RSS 3 document due to complete interoperability
  18. The Standard must provide exemplary an XSLT file to visually display the contents of an RSS file in the RSS 3 Lite type
  19. The Standard must provide an XML Schema for validation of the format
  20. The Standard must provide a DTD for the elements and attributes of the format
  21. Each specification must provide two examples of their RSS-type document, one empty and one displaying all their features

RSS Category Declaration Language (RCDL):

  1. Alongside the RSS 3 Specifications and as a part of the RSS Version 3 class of standards, another specification is to be produced - RSS Category Declaration Language (RCDL)
  2. This language should be used to declare which categories an RSS feeds used in categorizing and cataloging its channels and items (only in RSS 3 Full)
  3. The language is to be XML-based and compliant
  4. The language must not require the use of any form of scripting within the file itself
  5. The language must not rely on the use of a DTD or an XML Schema
  6. The language must provide an exemplary RCDL file

RSS Rating Description Language (RRDL):

  1. Alongside the RSS 3 Specifications and as a part of the RSS Version 3 class of standards, another specification is to be produced - RSS Rating Description Language (RRDL)
  2. The language should be used to describe what content the RSS element may contain and what does it depict
  3. The language is to allow several classes of ratings within thee RRDL file for the RSS rating element to pick which one to use
  4. The language is to be inspired by the general PICS concept, yet is to be simply structured, easily understandable and XML-based and compliant
  5. The language must not require the use of any form of scripting within the file itself
  6. The language must not rely on the use of a DTD or an XML Schema
  7. The language must provide a standardized common file for wide use depicting age appropriateness

Any objections or questions concerning the requirements stated above are to be sent to the editor or posted in the Message Board.


Navigate: Home | 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