Let's go with that thought and see what RSS does for us, keeping our goals in mind: a format for saving an entire thread of messages from one of several kinds of discussion apps, with the ability to import it into another discussion app.

There are the runtime goals (what the standard accomplishes for users of the apps that support it), and the adoption goals (the standard is more useful as more apps adopt it).

RSS has a great adoption advantage in already existing and being supported by several interesting (albeit syndication-oriented) apps.

My hesitation is the runtime goal -- i.e. what RSS is intended for. Syndication is about periodically gathering summaries of the latest items from one publishing node and publishing them within another.

But people use RSS for other things (probably following the same reasoning we're using here: it's out there and it works), and that's one thing that caused the push to RSS 1.0, using RDF instead of a DTD, as Edd explains here: http://www.oreillynet.com/pub/a/network/20...zine/rss_intro.html.

Edd's article helps me in another area too: my big concern about crafting a DTD is how to allow for extensibility and how to carefully choose which items are optional. RDF allows that more flexibly it seems, at the cost of introducing a new meta-level of description. Aaron, were you a part of the decision making regarding the move to RDF? What were the considerations?

---

OK, now let's flip and ask from the other side: if we were to create a DTD, is it feasible to produce a DTD that's flexible enough? Can DTDs be extensible? That's where your XML expertise is needed, if you'll allow the thought experiment of a non-RSS solution for a moment.