On the implementation side, the database cannot possibly maintain one event record for every occurrence of the event, because there could be an unbounded number of occurrences. So it must maintain only one record for the event.  This means that we need a way to determine, given a recurring event and a time window,  whether an occurrence of that event falls within the window.  More generally, given a time window and a list of base events, we need to compute all occurrences of all the base events that fall within the window. The latter facility will, for example, enable us to compute all occurrences of a user's events on a given day or in a given week.

The event list expander is a data port that fills this need. Given an event list and a time window, it "expands" the list into a list of occurrences within that window. This data port behaves just like the database data port, with some restrictions. It can only handle one table, and that is the Event table whose structure is stipulated in the database schema of the site. It performs its actions by simply "forwarding" its invocation to the database data port and then doing the necessary post-processing for expanding the list of events that the database port provides.

The recurrence pattern maintains a start time and information about the periodicity of the recurrence. The recurrence may be for fixed times (e.g., every so many minutes), weekly (e.g., every Sunday and Wednesday), monthly or annual. A monthly recurrence can be either fixed (e.g., the third day of the month) or indexed (e.g., the second Sunday of the month). Similarly, an annual recurrence can be either fixed (e.g., the 15th of April) or indexed (e.g., the first Sunday of May). So the pattern's representation in XML contains tags that correspond to these quantities. Here are some examples that illustrate all the possibilities.