6 Choosing RSS V1.0

It is proposed that RSS V1.0 be adopted as a Recommended Standard and becomes mandatory in the future (subject to public consultation and further pilot testing).

6.1 Rationale for choosing RSS V1.0

6.1.1 The pilot

Twenty government agencies have piloted the RSS V1.0 standard since May 2003. The number of articles that passed through the service during the pilot is estimated as in excess of 2000.
The service included:

• a news-feed provided in the RSS format (described in this proposal)
• a news-fetch operated by the SSC EGU that collects and aggregates news stories from participating agencies
• a news syndication service operated by the SSC EGU, which allows agencies and other organisations to subscribe to the aggregated news-feed.

Main benefits included:

• syndicated news generates increased circulation
• news servers can automatically pick and republish content
• auto archiving ensures the portal only carries up-to-date news
• fewer data entry errors and multiple entries
• improved user experience because of its regional functionality.

There were some establishment costs. For the SSC EGU, these included:

• resource for coding the RSS schemas for participating agencies
• hardware and software resources for running the pilot service (this is not a resource or cost incurred for or by the RSS V1.0 standard itself).

For agencies, costs included:

• programming changes to the database or content management system
• using generally low/no cost RSS software for generating the news-feeds on the webmasters' desktop.

For a recent article outlining the rationale for choosing RSS V1.0 for the pilot and progress to date go to: http://www.readwriteweb.com/archives/001866.html This was later republished in Computerworld.

6.1.2 Fit with existing New Zealand standards

RSS is compatible with the mandated RDF and XML standards, as well as Dublin Core via NZGLS/Metalogue.

6.1.3 Machine readability

RSS is machine readable. This is critical for the automated nature of content aggregation and syndicated publishing.

6.1.4 Modularisation

Modularisation of specific functionality into the pluggable RSS modules is achieved by using XML Namespaces for partitioning vocabularies. This means that no reworking of the RSS core is required to add or remove RSS functionality. Instead it's just a matter of including a particular set of modules best suited to the task at hand.

Advanced applications of RSS require richer representation of relationships between intra- and inter-channel elements (e.g. threaded discussions). RDF provides a framework for this. RSS 0.9x provided a basic although limited RDF base upon which to layer further structure.

6.1.5 Design

