Schedule
is a representation of a recurrence rule, compatible with the iCalendar specification, designed to be extrapolated by the data user into individual occurrences.PartialSchedule
, by contrast, must not be extrapolated by the data user, and is for information only.Schedule
to a feedSchedule
must be included in the SessionSeries
feed for systems that display occurrences of a sessions directly from a recurrence rule (as opposed to first materialising them into a database).ScheduledSession
sScheduledSession
feed be published alongside any SessionSeries
feed that contains Schedule
s, and that this ScheduledSession
feed also includes remainingAttendeeCapacity
. If implementing the Open Booking API, such a complementary feed is required.ScheduledSession
s are included in a feed or subEvent
, they must not include all occurrences that are generated from the recurrence rule, and instead must only include those events that either:remainingAttendeeCapacity
< maximumAttendeeCapacity
)Schedule
.SessionSeries
.ScheduledSession
s feed.ScheduledSession
feed. For example: if a SessionSeries
has a recurrence rule for a weekly event with an endDate
in 2050, only the ScheduledSession
s that have been booked at least once or have been manually edited would appear in the ScheduledSession
feed.ScheduledSession
s are included, the Schedule
must also include an idTemplate
, such as the below, which matches the pattern of the @id
of the ScheduledSession
s (noting the startDate
placeholder must use a string format of YYYY-MM-DDThh:mm:ssZ
(e.g. 1997-07-16T19:20:00Z
):urlTemplate
may also be included in the Schedule
using the same startDate
placeholder.ScheduledSession
that was previously generated by a Schedule
is rescheduled to a different start time, its original @id
must be retained (which contains the original start time), to ensure that it still hides the same generated occurrence (see below), and to ensure that Change of Logistics Notifications are still triggered.Schedule
is updated, it must include exceptDates
for any overlaps with any explicitly defined occurrences created from previous Schedule
s, as they might have been rescheduled based on a previous @id
.Schedule
found in a feedSchedule
together with complimentary ScheduledSession
s, the data user must do the following:Schedule
in the future, taking into account the exceptDate
property.scheduledEventType
, property and use it for the @type
property of each occurrence.startDate
of the occurrences based on the contents of the Schedule
. DTSTART
must be determined by using the startDate
, startTime
, and scheduleTimezone
of the Schedule
together, for example:startDate
and startTime
of the Schedule
are in "local time" based on the scheduleTimezone
.duration
of the Schedule
to calculate the endDate
of each occurrence.startDate
and endDate
for each occurrence to UTC using a string format of YYYY-MM-DDThh:mm:ssZ
(e.g. 1997-07-16T19:20:00Z
) for placeholder replacement.idTemplate
property (if provided) and substitute the startDate
placeholder with the calculated string value of startDate
(and do the same with endDate
). Use the resulting string as the value of the @id
property for the occurrence.urlTemplate
property (if provided) and substitute the startDate
placeholder with the calculated string value of startDate
(and do the same with endDate
). Use the resulting string as the value of the url
property for the occurrence.Schedule
since the last time it was updated, store the generated occurrences as follows:modified
RPDE timestamp associated with the Schedule
. Ensure that any explicitly defined occurrences that may have been generated from a previous run of Step 3 (below) are not overwritten by this step.ScheduledSession
s found in a subEvent
or ScheduledSession
feed), using the explicitly defined occurrence in its entirety based on its @id
.SessionSeries
feed:ScheduledSession
feed: