In contrast to its predecessors from the RSS 0.9x family, RSS 2.0 can be extended through modules. A module consists of XML elements that can perform additional functions. The elements of a module have to belong to their own defined XML namespace.
With the namespace mechanism, RSS 2.0 uses a technique that was introduced at an early stage of the development of XML to extend and to combine XML vocabularies. If you are not familiar with the namespace mechanism, you can learn as much about it as is necessary to read on from the appendix (see section A.1).
Modularization and extensibility are also characteristic of the other two syndication formats you see in this book: RSS 1.0 and Atom. Basically, modules that are used with RSS 2.0 can also be combined with these vocabularies. There are additional restrictions in RSS 1.0 and Atom, however, which do not apply to RSS 2.0.
For some time RSS 2.0 extension modules were used mostly by technically interested bloggers, and remained a rather esoteric feature of RSS. This changed in 2005, with OpenSearch RSS, Media RSS, and the Simple List Extensions—three extension modules proposed by Internet giants Amazon, Yahoo, and Microsoft. The companies started to promote RSS as a key component of their future offerings. It is significant that in this case these companies stick to the concept of RSS as an open, non-proprietary standard.
The vast majority of RSS 2.0 feeds do not use any extension elements In statistics about the popularity of the RSS elements, offered by Syndic8, most of them don’t even appear (http://www.syndic8.com/stats.php?Section=rss#TagUsage).
In the following chapters you will once more encounter the question of how extensions are to be interpreted by XML vocabularies. It could be formulated like this: is it possible to define general mechanisms for extensions, or is it necessary to define for every format extension individually how a target application should process the new elements? The
discussions about RSS 1.0 and Atom make the problems concerning the extension of a syndication format explicit.
For now, it is sufficient to know that for many developers of other syndication standards, the namespace mechanism alone is not enough to define how a feed format can be extended.
An RSS 2.0 feed is allowed to contain elements from other vocabularies only if they belong to a defined namespace. There are no other restrictions. Extensions are only meaningful, however, if there is software to process the additional language elements.
In most cases, a prefix separated by a colon from the local name characterizes the element names that stem from an extension module. Examples are ssr:rdf or dc:author. Software that can’t do anything with these element names is allowed to just ignore them. The namespace declaration tells the processor which namespace these elements belong to.
The processor allocates attributes without a prefix to the namespace of the element within which they appear. The XML namespace recommendation allows to combine attributes with a prefix with elements from other namespaces.
The RSS elements themselves are not allocated to a namespace—the use of namespaces would interfere with compatibility with the predecessor formats. If it were necessary for the validation of an RSS document to declare a namespace, RSS 0.91 and 0.92 documents would inevitably be invalid. Winer himself, however, suggested later experimenting with a namespace for the elements of the RSS vocabulary—but ultimately without result (Dave Winer: Next Step in Syndication Technology, http://blogs.law.harvard.edu/stories/storyReader$419; see also Sam Ruby’s discussion about a namespace for RSS 2.0: RSS Namespace Proposal,
Namespaces are used by the other syndication formats as well, although in a more restricted and explicit way than in RSS 2.0. Winer doesn’t say anything in the specification about where in an RSS document extensions are allowed. Other authors like Morbus Iff (Kevin Hemenway’s pseudonym; short biography: http://www.oreillynet.com/pub/au/779; see also http://gamegrene.com/wiki/User:MorbusIff) referred to the fact that extension elements that are not descendants of channel or item can change the structure of an RSS document and can lead to incorrect processing of the documents (Extending RSS 2.0 With Namespaces,http://www.disobey.com/detergent/2002/extendingrss2/).
Again and again, Dave Winer has recommended using namespaces sparingly. Above all, he objects to the use of extensions where RSS 2.0 elements are sufficient (a practice he calls "funky"; http://backend.userland.com/davesRss2PoliticalFaq#questionWhatDoesFunkyMeanInTheContextOfRss20). The main interest here, again, is simplicity of the format for the user and the implementer. RSS achieves a lot, because it is a standard. Extensions that don’t establish themselves widely are meaningless—with the exception of extensions that were developed for specifically defined software. Here, too, the motto "less is more" applies. Modules with few, simple, and clearly defined elements are easiest to implement and have the best chance to win recognition on a broader level.
Dave Winer defined the first of the extension modules himself; it is called blogChannel. The blogChannel module introduces three new elements blogRoll, mySubscriptions, and blink. All three are descendants of the RSS channel element. The URI that defines the namespace of these elements is http://backend.userland.com/ blogChannelModule. Under this address you will find documents that explain how the elements of the module are to be used.
The blogChannel:blogRoll element contains the URI of an OPML document with the blogroll of the weblog the feed belongs to. (OPML, or Outline Processor Markup Language, is a format for outlines. Like RSS 2.0 it was developed mostly by Dave Winer. Appendix A provides a short introduction to this format. OPML can be used for structured lists of URIs, and therefore to exchange information about subscribed feeds between applications. Many feedreaders can export and import subscription lists as OPML files.)
The blogRoll:mysubscriptions element contains the URI of an OPML document with the feeds the author of the weblog has subscribed to.
With the blogChannel:blink element—which shouldn’t be taken completely seriously—the author of a weblog can advertise another weblog, the URI of which is the content of the element.
The blogChannel:changes element is supposed to prevent aggregators from using too much bandwidth. The content of the element is the URI of a document called changes.xml. If a feed containing the changes element is updated, it sends a ping to the server on which the file is located. Consequently, aggregators can use this document to identify the feeds that were changed, and don’t have to download all the feeds.
With the BitTorrent module (http://www.reallysimplesyndication.com/discuss/msgReader$201?mode=topic) the address of a BitTorrent seed can be indicated, through which data (mostly audio and video documents) that are also referred to in an enclosure element can be downloaded. The namespace for torrent, the only element of this module, is http://www.reallysimplesyndication.com/bitTorrentRssModule.
The default prefix is bitTorrent. The element should be used only in connection with enclosure, so that the remaining details within the parent item element refer to both. Dave Winer gives the following example (http://static.podcatch.com/ manila/gems/un/torrentRssExample.xml).
... <item> <title>Daily Source Code November 24 2004</title> <link>http://adam.opml.org/DSC20041124.mp3</link> <description>I finally got Patricia back on the mic to talk about another of her fabulous showbiz stories, today: Stevie Nicks.</description> <guid>http://radio.weblogs.com/0001014/categories/dailySourceCode/ 2004/11/24.html#a6900</guid> <pubDate>Wed, 24 Nov 2004 08:10:37 GMT</pubDate> <bitTorrent:torrent bitTorrent:url="http://torrents.podcatch.com/ DSC20041124.mp3.torrent"/> <enclosure url="http://adam.opml.org/DSC20041124.mp3" length="16716621" type="audio/mpeg"/> </item> ...
BitTorrent seeds can also be directly indicated within enclosure, if there is no alternative download address for the complete equivalent file (see also section 2.4).
Winer himself also developed the creativeCommons module. With the elements from this module it can be indicated on the level of the channel or the item, which of the different creativeCommons licenses is valid. The namespace http://backend.userland.com/creativeCommonsRssModule is defined for the creativeCommons module.
The module contains only one single element called license. If this element is used on the item level, it indicates only the license valid for that content. If, at the same time, a license that is valid for the whole channel is indicated, it will be overwritten for the relevant item.
The content of this element is formed by the URI of one of the Creative Commons licenses listed on the Creative Commons website (http://creativecommons.org/). It is specifically permitted, however, to refer to other licenses. The element can be used multiple times if a channel or element is published under more than one license.
In recent years there have been repeated attempts to define the topics of newsfeeds more clearly and conveniently than is the case with the category element. (Although category, as well, allows the reference to a nomenclature.) Matt Mower and Paolo Valdemarin presented an interesting attempt in that direction with Easy News Topics (ENT; http://matt.blogs.it/specs/ENT/1.0/). The category element isn’t sufficient for them, however, because it doesn’t allow for the indicated topics to be linked to a classification. The namespace for the ENT module is http://www.purl.org/NET/ENT/1.0/.
This extension has two main goals:
It is supposed to facilitate indicating the topics of entries in such a way that intelligent aggregators can compile thematic feeds. For example, aggregators can filter and recombine feeds that are equipped with the ENT identifiers. All other developers who suggested extensions for topics or categories up to now pursued the same goal—with only moderate success so far, because none of the systems has been implemented to an extent worth mentioning.
In their second goal, the developers of Easy News Topics differ from other systems with similar tasks: through linking, the Easy News elements are supposed to allow the use of more powerful and flexible standards. The ENT developers assume that other modules with similar goals couldn’t establish themselves because they are too complex and, for that reason, too difficult for most users.
The module defines only two elements, cloud and topic. The content of cloud is made up by any number of elements of the type topic.
The cloud element indicates a source for topics, and takes the form of a URI. This URI can refer to an RDF document, an OPML list, or a topic map that includes further
information about the topics. ENT doesn’t require the actual existence of a document under the URI. The application decides how to deal with a resource that can be found under the indicated URI. The element identifies the occurrence of a topic according to the topic map standard.
Topic maps are a standard for meta-information that overlaps in its functions with RDF. A topic map works like an index for any number of sources. The map doesn’t indicate words, but terms and concepts, that is, topics. In regards to the book that you are reading right now, RSS extensions, for example, could be such a topic. A topic map is an XML document with information about where topics occur in documents. In the topic map terminology these locations are called "occurrences" of topics. Moreover, the relationship between topics is described in a topic map as well. The extensions of RSS 2.0, for example, are connected with the topic extensions in a way that can be called a subclass-superclass relation. In this way semantic nets that describe a great number of different sources can be built. (You can find more information about this highly interesting technology on the topic maps site of the Cover Pages: http://www.oasis-open.org/cover/topicMaps.html).
cloud has three attributes. The href attribute is obligatory, and the two attributes infoRef and description are optional:
|
Attribute |
Description |
|---|---|
|
|
Refers to the URI of the source of the topics. |
|
|
Can include a URI under which information about this source can be found: for example, human-readable documentation. |
|
|
Serves the same purpose as the RSS 2.0 element with the same name, and can contain a short description of |
In the topic element "a named representation of a subject" is indicated. The topic can be simply indicated as a character string (PCDATA). In connection with cloud, however, topic allows unique identification of the topic of the entry. The topic element also has three attributes. The id attribute, which is obligatory, and the optional attributes classification and href:
|
Attribute |
Description |
|---|---|
|
|
Has to be a fragment identifier according to the valid definition of URIs (or IRIs, their internationalized version). It can appear within the chosen |
|
|
Contains the type of the topic. This attribute can only be used appropriately if a system that supports a classification is indicated as the cloud. |
|
|
Holds the URI of a site that is human readable and refers to the topic. |
The specification contains among others the following sample document:
<item> <title> <link>http://www.example.org/blog/2003/04/08.html#a855</> <guid>http://www.example.org/blog/2003/04/08.html#a855</guid> <pubDate>Tue, 08 Apr 2003 10:28:59 GMT</pubDate> <description>Here is the text of the item.</> <ent:cloud ent:href="http://matt.blogs.it/topics/ resources/topicRoll.opml"> <ent:topic ent:id="sf_giants">San Franscisco Giants</ent:topic> </ent:cloud> <ent:cloud ent:href="http://www.examples.com/mlb.xtm"> <ent:topic ent:id="barry_bonds" ent:classification="player">Barry Bonds</ent:topic> <ent:topic ent:id="ray_durham" ent:classification="player">Ray Durham</ent:topic> <ent:topic ent:id="felipe_alou" ent:classification="manager">Felipe Alou</ent:topic> </ent:cloud> </item>
Amazon developed probably the most interesting new extension. Amazon’s OpenSearch search engine called "A9" is further evidence of the considerable economic interest in RSS technologies—and certainly for the commercial possibilities of the format as well.
The extension "OpenSearch RSS" (http://opensearch.a9.com) serves to provide RSS 2.0 with language tools through which search results can be presented as RSS feeds, and can be received regularly. OpenSearch makes it possible to subscribe queries and to access their results in a feed reader or aggregator. The extension defines a standard format for the reproduction of search results. It is Amazon’s expressed intention, however, that the OpenSearch extension elements can be ignored by existing RSS readers.
Amazon’s search engine A9 (http://a9.com/) supports OpenSearch RSS 1.0. A draft of version 1.1 has been proposed; probably it will soon be finalized and implemented by A9.
OpenSearch provides an exchange format for search results. Sites that support this format can be registered with A9. A9 users can get search results from these sites in addition to default search results provided by A9’s partner Google. They can, for instance, add the Wikipedia and the Amazon Book Store to their personalized version of A9.
The basic premise of OpenSearch RSS is very simple: Today the results of search engines on the Web are normally rendered as HTML and therefore cannot be exchanged between sites. There is no automated way to combine the results of the search engine of a bookstore with those of another search engine used, for instance, by a public library. Users interested in results from both sites have three choices (and none of them is satisfying):
- They can use a general search engine like Google, which may be outdated, incomplete, and less specific compared to the search engines offered by the sites themselves.
- They can browse through results of both engines one after the other—this might be no problem in case of just two sites, but nearly impossible for a search within, say, 20 or more resources.
- They can use a meta search engine that, in most cases, will not exist because it has to be tailored individually for each of the sites that it supports. (This would mean that programmers have to analyze the HTML produced by each of the search engines and to write a sort of parser that extracts the results.)
Enter OpenSearch: search engines can now put out their results in a standardized extended version of RSS instead of HTML; the lists in this format can be processed without taking care of the specifics of each search engine. OpenSearch RSS does for search results what RSS did for newsfeeds: it allows for isolation of the content from its presentation, and for encoding it in a simple format with defined semantics.
Many prominent websites are already supporting OpenSearch, among them newpapers like the New York Times and USA Today, and specialized search engines like Findory. OpenSearch will probably get even more momentum because Microsoft announced to support it in the upcoming Internet Explorer 7. Users of IE 7 will be able to subscribe to search engines just as users of other browsers already can subscribe to newsfeeds—a feature that IE 7 will adopt.
RSS extensions form the central part of OpenSearch, because they allow for the exchange of search results between sites and services. In addition to these extensions, OpenSearch defines an XML document type for the description of search services, and a standardized query syntax. An application that is OpenSearch-enabled uses this description and the syntax to address queries to search engines that support OpenSearch.
The query syntax is defined by URI templates for HTTP queries. The templates contain an array of parameters; the service description document of a search engine informs a client which parameters the engine supports; the client replaces the parameters in the URI template by values to start a query.
OpenSearch version 1.0 introduces three new elements and a namespace of its own, http://a9.com/-/spec/opensearchrss/1.0/.
The search results themselves are characterized as RSS items. Within the item elements, link contains the link to the document that was found, title contains the title of the page, and description the beginning of the text. That is interesting, because this technology shows how common components of web presences can be semantically tagged with RSS. For this purpose, OpenSearch uses the already introduced RSS elements with the same name (which would remain in the RSS namespace if such a namespace were formally defined), but extends their frame of meaning.
With result lists of this kind, the name of the producer of the search results is to appear as the title of channel. Belonging to that information is the name of the search engine as well as the terms of the search. HTML markup should be avoided here.
The link element within channel refers to a website where the search results are to be found. The description element describes the search (and can contain simple protected HTML markup).
In addition, the extension introduces three new elements. The additional elements are descendants of the channel element and are located in the openSearch namespace.
The totalResults element indicates how many results the search engine has found:
<openSearch:totalResults>1000</openSearch:totalResults>
If the search came up with no results, 0 is supposed to be indicated. If the element is missing, the client can assume that all search results are included in the feed received from the search engine.
The startIndex element contains an integer as well:
<openSearch:startIndex>1</openSearch:startIndex>
It indicates which of the search results will be presented first. You know this procedure from all common search engines; the site usually starts with something like "1-10 of 1756 results". This element, like the other two, is optional.
The itemsPerPage element indicates the maximum number of results a page can contain:
<openSearch:itemsPerPage>10</openSearch:itemsPerPage>
In version 1.1 the extensions are called OpenSearch Response elements. The namespace is identified by the URI http://a9.com/-/spec/opensearchresponse/1.1. The elements are defined as an extension to RSS 2.0 and to Atom as well. A fourth element openSearch:searchTerms has been added; it is optional. As with the other OpenSearch elements, it can appear once at maximum. The extension is itself extensible; elements in other namespaces can be added as children of the OpenSearch elements.
The draft of the specification recommends using the link Atom element for extensions of the OpenSearch RSS elements. The specification proposes values for the rel attribute of this element to indicate the relation of a feed document to other documents. rel="alternate" and rel="self" need not be defined, as they appear in the Atom 1.0 specification. alternate points to an alternative representation of the same resource, usually to an HTML page. self points to the URI of the feed document. (The Atom specification states that all values of the element atom:link have to be registered at the IANA. alternate and self have already been proposed as value to IANA registry; see chapter 4).
The other values of rel proposed in the draft of the specification are specific to search results, and have still to be proposed to the IANA: start links to the first page of search results, previous to the previous, next to the next, and end to the last page. description refers to the description of the service in a special XML format.
Furthermore, the OpenSearch specification (http://opensearch.a9.com/spec/opensearchrss/1.0/) suggests methods to optimally use existing RSS 2.0 elements in connection with searches. Also, there is already the prospect of further versions of the OpenSearch technology with additional functions. The language choice, coding, spelling suggestions, multimedia results, and paid search listing are among the possible extensions mentioned. It is immediately obvious what possibilities such "saved searches" offer if they are combined with categories.
Yahoo! has publicly developed a media RSS specification (http://tools.search.yahoo.com/mrss/). (Dave Winer was irritated, and complained about how much of his work was used by Yahoo!—not only without mentioning him, but also without informing him.) Version 1.0 is used for Yahoo!’s video search (http://video.search.yahoo.com/). Meanwhile the developers have proposed a draft of a version 1.1 of the specification (http://groups.yahoo.com/group/rss-media/files/). The elements of the module are supposed to replace and complement the enclosure element and to allow a differentiated syndication of media. The module supports thumbnails, copyright information, and transcripts.
The namespace URI is http://search.yahoo.com/mrss/.
As a namespace prefix the specification itself uses media:.
Media RSS is adapted to the special requirements of movies and television shows and contains elements for the specific metadata items that frequently belong to such media. They are supposed to organize and indicate media content. Further describing attributes will be added in future versions.
If you want to incorporate references to media in an RSS feed, you have two alternatives: You can link to just one file or to several files with the same content adapted to different conditions of bandwidth and player software. With RSS Media you describe the individual files in both cases with the media:content extension element. If you offer several versions of the same content, use the element media:group as container for the descriptions of the individual files.
The media:group element is always a descendant of item. Its descendants are several elements of the type media:url, which refer to the same content, but to different representations of that content. The element is optional.
The extension element media:content is a descendant of item or media:group. Within an element of the type media:group, it can appear multiple times only if it refers to different representations of the same content. It is used to publish any kind of media. This element has the following attributes, almost all of which are optional:
urlindicates the URI of the medium. If this attribute is missing, an element of the typeplayerhas to be added.fileSizeindicates the size in bytes.typeindicates the media type (as a MIME type).isDefaultspecifies whether, in a group, this is the medium that is played back if there is no expressed requirement for a different one. Permitted values aretrueandfalse.expressioncan have the valuessample, full, andnonstop. The value indicates whether it is a sample or a full version;nonstopis chosen if the medium is continuously streamed.fullis the default value.bitratestates how many kilobits per second are contained in the stream. Withbitrate, streams with different download rates can be differentiated.framerateindicates how many frames per second are supposed to be shown for visual media.duration, height, andwidthindicate play-back time, size, and width.playerWidthandplayerHeightindicate the window dimensions of the software that plays back the media, andplayerURLindicates a URI that determines the play-back software.samplingrateis an optional attribute (since version 1.1) that can be used to declare how many samples per second were taken to generate the media object. The value is expressed in thousands of samples per second.mediumdeclares (optionally) the type of the medium; allowed values areimage, audio, video, document, andexecutable. The attribute was introduced in version 1.1. It helps the user to decide what he or she wants to do with a file and doesnt replace the declaration of the MIME type.langindicates the language used in the media (introduced in version 1.1). As values, you can use the language tags defined in RFC 3066.channelsserves to indicate the number of audio channels (introduced in version 1.1).
In principle, the two elements media:content and media:group can appear any number of times as descendants of the same element. However, the specification recommends sticking to the RSS rule that every item contains one "story", and within an item element to refer only to one item or one medium. As you may remember, in regards to the RSS enclosure element, a similar discussion is taking place about whether it can be repeated within item or not. If an item contains more than one medium, it can no longer be allocated to the URI that is indicated in link.
Further optional elements can describe item, media:content, or media:group (the latter in the namespace of the extension, labeled here with the prefix media:). They refer to a characteristic of this element.
media:ratingis used to declare the "permissible audience". It carries an attributeschemewith a URI do declare the rating scheme that is used. Examples for values used in the specification areurn:icra, urn:mpaa, andurn:v-chip. It is also possible to useurn:simpleas value ofscheme. In this case, the content of the element is simplyadultornonadult. In version 1.1 of the specification,media:ratingreplaces themedia:adultelement of version 1.0;media:adultis deprecated.media:titleincludes the title of the media object. There are no further rules. We dont get to know whether markup is allowed within the title or not.media:thumbnailcontains information about an image that is to be used as a thumbnail of the media object. The three attributesurl, height, andwidthindicate the URI, the height, and the width of the media object respectively.media:categoryindicates the category of the medium and is an example of an extension element that Dave Winer would call "funky". It doesnt have any other noticeable function than thecategoryelement, which already belongs to the RSS 2.0 language space.media:categoryhas two attributes:schemeindicates which taxonomy the term that identifies the category derives from, andlabelgives an identification of the category that is human readable.media:hashindicates the hash according to the MD5 message digest algorithm.hashcan be used to check whether a medium was fully transmitted or not.media:playeris supposed to allow a media player in a browser to open the medium.media:playerdeclares attributes as well:urlfor the URI of the player software,heightfor the height, andwidthfor the width of the window.media:creditcontains persons, companies, locations, etc., that have contributed to the creation of the medium. The optional attributeroleindicates which role the person or company played during the production of the medium. In the specification you can find an entire list of such roles, among themauthor, composer, andproducer. You can use theschemeattribute to declare the URI of the role scheme. As its default scheme Media RSS uses the European Broadcasting Union Role Codes; they are identified by the URIurn:ebu.media:textincludes the transcript already mentioned above. The attributetypewith the valuesplainorhtmlindicates in which text format the transcription is available.typeis an obligatory attribute. In the future it is also supposed to support text with a time code to allow subtitles for movies. In version 1.1 thelangattribute was added to indicate the language of the text.media:descriptionis an element added by version 1.1 of the specification. It contains a short human-readable description of the medium. The attributetypewith the possible valuestextorhtmlindicates the format of the description.media:keywordscan be used as a container for a list of human-readable descriptive keywords (since version 1.1).
Some of the language tools of Media RSS have functions you might recognize from the Synchronized Multimedia Integration Language (SMIL; http://www.w3.org/ AudioVideo/). SMIL too allows indicating alternative media, incorporating transcripts, and displaying copyright information. However, SMIL was explicitly designed to control the timing of presentations on the Web. The functions of Media RSS are only rudimentary in comparison to SMIL. In the past, SMIL has been propagated above all by the company Real Networks, which, as a provider of media on the Web, is a competitor of Yahoo!. This maybe one reason why this language wasn’t used to define a media module for RSS.
RSS originated as a news syndication format; consequently the members (items) of a newsfeed are ordered by their date of origin. Meanwhile many other different uses of feed formats were discovered; in some cases it made more sense to order the items of a feed with regard to other criteria than date. Microsoft has published an extension module for RSS 2.0 that gives the publisher the power to decide over the order in which RSS
items appear in a channel. (The URI of the specification is http://msdn.microsoft.com/windowsvista/building/rss/simplefeedextensions/.) With these extension elements you can, for instance, publish a photo feed and sort it by the names of the photographed persons or the subjects you like most—under the condition that the extension is supported by the software that consumes the feed.
Since Microsoft wants to make RSS a key feature of the next Windows version that is supported on the level of the operating system, it is highly probable that soon many applications will make use of this extension—notwithstanding that some prominent RSS and Atom developers remain skeptical about their usefulness (see http://dannyayers.com/archives/2005/06/24/ms-rss/). As for RSS in general, the applications can simply use the RSS-related functionality offered by Windows Vista.
The namespace of the Simple List Extensions is identified by the URI http://www.microsoft.com/schemas/rss/core/2005; the recommended prefix is cf. The element cf:treatAs (a child of channel) signals that a feed should be considered as a list. The specification states that it may be treated as a representation of a "complete, ordered list of content from the server".
The other elements describe properties that can be used to sort, group, or filter the content. The cf:listinfo element serves as a container for the information about the sorting or filtering criteria. It has the children cf:sort and cf:group. Both elements contain one or more children with a name that is also used as name of children of each item-element that belongs to the channel. cf:sort has an data-type attribute to indicate how the content used for sorting the members must be interpreted.
cf:sort and cf:group contain a text string with a human-readable name for the element used for grouping or filtering. This name will normally appear in an interface that allows the user to sort the items that belong to a feed. Thus you could, for instance, use an extension element with the name project:meetingDate to indicate that the items of a newsfeed contain information about meeting dates. As a child of cf:sort, it can serve to sort the items with respect to their dates even if they were published in another order. The content of the data-type attribute declares that the sorting should be based on the time-related content, not on the textual value of the element.
The Simple Semantic Resolution module developed by Danny Ayers plays a special role. I am introducing it as the last of the RSS 2.0 modules, because it leads on to RSS 1.0 and the RDF data model RSS 1.0 is based on. This module doesn’t complement RSS 2.0 with additional functions; it only concerns the interpretation of a document. The only element of the module says: This document can be interpreted as a valid RDF document and it can be translated with an XSLT stylesheet into an RSS 1.0 document. If you don’t know RSS 1.0, please read Chapter 3, which introduces this vocabulary in detail!
The SSR module belongs to the namespace http://purl.org/stuff/ssr.
Danny Ayers uses ssr as a prefix.
The module has only one element: ssr:rdf. If this element is included in an RSS 2.0 document, it tells the processor that it can be interpreted as RDF. Consequently, the processor can parse it in such a way that an RDF representation of the document is produced, that is, a directed graph with nodes and links. Furthermore, the module also uses one single attribute: transform.
The value of this attribute is the URI of an XSLT stylesheet. With this stylesheet the document can be transformed into the RSS 1.0 syntax.
Authors of other modules can use the module for Simple Semantic Resolution as well. If the semantics of their module is defined in a way that it can be presented as an RDF graph, they can communicate this information to a processor using the element ssr:rdf.
You will encounter the tasks of this module again in the next chapter. There, we will explain in detail what an RDF graph looks like, and when an XML document that doesn’t contain RDF elements can be interpreted as an RDF document.
There are many other RSS 2.0 modules; you can find a complete list at http://blogs.law. harvard.edu/tech/directory/5/specifications/rss20ModulesNamespaces. Many of these modules couldn’t establish themselves more widely; maybe they can be used as a starting point to develop future additions for this and for the other syndication vocabularies.
You will get to know one of the most important, and also most explored, possibilities for extending RSS in the next chapter: the Dublin Core vocabulary for bibliographical metadata. This module was developed in connection with RSS 1.0, but it can also be used together with the other syndication vocabularies without creating any problems. Some developers use elements like author from the Dublin Core vocabulary, because their semantics are defined more precisely than the language tools that are available to RSS 2.0.
As you can see, it is true that RSS 2.0 is "frozen", but the world of RSS modules is markedly active and becoming manifold. For several years, RSS 2.0 modules were developed apart from the mainstream and weren’t used very often. Since 2005, however, Internet giants like Amazon and Yahoo! have adopted this technology and apply it for tasks that play a central role in their strategy.