Chapter 11. Developing New Modules
Inventions reached their limit long ago, and I see no hope for further development.
Sextus Julius Frontinus
In this chapter, we will create a new module and extend a desktop reader (AmphetaDesk) to understand it. We will also discuss the differences between the RSS 1.0, RSS 2.0, and Atom data models and the effect of these differences on module design.
11.1. Namespaces and Modules Within RSS 2.0 and Atom
As mentioned earlier, RSS 2.0 introduced namespaced modules to the simple strand of RSS. RSS 1.0 was designed with namespace support from the very beginning. The specification document states:
Other than not defining a namespace for the core elements of RSS 2.0, the modules work the same way as the modules for RSS 1.0: declare the module's namespace in the root element (which in the case of RSS 2.0 is, of course, rss) and then use the module elements as directed by their specification. Parsers that don't recognize the namespace just ignore the new elements.
11.1.1. Differences from RSS 1.0
RSS 1.0 modules can't be reused within RSS 2.0. To do so requires the feed author to declare two additional namespaces within the root element: the namespace of the module and the namespace of RDF. This isn't explicitly forbidden but is heavily frowned upon.
Because of this, you need to recall the simplest ways to convert between the default module styles. RSS 1.0 modules, you will remember, declare everything in terms of RDF resources. This is done with the rdf:resource attribute. For example, a fictional element pet:image, used to denote an image of the feed author's pet, is written:
<pet:image rdf:resource=" URI of image"/>
whereas in RSS 2.0, the default lack of RDF means you must just declare the URI of the image as a literal string:
<pet:image> URI of image</pet:image>
However, the differences go deeper than this, which you'll see when we design a new module: mod_Book.