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.
_______________________________________________