There is an issue with Change of Logistics Notifications when used in combination with a Schedule.
With reference to the recommended processing approach, consider the scenario as follows:
- Explicitly defined occurrence is rescheduled, from 10/10/2020 10am to 10/10/2020 11am, and
@id is maintained as the value derived from 10/10/2020 10am
- Schedule changes to 11am, with
exceptDate of 10/10/2020 11am (to cover the previously rescheduled version)
- Then schedule adds a 10am recurrence to the existing schedule rule - the ID of the resulting occurrence for 10/10/2020 will overlap with the first ID?!
Initial thoughts on options to resolve this:
- A) When updating Schedules, the
@id of any generated sessions needs to be updated too, which means Change of Logistics Notifications do not apply to Schedules. However if the @id is updated, the Orders feed of the Open Booking API will not be able to resolve the old @id. Also requiring mutable IDs is bad practice.
- B) We use a
previousId field (similar to previousStartDate) to track the generated ID, if the schedule changes.
- C) Perhaps a more consistent version of (B): we use a
scheduleOccurrenceId to reference the generated schedule, instead of @id. This allows the use of unique IDs for each materialised occurrence (e.g. in the ScheduledSession feed), which still include a reference back to the generated occurrence. The issue with the approach is that generated occurrences will not have @id and therefore will not be bookable.
- D) We give the
Schedule a version ID from which occurrence IDs are derived (by embedding the schedule version ID in the idTemplate of the Schedule). If the Schedule is updated, the ScheduledSession feed must be used to update the startDate of any events that have moved (triggering Change of Logistics) while maintaining the existing @id that includes the previous schedule version. The new defined Schedule must include exceptDate to exclude any overlapping dates from the old Schedule, to ensure duplicate opportunities are not created.
Note: Any options that involve updating @id are at odds with JSON-LD principles and will break the Orders feed of the Open Booking API.
Option D is likely the cleanest, though it requires publishers to maintain a version of a Schedule and is quite prescriptive in the use of @id. It forces the @id of opportunities generated by each Schedule into a separate effective namespace, which is the most robust approach.
Another issue with D is that if a Schedule is extended (e.g. by an additional month), it would generate a large number of exceptDates in the new Schedule. More efficient to add a new Schedule to the eventSchedule array for the extension, but again this is a prescriptive solution. Alternatively, the new Schedule must have a startDate in the future.
Option D could be applied only to opportunities bookable through the Open Booking API.
The above also suggests that the ScheduledSession feed must materialise all ScheduledSessions that contain bookings into the ScheduledSessions feed, such that even when the Schedules are updated to cover dates in the future or different dates, those ScheduledSessions that relate to existing bookings can still accurately dereferenced from the Orders feed.
There is an issue with Change of Logistics Notifications when used in combination with a
Schedule.With reference to the recommended processing approach, consider the scenario as follows:
@idis maintained as the value derived from 10/10/2020 10amexceptDateof 10/10/2020 11am (to cover the previously rescheduled version)Initial thoughts on options to resolve this:
@idof any generated sessions needs to be updated too, which means Change of Logistics Notifications do not apply to Schedules. However if the@idis updated, the Orders feed of the Open Booking API will not be able to resolve the old@id. Also requiring mutable IDs is bad practice.previousIdfield (similar to previousStartDate) to track the generated ID, if the schedule changes.scheduleOccurrenceIdto reference the generated schedule, instead of@id. This allows the use of unique IDs for each materialised occurrence (e.g. in the ScheduledSession feed), which still include a reference back to the generated occurrence. The issue with the approach is that generated occurrences will not have@idand therefore will not be bookable.Schedulea version ID from which occurrence IDs are derived (by embedding the schedule version ID in theidTemplateof theSchedule). If theScheduleis updated, the ScheduledSession feed must be used to update thestartDateof any events that have moved (triggering Change of Logistics) while maintaining the existing@idthat includes the previous schedule version. The new defined Schedule must includeexceptDateto exclude any overlapping dates from the oldSchedule, to ensure duplicate opportunities are not created.Note: Any options that involve updating
@idare at odds with JSON-LD principles and will break the Orders feed of the Open Booking API.Option D is likely the cleanest, though it requires publishers to maintain a version of a
Scheduleand is quite prescriptive in the use of@id. It forces the@idof opportunities generated by each Schedule into a separate effective namespace, which is the most robust approach.Another issue with D is that if a
Scheduleis extended (e.g. by an additional month), it would generate a large number ofexceptDates in the new Schedule. More efficient to add a newScheduleto theeventSchedulearray for the extension, but again this is a prescriptive solution. Alternatively, the newSchedulemust have astartDatein the future.Option D could be applied only to opportunities bookable through the Open Booking API.
The above also suggests that the ScheduledSession feed must materialise all ScheduledSessions that contain bookings into the ScheduledSessions feed, such that even when the Schedules are updated to cover dates in the future or different dates, those ScheduledSessions that relate to existing bookings can still accurately dereferenced from the Orders feed.