Chapter 11. Developing New Modules

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:

    A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace. The elements defined in this document aren't themselves members of a namespace, so that RSS 2.0 can remain compatible with previous versions in the following sensea version 0.91 or 0.92 file is also a valid 2.0 file. If the elements of RSS 2.0 were in a namespace, this constraint would break, a version 0.9x file would not be a valid 2.0 file.

    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:

     URI of image</pet:image>

    However, the differences go deeper than this, which you'll see when we design a new module: mod_Book.

    Modules in Atom

    If you go to the version of the Atom specification I have based this book on, at, you will see that Section 9, the section designated to explain the expansion of the Atom format, is entirely empty.

    This presents a problem. I can't with any authority tell you what to do with an Atom feed. I can, however, make some suggestions. I don't think you will have any trouble if you use modules in Atom in exactly the same way as in RSS 2.0. The syntax can probably remain the same, although preferably, you should design the Atom module following the same pattern of constructs for people, links, and so on as the core Atom specification itself. It just makes coding easier. With that in mind, it is probably more sensible to design the module for Atom and move it to RSS 2.0, than the other way around. But again, I can't make any definitive statements on modules within Atom in this edition. For now, therefore, we'll talk only about RSS.