I see some pros and cons to this effort.
Cons: RSS is already well established. It is simple, easy to implement and understand. In other words, done properly (which isn’t hard to do) it just works. I whacked together an RSS feed from a database in an hours or so – and it worked in aggregators straight up. I don’t think (particularly with RSS 2.0) that there is a significantly better mouse-trap. (I’m sure others disagree)
Pros: Ever since I first looked at RSS I couldn’t work out why auther and publication date of the individual entries were not included (not that I could see anyway). There were other annoyances, but that was the main one. It basically meant that RSS couldn’t be used for multi-author news. This didn’t make sense. However, (and that’s a big however), these gripes were fixed in RSS 2.0.
IMHO, weblog tools that include standard HTML as content in item and description elements shouldn’t – it should be well-formed XHTML. But this fact doesn’t seem to bother most RSS aggregators and other tools.
Looking quickly (read: skimming /really/ fast) at the WIKI for what the effort is discussing, this looks like it’s going to be another SOAP – really hard to use and understand. It looks as though it’s going to incorporate attachments and all sorts of cruft that make it hard to get up and running without pre-built libraries and a couple of weeks to get your head around the concepts.
But this is probably jumping the gun a little. As Sam states: “At the present time, I would like limit the scope of this wiki to describing a conceptual data model of what constitutes a well formed log entry.”
Maybe they’ll come to the conclusion that RSS 2.0 kinda does that, maybe they won’t…