MeatballWiki | RecentChanges | Random Page | Indices | Categories

1. Introduction
2. History of Proposals
3. Implementations
4. RSS Auto Discovery
6. Future directions

1. Introduction

At least a couple of us, now, have starting playing around with generating RichSiteSummary descriptions of wikis. (See UnifiedRecentChanges.)

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.

2. History of Proposals

mod_wiki (LaurensPit, et. al) :

Original author statement.
I've created a proposal for a Wiki Module to extend RSS v1.0. I'm looking for more wiki software authors to add to the list of authors, hopefully get consensus, and then submit this to the RSS-DEV mailinglist. Comments are welcome of course. -- LaurensPit

General sentiment of Laurens ;)
Good work Laurens. Thank you for putting together the proposal and getting the ball rolling.

3. Implementations

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.)

The other wiki RSSification work that I'm aware of is that by DaveJacoby. See UnifiedRecentChanges for more on that.

I'm using some standard (and proposed standard) properties from the Dublin Core [1] and Aggregation [2] modules of the RSS 1.0 spec [3] to store some wiki meta-information in my RSS files:

Page name
Change summary.
Link to page (surprise, surprise).
(Most recent) page author.
Page modification time.
A URI which is unique to a particular RecentChanges entry (i.e. unique to a particular page version.)
Name of source wiki. (Comes from the title of the source channel.)
URL of source wiki. (Currently taken from the link property of either the image or the channel.)
Time that item got entered into my URC database.

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

Yes, that's exactly how I'm producing the HammondWiki RSS RecentChanges. (Except that HammondWiki is PhpWiki based, so it's a separate PHP script that produces the RSS.)

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

OpenWiki generates an RichSiteSummary feed, and can read RSS somehow: http://openwiki.com/?AllTheNews http://openwiki.com/?RssPage and http://openwiki.com/?BSD

Futhermore, OpenWiki can aggregate any number of RSS feeds, e.g.: http://openwiki.com/?AllTheNews/Aggregation

OpenWiki can also read ScriptingNews feeds, opening up a wealth of blogs to be included in the wiki, see e.g.: http://openwiki.com/?ScriptingNews

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.

I'm pretty sure that use of HTML within rss:description properties (or any of the #PCDATA properties, for that matter) is not kosher. Also, I think the format of dc:date should be ISO-8601 [4] (e.g. "2001-11-19T18:50:57+01:00" rather than "2001-11-19 18:50:57") --JeffDairiki

I know i don't understand RSS, but if i understand you right on this, i think a lot of RSS feeds do contain HTML, as it's the only way to include more than one link in one item. --JohnAbbe

PhpWiki (the latest code in CVS) now produces ModWikified PhpWiki:RecentChanges: http://phpwiki.sf.net/phpwiki/RecentChanges?format=rss.

WikkiTikkiTavi 0.21 provides RSS support. See, for example, http://tavi.sourceforge.net/index.php?action=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. ;)

MoinMoin:RecentChanges and MoinMoin:RecentChanges?action=rss_rc (matches v0.44) -- J├╝rgenHermann

I implemented UseMod:WikiPatches/ModWiki to roll into the massive MeatballWiki upgrades. I'm not sure if it's correct though. The validator accepts it though. -- SunirShah

4. RSS Auto Discovery

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

6. Future directions

Some suggestions:

    (ie. cooked page content, but no page wrapper)

    hopefully machine readable (hah!)

-- EricScheid.

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?

-- BayleShanks

The section Extending Atom is still empty. [5] Note that the same thing is trivial for RSS 2.0: Just use XML namespaces. [6] -- AlexSchroeder


Why doesn't this URL point to the ModWiki spec anymore?: http://purl.org/rss/1.0/modules/wiki/ -- BayleShanks

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.

-- BayleShanks

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):

"An RSS 3.0 document consists of one head item followed by zero or more body items." [7]

-- AlexSchroeder

I wrote up a spec of how I'm extending RSS 2.0 based on ModWiki: CommunityWiki:WikiModule. -- AlexSchroeder

Sunir, I completely agree with you about RSS and like your rcsimple format. I actually wrote a up a "Spine for the Web" [8] quite similar in spirit. Still, it would be great if you had an RSS feed. We're aggregating an RSS feed at [9] 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.



MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions