iCalendar in UML


Introduction:

iCalendar is the Internet Calendaring and Scheduling Core Object specification. It is "normatively" defined in a document known as RFC 2445.

For a related development project, it was necessary to gain more understanding of the iCalendar spec. Unfortunately, iCalendar is quite complicated, so it was decided that I would diagram the iCalendar specification in UML.

The benefits of this documentation are many. The process of diagraming the spec. has given me much insight into the good, bad, and ugly aspects of iCal, and Internet Calendaring in general. The diagrams can be used as a reference guide for someone starting to develop an application using iCal. More importantly, however, the diagrams can be used as a minimum requirements document for developing new protocols to perform internet calendaring (such as one based on RDF).

Diagrams:

There are three diagrams, currently. The top-level diagram shows the different Components (such as Event, Alarm, etc.). The second-level diagram shows the Properties that make up the Components. Finally, the third-level diagram shows the Parameters that make up the Properties.


Methodology:

The goal was to produce a set of documents that could be used as a guide for implementing objects that represent a Calendar, and can be used to produce valid iCalendar data and also valid RDF-based calendar data. UML seemed a natural choice.

The first step was to model the property parameters, (also known as attributes). Each property parameter has an identifier and a data object. These are called name and value, respectively. value can be any of several different types (String, URI, CAL-ADDRESS, etc).

The second step was to model the properties. There are many different properties, and each has a different set of optional and required parameters. During this step, it was frequently necessary to modify the models for the parameters.

The next step was to model the iCalendar components (such as Events aka VEVENT). Having performed the previous two steps, this step was actually quite intuitive. During this step, it was necessary to modify the models for the properties.

Finally, it was necessary to relayout the pages, so they would fit better in a pdf file. Enjoy!


Michael Arick
Last modified: Tue May 29 00:04:14 PDT 2001