Summary
The current schedule model is too simplified, causing data loss when importing or exporting schedules.
Evidence
The schema keeps only dtstart, freq, interval, byday, and bymonthday while dropping broader RRULE semantics.
Impact
Technical: round-tripping between ORUK, iCal, and HSDS becomes lossy and requires custom transformation code.
Business: increases engineering cost, reduces interoperability, and undermines trust in service availability data.
Expected behaviour
ORUK should preserve schedule meaning end-to-end, without forcing data loss for standard recurrence cases.
Suggested resolution
Reintroduce the full RRULE model or define a lossless canonical schedule structure with explicit transformation rules.
Severity
Critical
Versioning note
These defects affect the core data model and likely require a breaking change (ORUK v4) to resolve fully. Backward compatibility may be maintained via transformation layers, but not within the current schema design.
Summary
The current schedule model is too simplified, causing data loss when importing or exporting schedules.
Evidence
The schema keeps only
dtstart,freq,interval,byday, andbymonthdaywhile dropping broader RRULE semantics.Impact
Technical: round-tripping between ORUK, iCal, and HSDS becomes lossy and requires custom transformation code.
Business: increases engineering cost, reduces interoperability, and undermines trust in service availability data.
Expected behaviour
ORUK should preserve schedule meaning end-to-end, without forcing data loss for standard recurrence cases.
Suggested resolution
Reintroduce the full RRULE model or define a lossless canonical schedule structure with explicit transformation rules.
Severity
Critical
Versioning note
These defects affect the core data model and likely require a breaking change (ORUK v4) to resolve fully. Backward compatibility may be maintained via transformation layers, but not within the current schema design.