Note to Dave - Mark may have said he does not like outliners; however, he DOES understand the power of an outliner:
I like to edit Python code in an IDE (or in Emacs in python-mode), which autoindents for me and allows me to “fold” code blocks (collapse an outline node) that I’m not currently using.
He’s already got what you’re offering him in Radio’s outliner (the one Frontier programmers all love)- but without the ability to easily edit that same script in some other text editor.
Mark Pilgrim investigates OPML. He makes some of the same observations that I’ve made in the past (unfortunately I don’t believe I published any of them, so go read his).
OPML is a nice idea, but is limited by Dave’s view that XML circa 1998 is all anyone should ever need, and his dislike for namespaces and subsequent refusal to update Frontier XML parser to support them.
For the record: having an xml-based outline format is an excellent idea! XML is perfect for describing hierarchies. Of course, an outline is often pretty boring unless you can also describe what the nodes represent. So Dave came up with nodetypes. Nodetypes allow you to say “this node represents an mp3 file” or “this node represents a Manila website structure”. This also is an excellent idea. However…
In order to be XML compatible/compliant, (and I DO mean XML circa 1998 or thereabouts) OPML needs to have a DTD against which strict parsers can validate the document. However (and I can’t find the reference at this time) OPML does not define what attributes can or cannot appear in an <outline> node. The only required attribute is the “text” attribute which contains the text of the outline heading. This is a problem because each nodetype uses a seperate set of attributes contained in the <outline> node to store information. This makes it impossible to develop a DTD for any OPML file because it may contain arbitrary attributes on a node.
The accepted solution to this problem in 98% of the XML-using world would be to break out nodetypes into their own namespaces. Define OPML-the-structred-document as simply as possible: <opml>, <head>, <body>, <outline>. Then, let applications thereof define their own elements and attributes, point those namespaces at their own DTDs, and then a parser that cares about such things can compare the OPML document to the included DTDs, and be happy. Meanwhile, parsers that don’t care could ignore the DTDs and keep right on going.
Of course, Frontier’s parser has not changed much since being “kernelized” a while back, and it does not support namespaces. So no Userland XML will ever make use of them, which is sad because I think XML Namespaces have “grown up” since their introduction, and are a big part of taking the web to the next step.
Dave points to my coffee cup radioFeedIcon. It was really easy to do with Conversant’s Resources. I just put \radioFeedIcon\ in my template or message.
Conversant offers a LOT of options when it comes to outputting your content. Any page can have it’s MIME type set, and templates (cf 1, 2) can be anything, including HTML, XML, I even tried RTF once. (No go on that one. ;-))
In the case of my RSS feed, the feed is a WeblogViewPage. The WeblogViewPage lets me create any number of ways to deliver my weblog content, in the past I’ve seen RSS, Avantgo, and OPML versions of Conversant weblogs using this technique.
Oh, and Dave, it’s Steve, please. ;-)
Hmm. thanks to my referers, I have found that I have the #3 and #4 hits for RSS Sources on Google. Cooool. I need to rewrite my rss feed.
This rssFeedIcon is a test.
This radioFeedIcon is too.
Thanks to my handy content management system, I’ve added some Dublin Core meta data to my templates. There’s more metadata on inner pages of the site (due to the message architecture of Conversant) than on the weblog. Once I migrate to XHTML (another goal of this site) I’ll likely redo the meta-data as RDF.
Since things have been slow at work, I’ve continued on development of the “RSSPuller”. It now reads RSS 0.91, 0.92, 0.92d2, and RDF 0.9 Simple. The code is also much better factored now, resulting in less debugging time. Thanks to the iDO Script scheduler, it’s running (4 times successfully now!) every 30 minutes on my work machine.
Aaron Hillegrass, WebObjects Yoda-type, has written a presentation program called BigShow that uses XML as the file format. Mmmm, XML.
“Power corrupts, PowerPoint corrupts absolutely.” — Edward Tufte
I did a little tool for Radio Userland that renders the htmlDirectory as RDF, in the fashion of the Open Directory’s RDF dump.
For a while I’ve wanted to get RSS running on this site. Conversant doesn’t generate RSS natively, but that’s no real limitation. Through the power of an extraordinary array of templates, and some query creativity, we present:
Recent Stuff RSS. First implemenation, query page based.
Redmonk RSS. Weblogview implementation. Simpler for me, maybe faster for you.
