Well, I've updated the Info Bite List specification again, based partly on some of the issues mentioned at the end of a recent posting here. Today, I'll talk about the changes and why I made them as a round-about way of discussing issues facing all RSS-like formats.

First, I changed the default mode for content from XML to escaped. I had originally adopted the Atom convention of defaulting to XML, based on the fact that the Atom folks had been considering the issue a lot longer than I had, so they probably made the right decision. However, after studying the issues, I've changed my mind. Info Bite List is intended to be able to carry whatever sort of payload the publisher wishes. By setting the mode to xml, escaped, or base64, Info Bite List and Atom can both accommodate just about anything. But I think the default should reflect the method that seems most likely to avoid the need to override the default in the most cases, and which seems most likely to make publishing and consuming feeds as easy as possible. The current state of things, which seems likely to continue, is (as far as I know) that most feeds contain HTML or plain text content. Most don't contain XHTML, or any other brand of XML. Perhaps defaulting to xml would prompt people to move from HTML to XHTML, but I don't at the moment feel the need to press the issue. That being the case, escaped seems the most useful mode. Also, though I'm sure some people would disagree, I don't see the need to have feed parsers parse the content of the feeds (meaning the stuff inside the description elements, etc.--of course they have to parse the feeds themselves). That intelligence seems better to leave up to the rendering code than the parsing code.

Another change was to add xml:base processing. Here I contradict the last statement made above, because xml:base processing is to be applied to all element content, which will require the parser either to know something about the format of the content, or to know how to pass on the xml:base setting to the renderer. Well, it's not a perfect world, is it? In support of my decision to keep this contradiction, xml:base processing does not require as much knowledge of the format of the content as fully parsing it and then rendering it from it's parsed form would.

Going back to what I wrote a few days ago, I replaced the "rolepsec" element with individual elements for each legal value for the "rel" attribute: email, fax, ibl, name, nick, tel, and website. This will help validators, as well as making feeds slightly smaller.

Finally, I removed the "guid" element. I figured that a link with the "rel" attribute set to "self" would serve the same purpose sufficiently well (that was the method recommended over using guid anyway).

All the little nagging questions about the format have been cleared from my mind now, so I think this is the version I'll begin implementing. Now I just need to find the time.