RE: [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocument operation semantics

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

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

 

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 operation semantics

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