On 21/12/15 19:41, John MacAuley wrote:
Hans and I have been working through behaviours of the Modify
operation as the NSI CS document is a little vague on some of
the more detailed aspects of the operation. Our most recent
discussion focused on the modification of startTime. For
example, let us say reservation X has a startTime of "now + 1
hour", but I would like to modify the startTime to start "now".
In an initial reservation request we specify at startTime of
now by omitting the <startTime> element, however, for a
modify operation we cannot distinguish from a startTime not
specified for modification and the startTime intentionally
missing to indicate "now".
In the current schema definition we cannot use an empty
<startTime> element as it is an illegal xsd:dateTime. So
that only leaves us with the option of specifying a
<startTime> reasonably close to now, but well all now how
troublesome this is with our current implementations.
Exactly, that was the reason why we came up with the possibility to
leave startTime or endTime empty to specify 'start now' and 'last
forever' reservations. I don't look forward to implement all kind of
workarounds again.
There is a solution to this issue. If we modify the existing
schema to allow for the "nillable" option on startTime we can
now specify an empty <startTime xsi:nil="true" />
element to handle this "start time of now" case. This would
require a non-backwards compatible change for modify, but I am
not sure how may NSA implementations of modify exist.
It is not because I proposed this of course ;-), but I believe this
is the best solution to modify start or end time without having to
change the current semantics around startTime and endTime.
The second issue is what happens if in the modify request a
parameter with the same value is provided? Do we fail the
modify or continue with the same value? For example, if a
modify is received with the same startTime but a different
endTime do we reject to modify since it contains the same
startTime, or do we accept the modify and only change the
endTime?
I would assume we accept the modify operation an proceed with
modification of endTime. What happens if only one parameter,
say capacity, is specified and it contains the same value as the
current reservation version?
Seen from a practical perspective, you already have to keep track of
the current reservation details to implement idempotency, so it is
very easy to check if a value specified in a modify is different
from the current value, only question is what are you going to do
after that, are you going send back an error or are you just going
to accept it as a no-op.
Related to this, is it allowed to send a modify that does not change
any of parameters of the reservation? And will that then result in a
new reservation with a higher criteria version?
Cheers,
HansT.