Scott's Workblog

This blog has moved! Go to my new blog!

August 13, 2005

Don't do it, Norm! [updated]

Norm Friesen's blog wouldn't let me comment, so here's my response to his Proposal: Chat and Discussion Interchange Datamodel.

Hi Norm,

I saw you'd posted this data model. Thanks for getting this out in public, I really needed to know about this! In the same spirit, I'll respond to the proposal with the sort of answer that doesn't normally get posted publically outside spec body fora ;-)

So, the main thing that strikes me about this is, why don't you like the existing IETF Atom and IETF XMPP specifications for representing forum posts and chat transcripts? They also define APIs for submitting, editing and removing messages. Why is there a need for a completely new data model for this? In fact, why is there a need for an ISO standard for this aspect at all, when this is covered by IETF already?

Atom format is the work of over a hundred contributors; the public list used to develop it has nearly five thousand posts on it - and thats just for the syndication format! At least give it a look before suggesting something else which looks about 90% similar.

You also mention IMS LIP, which is probably the last thing I'd use to represent a participant in a chat or forum - far better to reference a FOAF or even a vCard. (If you want to use IMS, Enterprise at least has the virtue of being briefer and more up to date.)

Atom simply uses "Author" and "Contributor", which you can link with canonical personal metadata via a URL reference (for example), or to contain a few bits of cached information (email address, a string for the name) if lookups are too expensive.

For setup and provisioning (as opposed to archiving or transfer) of forums and chats I'd also look at OASIS SPML for provisioning and XACML for representation of authorization rules. This is quite a problem area, and I'm not sure it should be tackled in the same chunk of work as moving forum posts around, which is a far simpler proposition that can be achieved with existing specifications and tools.

Runtime activation and state coordination of services that involve collaboration is not trivial. I'm not sure we're quite ready for this one yet - the IMS Tool Interoperability activity is an initial exploration of this area. Lets sit back and reflect on this one first!

I'd also argue that ISO is not the appropriate starting point for such work, but rather trialling in public with an active user and developer community would be more suitable; if the approach is proven to be workable and of broad interest, then submission to formal standardization could subsequently take place. There are a lot of people in the wider community (that is, not members of ISO committees) who could have a really good input to this.

Please don't invent the LOM of Chat :-(

All the best, Scott

update I just noticed Stephen Downes has already posted in a fairly similar vein.

I'd cast Stephen's example into Atom like this (assuming the proposed threading extensions get accepted as guidelines):

  <atom:title>My first Post</atom:title>
  <atom:content>This is my first post</atom:content>
  <atom:link rel="alternate" href=""/>
    <atom:name>Stephen Downes</atom:name>
  <atom:published>11 Jun 2005 11;15 ADT</atom:published>
  <thr:in-reply-to id="" href="" />
  <link rel="related" href=""/>

main archive