Re: [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocumentoperation semantics

[Fred Carter <fred.carter@amberpoint.com>]

In general, if this is all a big deal, why not deal with it like pretty much all other computer instructions do:  have an option.

In Windows/Macintosh/whatever, if I copy a folder/directory over top of another, pop-op boxes may appear which say words to the effect "you've already got a file named foo, do ya wanna stop, overwrite this one, or overwrite them all."  Or if there are files that are readonly, not owned by me, munged beyond words, etc.  Similarly, at CLI land, if I remove things, I get "override permission XXX?" type questions left & right.

Why not just offer an option of front?  Default is to fault if somethings are not writeable by the sender (or by anyone), but allow an option to "silently ignore" such situations.  changeWhatYouCan=true or whatever. :-)  It might return some status "some junk changed", depending upon how silent one wished to be...

Suggestion offered.  No strong opinion one way or the other.  But it seems like a reasonable compromise...  Not without precedence in system services, certainly not in UI's.

/fred

Thus quoth Sedukhin, Igor S (~ 1/7/2005 1:17 PM ~)...

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 .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 

 

  _____  

From: Steve Graham [mailto:sggraham@us.ibm.com] 
Sent: Friday, January 07, 2005 4:12 PM
To: Sedukhin, Igor S
Cc: wsrf@lists.oasis-open.org
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" <Igor.Sedukhin@ca.com> 

01/07/2005 03:50 PM 

To
Steve Graham/Raleigh/IBM@IBMUS 
cc
<wsrf@lists.oasis-open.org> 
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 .. (igor.sedukhin@ca.com <mailto:igor.sedukhin@ca.com>
)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 




  _____  

From: Steve Graham [mailto:sggraham@us.ibm.com] 
Sent: Friday, January 07, 2005 3:39 PM
To: Sedukhin, Igor S
Cc: wsrf@lists.oasis-open.org
Subject: RE: [wsrf] resolving issue 72: clarification of
PutResourcePropertiesDocument operation semantics


"Sedukhin, Igor S" <Igor.Sedukhin@ca.com> 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 .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 
  

From: Steve Graham [mailto:sggraham@us.ibm.com] 
Sent: Friday, January 07, 2005 8:32 AM
To: Sedukhin, Igor S
Cc: wsrf@lists.oasis-open.org
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" <Igor.Sedukhin@ca.com> 
01/06/2005 11:57 PM 

To 

<wsrf@lists.oasis-open.org> 

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 .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 
    

-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301