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).ScheduledSessionsScheduledSession feed be published alongside any SessionSeries feed that contains Schedules, and that this ScheduledSession feed also includes remainingAttendeeCapacity. If implementing the Open Booking API, such a complementary feed is required.ScheduledSessions 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.ScheduledSessions feed.ScheduledSession feed. For example: if a SessionSeries has a recurrence rule for a weekly event with an endDate in 2050, only the ScheduledSessions that have been booked at least once or have been manually edited would appear in the ScheduledSession feed.ScheduledSessions are included, the Schedule must also include an idTemplate, such as the below, which matches the pattern of the @id of the ScheduledSessions (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 Schedules, as they might have been rescheduled based on a previous @id.Schedule found in a feedSchedule together with complimentary ScheduledSessions, 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.ScheduledSessions found in a subEvent or ScheduledSession feed), using the explicitly defined occurrence in its entirety based on its @id.SessionSeries feed:ScheduledSession feed: