One of the selling points of RSS 1.0 is its extensibility. Wiki pages come with a wad of MetaData?, most of which one might like to include in RSS data. The need for a wiki extension module for RSS seems clear. Consequently, we standardized ModWiki. To see the rationale for ModWiki, see ModWikiDevelopmentHistory.
Of course, ModWiki 1.0 can't be the last word. Here's some discussion about future directions.
mod_wiki (LaurensPit, et. al) :
I've started to work on my own UnifiedRecentChanges engine. Example (but not necessarily up-to-date) output is at http://www.dairiki.org/rss1.0/urc.rdf. (An ugly HTMLified version as at http://www.dairiki.org/rss1.0/urc.html.) I've hacked my personal PhpWiki so that directly generates an RSSified version of HammondWiki:RecentChanges (see http://www.dairiki.org/rss1.0/hammondwiki.rdf.)
More to come. Comments gladly welcome. --JeffDairiki
I'm very interested in this. I would like to write a Perl script that does this for UseMod page databases. This doesn't even have to be a patch to wiki.pl itself -- it could be a separate script, too. -- AlexSchroeder
What sort of meta-data are you wanting put put into your RSS output? Are the RSS 1.0 and DC properties (used as described above) sufficient for your needs? Or do you want to include more wiki-specific detail (e.g. diff links)?
Don't let the lack of a complete wiki RSS specification on this page keep you from writing your script. As this page, so far, is based solely on my own crackpot ideas (and I'm no expert on RDF or RSS) I've been waiting for feedback from others such as yourself before fleshing out the above "specs" more completely. (As far as I am aware, you, I and DaveJacoby are the only ones actively working on RSSified RecentChanges --- and Dave and I haven't been that active recently.) --JeffDairiki
I'm at the testing stage to do so for the [IAwiki]. I patched wiki.pl inside the
sub WriteRcLog thus keeping the RSS file up to date to the minute. I'm maintaining a small recent-recent-changes log file, which only contains 15 lines, being the last 15 unique pages changed. It reads it in each time, and then overwrites it each time. The [RSS file] is only bare bones at this time. I have yet to grok an extended version with all the dc stuff. I'll be copying the patch over onto UseMod:WikiPatches soon enough. -- EricScheid
PikiePikie v0.4 can generate an RSS feed from any page or from a specified list of pages. It's very recent code, but UserLand seems happy with the generated XML. Any feedback from other engines which can read RSS feeds would be most welcome -- StevePike.
PhpWiki (the latest code in CVS) now produces ModWikified PhpWiki:RecentChanges: http://phpwiki.sf.net/phpwiki/RecentChanges?format=rss.
(19-Apr-2002) Wiki:JspWiki provides RSS support since version 1.7.5. Questions, comments, etc. should go to http://www.ecyrd.com/JSPWiki/Wiki.jsp?page=RSSFeedForJSPWiki. Thank you =).
Implementation is pretty simple, I made it a little harder (and more flexible) by using SAX to generate it. ;)
See http://diveintomark.org/archives/2002/05/30.html#rss_autodiscovery (and the updates referred to at that page) for details of how the html <link> element can be used to enable news aggregators to find a relevant RSS feed, given only the name of the site. It would be good if wikis which adopted RSS feeds could also follow this emerging standard --LawrenceAkka?
I don't know much about RSS, but has this been submitted to others yet? I get the feeling that other similar standards are developed that may be incompatible. The URL http://purl.org/rss/1.0/modules/wiki/ does not seem to be attached to MeatBall:ModWiki. Perhaps it is time for someone to notify the above-mentioned RSS-DEV group, if this has not already been done. -- BayleShanks
I like it. With UseMod:WikiPatches/RssInclusion, this gets more usable every day. The patch does not use any of the tags in the wiki namespace, but adding it would be trivial. Since http://web.resource.org/rss/1.0/modules/wiki/ is still 404, validation does not happen. We should push this. -- AlexSchroeder
(ie. cooked page content, but no page wrapper)
hopefully machine readable (hah!)
Regarding the TextFormattingRules resource, after writing UseMod 2.0's parser, I'm almost ready to start writing a formal structure for WikiSyntax, one that should be generally considered reasonable by all wikis. Perhaps after I do that we can progress to a better WikiInterchangeFormat. -- SunirShah
The 1.0 spec puts the contributor's information inside RDF inside <dc:contributor>. This puts an additional burden on the parser to deal with RDF, and to allow the client to extract the wiki:host property from the RDF if they want the IP address. I've noticed that feedparser.py, a popular Python RSS library, can't handle this (another popular Python library, RSS.py, doesn't do extension modules like ModWiki at all).
Currently, feedparser.py puts the contributor's name into a top-level field called "rdf_value"; rdf_value is a sister field to "dc_contributor", which is left empty. That is, to access it, you do
feed.entries[entryNum].rdf_value. This isn't very intuitive. And feedparser.py ignores the wiki:host property. I was about to suggest to the feedparser project that they add a special case to accomodate ModWiki, but while I was writing it I decided that in fact it's really "ModWiki's fault" for making the standard complicated.
I suggest that the next version of the spec puts the username of contributor, if available, or the IP address, if available, straight into <dc:contributor>, as in <dc:contributor>BayleShanks</dc:contributor>. And add a <wiki:IP> element to hold the IP address.
I agree that it would be cooler to have an element representing the person, and then to represent the person's name and IP as attribtues inside that element, but that isn't really useful for interoperability unless it's in the context of a standard which is used widely by RSS feed parsers. Yes, ModWiki is a standard, but it's sort of a standard-within-a-standard; we shouldn't impose any more implementation complexity on the parser than the rest of RSS tends to impose.
In addition, we should be talking about the Atom equivalent to ModWiki (is there already a page for that?). Does Atom even support extension modules?
Oh, is it maybe because we haven't submitted to RSS-DEV yet? (hint, hint).
Do I have to submit this thing myself to make it happen? I don't want to because I don't really know as much about XML/RSS as some other people here, but I will if that's what it takes.
While working with mod wiki, I came to the conclusion that RSS 1.0 is totally overengineered. The only reason I'm trying to deal with it is because the library I am using (XML::RSS) supports it. RSS 2.0 has been very simple to use on several occasions, on the other hand. Atom is just as easy, but the requirement of using XHTML instead of any HTML version we please for the entry text itself was disappointing. Plus Atom has a whole lot of stuff about modifying entries that distracts. I think I will just focus on RSS 2.0 for future work, and rely on services like feedburner and libraries to do the hard work for me. (And in the dark corners of my heart I will keep RSS 3.0 alive, of course.) No commitment from my side, therefore. -- AlexSchroeder
Bayle, we should try to submit it again. I don't know what happened last time, but obviously we failed.
Alex, based on Aaron Swartz's RSS3 parody, and also for the same reason, I actually implemented MeatBall:action=rcsimple. I also think RSS is bad. It [wastes bandwidth], is ugly, is controlled by a small group of people who don't represent me, is not good XML semantics, and it shouldn't be XML in the first place.-- SunirShah
Cool. :) A minor quibble with the implementation: The current implementation seems to miss a "head item" (channel description):
Sunir, I completely agree with you about RSS and like your rcsimple format. I actually wrote a up a "Spine for the Web"  quite similar in spirit. Still, it would be great if you had an RSS feed. We're aggregating an RSS feed at  so we can follow people who are contributing to the PublicDomain, like BrandonCSSanders?. That would help our communities interact. I hope you might! -- AndriusKulikauskas
See also WeblogMetaDataInitiative.