iCalendar Data Model
The iCalendar data format has a well defined data model. iCalendar “objects” encompass a set of iCalendar “components” each of which contains a set of iCalendar “properties” and possibly other sub-components. An iCalendar property consists of a name, a set of optional parameters (specified as “key=value” pairs) and a value.
iCalendar components include:
VCALENDARwhich encapsulates a set of other components to form a “calendar”
VEVENTwhich represents an event
VTODOwhich represents a task or to-do
VJOURNALwhich represents a journal entry
VFREEBUSYwhich represents periods of free or busy time information
VTIMEZONEwhich represents a timezone definition (timezone offset and daylight saving rules)
VALARMis a sub-component and is used to set alarms or reminders on events or tasks.
DAYLIGHTare sub-components used in
VTIMEZONEcomponents to represent standard and daylight time onsets and offsets.
DTSTARTwhich represents a start time for a component
DTENDwhich represents an end time for a component
SUMMARYwhich represents a title or summary for a component
RRULEwhich can specify rules for repeating events or tasks (for example, every day, every week on Tuesdays, etc)
ORGANIZERwhich represents the calendar user who is organizing an event or assigning a task
ATTENDEEwhich represents calendar users attending an event or assigned a task
In addition to this data model and the predefined properties, the specification defines how all those are used together to define the semantics of calendar objects and scheduling. The semantics are basically a set of rules stating how all the components and properties are used together to ensure that all iCalendar products can work together to achieve good interoperability. For example, a rule requires that all events must have one and only one
DTSTART property. The most important part of the iCalendar specification is the semantics of the calendaring model that it represents. The use of text, XML or JSON to encode those is secondary.
iCalendar was designed to be extensible, allowing for new components, properties and parameters to be defined as needed. A registry exists to maintain the list of standard extensions with references to their definitions to ensure anyone can use them and work well with others.
New components being worked on include