After a quick read of the standard, it is obvious that an iCalendar component can be represented as a primary object with the individual components represented as sub-classes.This lends itself to object oriented programming. Unfortunately, this project will be built in the reverse of the typical development order; create the programmatic interface and then use the database for persisting the data.
We can, however, take advantage of the apparent inheritable hierarchy of the standard in building the database schema. In a typical OOP project, a Calendar object would be created and then a sub-class, inheriting Calendar, would be created for each of the components with the properties for each defined. Because the iCalendar standard reuses many of the fields between components for similar uses, a single CalendarItem table can be created with another table defining the component for each entry.
The iCalendar object has four properties that apply to the calendar object level; Product ID, Version, Calendar Scale and Method. The product ID identifies the application that generates an iCalendar file and the Version tells the importing application which standards version to use. In the case of RFC 5545, the version is 2.0. Calendar Scale and Method are both optional. Calendar Scale defines the “scale” of the calendar. By default, this is GREGORIAN, but others may be defined in other or future RFCs. The Method is the transport method as defined in RFC 5546. I’m not sure if this should be persisted, so I’ll have a field in the database but it will be nullable.
The rest of the properties of the iCalendar object can be assigned to at least one of the six components. As stated in an earlier post, these components are Events, To dos, Journals, Free/Busy schedules, Alarms and Time Zones. Going forward, this blog will refer to the component in general as listed here and the specific objects will be prefixed by a “v”; as in vEvent, vToDo, vJournal, vFreeBusy, vAlarm and vTimeZone.
The vEvent object is a set of properties, possibly including those for a vAlarm, that defines a block of time when something is to happen. When thinking about calendars, this is the most common component type. Additionally, it cannot be nested within another component, but can be related to other vEvents, vToDos and vJournals.
vToDos are sets of properties, also possibly including those for a vAlarm, that defines a work item for an individual. Like the vEvents, vToDos cannot be nested within another component. It can, however, be related to other vToDos, vEvents and vJournals.
vJournals are sets of properties that defines one or more descriptive text notes associated with a particular calendar date. Because a vJournal had no time, it will not affect Free/Busy searches. Like the vEvents, vJournals cannot be nested within another component. It can, however, be related to other vJournals, vEvents and vToDos.
vFreeBusy are either a request for Free/Busy, a response to a request or a published Free/Busy schedule. Because of that, the data will not be persisted.
vAlarms are a set of properties that define a reminder for a vEvent or vToDo. There can be zero or more Alarms for an Event or a To Do. Because of that, a mechanism for associating the alarms with the parent component is built into the properties.
Note: Implementations should carefully consider whether they accept alarm components from untrusted sources, e.g., when importing calendar objects from external sources. One reasonable policy is to always ignore alarm components that the calendar user has not set herself, or at least ask for confirmation in such a case.
The final component is vTimeZone. It unambiguously defines the time rules for a specific geographic region. It is used by other components to define local times.
Note: The specification of a global time zone registry is not addressed by this document and is left for future study. However, implementers may find the TZ database a useful reference. It is an informal, public-domain collection of time zone information, which is currently being maintained by volunteer Internet participants, and is used in several operating systems. This database contains current and historical time zone information for a wide variety of locations around the globe; it provides a time zone identifier for every unique time zone rule set in actual use since 1970, with historical data going back to the introduction of standard time.