Actually that rule says nothing about the results
being implementation specific what it says is the *interpretation* is what needs
to be done is implementation specific (which it is anyways) and the results are
very much specified. There is no statement there which says that results are
implementation specific.
rule 1.B: the WS-Resource implementation is free to interpret the
resource properties document contained in the Put request in any way it deems
necessary for the update to occur.
rule 1.B.I: if the resource properties document
maintaned by the WS-Resource after update is XML Infoset identical to the
resource properties document contained in the Put request, then response MUST
contain nothing.
rule 1.B.II: if the resource properties document
maintaned by the WS-Resource after update is not XML Infoset identical to the
resource properties document contained in the Put request, then response MUST
contain the updated resource properties document.
-- Igor
Sedukhin
..
()
-- (631)
342-4325
..
1 CA Plaza, Islandia, NY 11749
From: Steve Graham [mailto:]
Sent: Friday, January 07, 2005 4:38 PM
To: Sedukhin, Igor
S
Cc:
Subject: RE: [wsrf]
resolving issue 72: clarification of PutResourcePropertiesDocument operation
semantics
not everything is implementation
specific. I agree some things are, but we should not "just accept" that
certain results will be implementation specific. Side effects we can never
cope with, stating that the actual results of PutRP document are implementation
specific is not acceptable.
>I think we're fine.
-1
sgg
++++++++
Steve
Graham
(919)254-0615 (T/L 444)
STSM, IBM Software Group, Web services and
SOA
Member, IBM Academy of Technology
<Soli Deo
Gloria/>
++++++++
"Sedukhin, Igor S"
<>
01/07/2005 04:17 PM
To
Steve
Graham/Raleigh/IBM@IBMUS
cc
<>
Subject
RE: [wsrf] resolving
issue 72: clarification of PutResourcePropertiesDocument operation
semantics
It is always implementation specific. The client needs to
understand (or guess :) the semantics of the implementation anyways. There is no
such absolute knownledge that a temperature property is not settable and has
this or the other effect. It is always relative to the client's understanding of
what the implementation will actually do. However, what we provide is a MEP
which takes care of some of the basic aspects of this interation and makes that,
at least, interoeprable. I think we're fine.
-- Igor Sedukhin ..
()
--
(631) 342-4325 ..
1 CA Plaza, Islandia, NY
11749
From: Steve Graham [mailto:]
Sent: Friday, January 07, 2005 4:12 PM
To: Sedukhin, Igor
S
Cc:
Subject: RE: [wsrf]
resolving issue 72: clarification of PutResourcePropertiesDocument operation
semantics
yes, good example.
However, the semantics of SetRP on temperature are clear, client
expects the fault. From what I understood of your proposal, it is
implemntation specific what exactly happens to the temperature.
++++++++
Steve
Graham
(919)254-0615 (T/L 444)
STSM, IBM Software Group, Web services and
SOA
Member, IBM Academy of Technology
<Soli Deo
Gloria/>
++++++++
"Sedukhin, Igor S"
<>
01/07/2005 03:50 PM
To
Steve
Graham/Raleigh/IBM@IBMUS
cc
<>
Subject
RE: [wsrf] resolving
issue 72: clarification of PutResourcePropertiesDocument operation
semantics
Steve, like I said,
the same concern is true of any property update.
Say I have
<myCrazyThermometer>
<temperature>...</temperature>
<message>...</messaage> *
</myCrazyThermometer>
The client does
SetRP(<temperature>X</temperature>). My impl sends a fault, but also
records a message that someone tried to update the temperature. So that is the
side effect.
Now I got the RP doc which may be very surpising to the client. The
client may not have intended this effect of the SetRP operation, but will have
to live with it anyways.
<myCrazyThermometer>
<temperature>Y</temperature>
</message>Client A tried to
update! Bad client! Kill him!</message>
</myCrazyTehrmometer>
-- Igor Sedukhin ..
()
--
(631) 342-4325 ..
1 CA Plaza, Islandia, NY
11749
From: Steve Graham [mailto:]
Sent: Friday, January 07, 2005 3:39 PM
To: Sedukhin, Igor
S
Cc:
Subject: RE: [wsrf]
resolving issue 72: clarification of PutResourcePropertiesDocument operation
semantics
"Sedukhin, Igor
S" <> wrote on 01/07/2005 03:27:38 PM:
>
Steve,
>
> I don't think
it is as scary as you describe. First of all any MEP that changes
>
values may result in unitended behaviour in that when the fault occurs e.g. an
> exception in the implementation code, there is no "undo" and the state
of the
> resource properties document MAY be undetermined.
True, but
at least the behavior of the web service, independent of
implementation
issues is
known a priori. If I try to do a SetResourceProperties MEP on an RP
that
is read only, I know
it will fault, this is part of the definition. However,
from
what I read, if I do a
PutRPDoc including some Read-only properties, the provider may
make certain changes but not all, it may
update everything, including read-only properties
(as a surprise to all concerned) or it may update
some properties, not others, etc. etc.
My point is that with a MEP that does change state like this, we
cannot be so flexible
with
the semantics.
>
That aside, I believe that
> particular rule of this MEP is
interoperable:
>
A. it says that Put MUST contain an XML Schema valid RP doc, so the
client
> knows what to do
> B. unless a fault was returned, the client
unambiguously knows what happened at
> the WS-Resource end: the new
document is either exactly the same as the one
> submitted or different
in which case the new one is returned.
But the client may still be surprised
that certain values did change when the client
expected them to stay the same.
>
> I guess you refer to the case when a client
intends to update something, but it
> does not get updated or something
else that was not intended is updated (side
> effects). However, that is
true of any form of update.
>
> -- Igor Sedukhin .. ()
> -- (631)
342-4325 .. 1 CA Plaza, Islandia, NY 11749
>
>
> From: Steve Graham
[mailto:]
> Sent: Friday, January 07, 2005 8:32
AM
> To: Sedukhin, Igor S
> Cc:
>
Subject: Re: [wsrf] resolving issue 72: clarification of
>
PutResourcePropertiesDocument operation semantics
>
> Hi Igor:
> Thanks for clarifying your position on PutRP doc.
> My concerns
remain about the vagueness of the semantics of this, and hence my
>
continued concern about adding this MEP. In particular,
> >rule
1.B: the WS-Resource implementation is free to interpret the resource
>
properties document contained in the Put request in any way it deems necessary
for
> >the update to occur.
>
> The freedom for an
implementation to interpret the request in which ever way it
> seems best
strikes me as a HUGE interoperability threat. How is a requestor to
> figure out what the actual interpretation might be? Further,
given this is a MEP
> that potentially changes values in the WS-Resource,
we must treat this MEP
> carefully, it might be difficult or impossible
for the requestor to "undo" the
> results, if it later deems that the
implementation interpreted the request in a
> "surprising" way.
>
> sgg
> ++++++++
> Steve Graham
> (919)254-0615 (T/L
444)
> STSM, IBM Software Group, Web services and SOA
> Member, IBM
Academy of Technology
> <Soli Deo Gloria/>
> ++++++++
>
>
>
> "Sedukhin, Igor S" <>
> 01/06/2005 11:57 PM
>
> To
>
> <>
>
> cc
>
> Subject
>
> [wsrf] resolving issue 72: clarification of
PutResourcePropertiesDocument operationsemantics
>
>
>
>
> Responding
to my AI [(Igor) Put forward a proposal to resolve issue 72 - how this
>
would be done with respect to the semantics issues etc.]
>
> I suggest to define the following semantics for the
PutResourcePropertiesDocument
> operation. The words are precise, so may
not be easy to read. Let me know if this
> needs further clarifications
or not.
> rule 1: a resource properties document SHOULD be contained in
the Put request, in
> which case the WS-Resource implementation MUST
interpret the request as an update
> of the resource properties document.
> rule 1.A: the resource properties document contained in the Put request
MUST be XML
> Schema valid.
> rule 1.B: the WS-Resource
implementation is free to interpret the resource
> properties document
contained in the Put request in any way it deems necessary for
> the
update to occur.
> rule 1.B.I: if the resource properties document
maintaned by the WS-Resource after
> update is XML Infoset identical to
the resource properties document contained in
> the Put request, then
response MUST contain nothing.
> rule 1.B.II: if the resource properties
document maintaned by the WS-Resource after
> update is not XML Infoset
identical to the resource properties document contained
> in the Put
request, then response MUST contain the updated resource properties
document.
> rule 3: in
principle any document MAY be contained in the Put request, in which
>
case the WS-Resource implementation MAY find sufficient information in the
request
> to interpret it as an update of the resource properties
document. The response then
> MUST contain the updated resource properties
document. This behaviour is
> implementation specific.
> Note that rule 3 is covering the case
where the resource properties document
> submitted in Put request in not
XML Schema valid (e.g. a partial document with some
> required properties
omitted). The rule 1.B.I is covering the case where the
> document is
valid, but may fill the values that are assigned by the WS-Resource
>
implementation e.g. IDs, static values, default values, calculated values,
> transient values, etc. Either way it is up to the implementation to
interpret Put,
> however, I believe, it is sufficiently interoperable if
the client can count on
> these rules to be in effect.
> -- Igor
Sedukhin .. ()
> -- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11749