[The descriptions included in 6.15 come directly from http://web.resource.org/rss/1.0.]

The RSS V1.0 design goal is an XML-based lightweight multipurpose extensible metadata description and syndication format. Backward compatibility with RSS 0.9 is a goal for ease of adoption by existing syndicated content producers.

Lightweight

Much of RSS's success stems from the fact that it is simply an XML document rather than a full syndication framework such as XMLNews and ICE.

Multipurpose

RSS is being increasingly used for more diverse applications. By using XML name-spaces and RDF functionality, RSS V1.0 can also be used for aggregation, discussion threads, job listings, real estate listings (multiple listing services), sports scores and document cataloguing.

Extensible

The crucial difference between RSS V1.0 and RSS 0.9 and RSS V2.0 lies in its extensibility via XML Namespaces and RDF compliance. Namespace-based modules allow compartmentalized extensibility. This allows RSS to be extended without:

• needing iterative rewrites of the core specification
• needing consensus on each and every element
• bloating RSS with elements that won't be used in any particular arena or application
• naming collisions.

Metadata

RDF allows for representation of rich metadata relationships beyond what is possible with earlier flat-structured RSS 0.9.

Syndication

Syndication in this context is defined as making data available online for retrieval and further transmission, aggregation, or online publication. The specifics of the various intricacies of syndication systems (such as free vs. subscription, push vs. pull) are beyond the scope of this specification.

Backward compatibility with RSS 0.9

Backward compatibility is accomplished by the assumption and stipulation that basic RSS parsers, modules, and libraries ignore what they weren't designed to understand. So if any instances of RSS 0.9 already exist they can be carried forward without further rework by the agency.

Modules

Namespace-based modularization gives RSS V1.0 compartmentalised extensibility.

6.2 Assessing RSS V1.0 against e-GIF criteria

The following table shows how the proposed standard meets the criteria for becoming an e-GIF standard.

Compatibility
Compatible with existing e-GIF standards.	- RSS is the "news instance" of RDF, already mandated in the e-GIF. - RSS is compatible with the mandated Unicode UTF-8 as the primary character set to handle two-bit character sets such as Māori macrons. - RSS is compatible with the mandated XML 1.0 standard for structured data. - RSS is compatible with the mandated XSLT standard for data transformation. - It is preferable that RSS element creations (such as creator, language, and publisher) be taken from the NZGLS Thesauri in Metalogue so that government-specific information descriptions are consistent with that standard, Subjects of New Zealand (SONZ), Functions of New Zealand (FONZ) and future Controlled Value (Vocabulary) Lists. Where information is not government-specific it can be taken from Dublin Core. Please note that RSS V1.0 is not compatible with previous versions of RSS 0.9x except through new translation applications such as SSR (Simple Semantics Resolution. http://ideagraph.net/xmlns/ssr/ ) and a variety of Open Source Software processors.
Consistent with private sector and international directions in interoperability.	Yes. It is supported by OASIS, W3C, IETF and XML.org amongst others.
Open - it is non-proprietary, available without restriction.	Yes.
In a technology area that is stable enough to permit standardisation.	Yes - data exchange.
Business need
The agency and collective needs that this addresses are clearly stated.	Consistent way of describing agency news items to allow data exchange for aggregation and syndication across multiple websites.
Functionality - the proposed standard must be:
Shown to meet the business needs	Already in pilot for one year with 20 agencies, with minimal issues. The EGU has developed best practice guidelines and the aggregator system. These will be reviewed, maintained and updated as circumstances require.
Preferably pre-existing - a need for a new standard will need to be justified.	RSS already exists and is developed from RDF, which also exists already.
Demonstrable, preferably with implementations from multiple sources. (Where the standard was created by an e-GIF working group, the group must show why it believes the standard should be implemented - this may involve building a proof of concept.)	Used extensively overseas (BBC, Wired and CNN). In New Zealand, the service and the standard definition was achieved with the help of many of the 20 agencies currently using the service in an informal working group context. The successful pilot provides evidence of proof of concept.
Shown to be properly engineered for security.	N/A. This is a data standard.
Impact and risks
The impact of implementing the standard must be analysed. The cost of this must not exceed the benefits identified. [This statement should be construed in an all of government context]	This standard will require no additional funding out of the EGU baseline for its ongoing governance and management, other than that already allocated for the pilot. For agencies, the impact is estimated as one to two days application development provided there is an existing news database or content management system "repository". In the unlikely event that an agency does not possess these, the only impact is that they will not benefit from the automation features of the service. The tagging of the news elements according to the standard specification serves as good practice. Furthermore, a forms client is freely available to generate RSS.
Risks of implementing the standard must be analysed and presented with likelihood, impact and any mitigations.	The risks are few and at a low level. There is a risk that an agency may be using 0.9x or 2.0 versions of RSS which are not compatible (though none are known by the authors). As applications are available to translate from one to the other, the risk of "collision" seems low.
The impact and risks of not proceeding should also be shown.	Continuation of existing situation will hinder the ability of agencies to circulate their news efficiently beyond their own website. Section 9.7 of the e-GIF indicates an intention for the standard to be introduced. The reasons not to proceed would need to be substantial and justified in a public forum.

6.3 Overseas examples

There are many hundreds of examples of RSS news-feeds from the private and public sector. Two examples are shown on the next pages. As with most organisations offering RSS functionality, a link to the RSS XML syntax is placed on the front page. The user invokes the RSS reader on the client/desktop to render the news-feed.

BBC Sports Scotland

Through the use of freely available desktop RSS readers (similar in concept to PDF) the feed is provided by the code (see below) linked from the home page above.

Canadian government

The Canadian government uses RSS extensively to deliver news by region and audience as shown in the next two screen shots.

[ Previous | Next ]