Not microformated here!

Most people naturally find it more enjoyable to speak than to listen. Which developers would not like to be known as the one who wrote this killer app that the whole company now relies on, rather than simply the guy who made the suggestion to use somebody else’s? If we are honest with ourselves, most of us, “Y” chromosomed beings, usually find it hard to admit that somebody else had better idea than we did, or did as good a job implementing it than we could have done…

Even organizations with an open mind to leveraging external ideas may simply be unaware that what they need is already available. There is very often a certain amount of "herd instinct" driving “not invented here” in these groups of peoples. Even open-source communities don't always know that what they're creating has already been done, and even if they do know, many reasons can prevent them from using an existing solution other than NIH syndrome itself. A way to diagnose NIH syndrome is to go through these other reasons and eliminate them. If none of them apply, then you are probably looking at a real NIH syndrome case! The only valid reasons are:

• No existing suitable solution can be found, not even one which may be adaptable.
• A close-to-suitable solution is found, but solving 90% of the problem is not sufficient. In this situation, if the "90%" solution cannot be extend or customize it to fulfill 100% of the specification, then the potential solution is rejected.
• A close-to-suitable solution is found, but the work to extend or customize it to fulfill 100% of the specification is more than the work to reproduce it entirely. Again, the potential solution is rejected.
• A suitable solution is found, but one that is not compatible with existing or chosen standards. This solution is rejected.

…Atom answers more than 90% of what is required for an IM logging format…

Through this lengthy introduction I wanted to express my deep agreement with Hal’s answers to the legitimate question he raised on the use of Microformats in the XMPP standard: simply put, they usually do not make sense in a real time communication context. Microformats are a typical example of very narrow minded NIH syndrome. They initialy came up to solve rendering issues in a static location based web, when information was not available in an XML form (vCard, calendar). The initial authors found smart to leverage Microformat to lessen the shortcomings of existing crawler’s technologies, and thus added keywords to published information. Again, this was a valid move for static content. But when it comes to IM logs, I believe Microformats are definitively not appropriate. There is at least one existing XML markups available that would do it better than any coming Microformat: the Atom feed standard.

If one goes beyond the word “syndication” in the standard’s name, it can easily check how Atom answers more than 90% of what is required to store and communicate content and meta-data for an IM logging system! It just need to run Atom’s capabilities through the above reasons’ list…

Atom’s feeds and entries contain three elements:

• A unique identifier, which can be as simple as the URI of a blog entry or a truly unique 128-bit message stanza’s thread.
• A title, which expresses a short, human readable subject line for the entry, and can be a blank string.
• A time-stamp which indicates when the recorded feed or entry occurred.

A feed or entry can have multiple author elements along with zero or more contributor elements. These later elements identify individuals who might have contributed to the production of the feed or entry. Both the author and contributor elements are fully extensible, to provide as much detail about the author or contributor as deemed appropriate. Further, Atom provides a robust, flexible, and consistent content model capable of supporting plain text, escaped HTML, well-formed XHTML, arbitrary XML, base-64 encoded binary content, and URI pointers to content not included directly within the feed.

Finally for those who would be wondering about multimedia, Atom supports elaborate enclosures which have already been used in application such as podcasting, and would provide an excellent ground for future Jingle applications logging.

I am sure everyone will also understand the added value of the existing and growing support of Atom directly in the browser for rendering, and in the feed aggregators for syndication. That alone obsoletes many of the fallacious arguments used in some comments to Hal’s post to sustain the use of Microformats.

To conclude, I believe Atom provides more than 90% of what is needed for a superior IM logging format. As its transport over XMPP is already under way, it makes sense for the JSF to spend time defining a usage mapping for this new IM logging scope. Would it be as much fun as rewriting a new markup? No, almost certainly not. Would it be more efficient and cost effective? Quite certainly yes.

Technorati Tags: XMPP, Jabber, Atom, Microformat, Interoperability, Instant messaging, Antecipate