ValidTo ??? → Both do not allow → Precedence: URL wins over body $from/$to wins over key values because client demonstrated knowledge of Temporal annotation wins over property because client demonstrated knowledge of Temporal and we don’t want Bad Requests POST PATCH PUT DELETE from and to Treated identical to Existing slices Same as PATCH, Existing slices specified (as PUT, only exception before/after setting unspecified key part or are key properties truncated properties to default truncated otherwise) values (normal PUT Existing fully Existing fully behavior) covered slices covered slices changed, optionally deleted/shadowed compacted Non-existing slices created Only from to defaults to start of to defaults to start to defaults to start of specified, only next time slice, or of next time slice, next time slice, or as key part max if no next time or max if no next max if no next time slice exists slice exists slice exists →assume client is unaware of Temporal Only from to defaults to max to defaults to max to defaults to max to defaults to max specified, not as key part → client is aware of Temporal Only to from defaults to of specified, only time slice as key part →assume client is unaware of Temporal Only to from defaults to min from defaults to min from defaults to min from defaults to min specified (as key part or otherwise) Neither Treated identical to from defaults to Same as PATCH, from defaults to specified PUT, only exception now, to defaults to setting unspecified now, to defaults to → not part of key are key properties properties to default max max values (normal PUT →assume Rationale: same as Rationale: change client is behavior) for PATCH is visible unaware of immediately Temporal afterwards and remains as
ValidTo → ??? Both → do not allow Precedence: URL wins over body $from/$to wins over key values because client demonstrated knowledge of Temporal annotation wins over property because client demonstrated knowledge of Temporal and we don’t want Bad Requests POST PATCH PUT DELETE from and to specified (as key part or otherwise) Treated identical to PUT, only exception are key properties Existing slices before/after truncated Existing fully covered slices changed, optionally compacted Non-existing slices created Same as PATCH, setting unspecified properties to default values (normal PUT behavior) Existing slices truncated Existing fully covered slices deleted/shadowed Only from specified, only as key part →assume client is unaware of Temporal to defaults to start of next time slice, or max if no next time slice exists to defaults to start of next time slice, or max if no next slice exists to defaults to start of next time slice, or max if no next time slice exists Only from specified, not as key part → client is aware of Temporal to defaults to max to defaults to max to defaults to max to defaults to max Only to specified, only as key part →assume client is unaware of Temporal from defaults to of time slice Only to specified (as key part or otherwise) from defaults to min from defaults to min from defaults to min from defaults to min Neither specified → not part of key →assume client is unaware of Temporal Treated identical to PUT, only exception are key properties from defaults to now, to defaults to max Rationale: change is visible immediately afterwards and remains as Same as PATCH, setting unspecified properties to default values (normal PUT behavior) from defaults to now, to defaults to max Rationale: same as for PATCH
odata-temporal-ext-v4.0-wd01-2017-11-15.docx