intertwingly

http://www.intertwingly.net/blog/?flav=rss2

Note: my only intent is to demonstrate what such a feed would look like in the hopes that this will influence the evolution of RSS.  I still feel strongly that RSS 0.94 should build upon a four year old standard instead of reinventing the wheel.

Note: despite the unusual rss version number, namespace declaration, and additional element, this feed seems to be happily consumed by Radio Userland's News Aggregator.

Expect to see comments appear and disappear on this entry as I test out support for saving personal information for frequent commenteers.

Cool!  Dave links.  But he's not sure what I want.  Perhaps it would help if I provided a few specifics:

Why invent item/pubDate when there already is dc:date?

Why must IM wait?

It is really cool that version N files are version N+1 files, but why can't version N+1 files be version N files?

In short, what I want is Modules.

Jon Udell: It's encouraging to see Dave Winer's statement in favor of namespaces and modular extensibility in the RSS 0.94 roadmap. Will the RSS 1.0 camp offer an olive branch of its own? I hope so.  Jon - if I read your suggestion correctly, are you suggesting that we give up on ever converging?

I hope 0.94 has an elastic wasteband.  The quick summary has been updated.  Meanwhile, it looks like the Really Simple Syndication essay is starting to be used as a BDG of sorts.

jim winstead has two beefs with RSS 1.0 that I agree with.  And seems to be the owner of 67 of the 68 RSS 0.93 feeds out there.

Gordon Weakliem: It seems to me that if you were generating proxy code for a WSDL contract and you hit <ANY> in a schema, the easiest thing to do would be to delegate to the programmer; i.e. give the programmer an XML Element and make her figure out what to do with it.  The next beta of Axis (and the current nightly builds) will map this:

<xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

into this:

private org.apache.axis.message.MessageElement [] _any;

Where MessageElement implements javax.xml.soap.SOAPElement from SAAJ and adds several methods, including a constructor that takes an org.w3c.dom.Element and a getAsDOM method which will return the DOM element.  There's actually plenty of other methods, so you don't need to go the DOM route, but it is there if you need it.