Implement a “standard” document ? Be strict when you write but forgiving when you read

A notorius document standard is iCal which describes a (text based) standard to exchange scheduling appointments. Every piece of scheduling software and loads of home grown applications support the iCal format. What an iCal document is supposed to look like is described in a RFC. The main problem with such a specification is that it is far too large and academic for the average developer to comprehend. As a result the many iCal appointments flying over the web have many differences. Also bigger applications are guilty, almost every version of Outlook produces iCal’s in a different format.

It’s not easy to make sure your iCal documents follow the standard. It would be nice if it was an xml-document, in that case you could validate it against a schema. My advice is to check not only the RFC but do Google around a lot. We did this in our iCal project. It is now deployed and we only have one problem with one specific version of mobile Outlook. Not bad.

When it comes to reading an iCal document I suggest your code to be forgiving. Take this example which happened to Scott. He had to convert the incoming document to lowercase by hand before his Mac iCal program would accept it. Is the casing in the RFC ? Perhaps. Did the code have to be that strict ? I don’t think so.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • pvanooijen

    Thanks ! I knew there had to be a human equivalent, so it even has a name.

  • Daniel Cadenas

    Indeed! this is Postel’s Law: “Be conservative in what you do; be liberal in which you
    accept from others.”

  • ScottBellware

    > Did the code have to be that strict ?

    Indeed! My experience made me reflect on how little people on different platforms might actually be exchanging these documents…