[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocument operation semantics
Fred, I think this compromise is fine. I can go with that,
even though I don't really see much reson to complicate things this much.
It's a simple Put... :) If someeone sends me a letter I may
store it, may interpret it and reply, or may burn it in the chimney. Who
cares... If one expects me to do something I don't want to do, get a lawyer...
:)
-- Igor
Sedukhin
..
(igor.sedukhin@ca.com) From: Fred Carter [mailto:fred.carter@amberpoint.com] Sent: Friday, January 07, 2005 4:34 PM To: Sedukhin, Igor S Cc: Steve Graham; wsrf@lists.oasis-open.org Subject: Re: [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocument operation semantics 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 MEPthat changesvalues may result in unitended behaviour in that when the fault occurse.g. anexception in the implementation code, there is no "undo" and the stateof theresource 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, sothe clientknows what to do B. unless a fault was returned, the client unambiguously knowswhat happened atthe WS-Resource end: the new document is either exactly the same asthe onesubmitted 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 updatesomething, but itdoes not get updated or something else that was not intended isupdated (sideeffects). 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 semanticsHi Igor: Thanks for clarifying your position on PutRP doc. My concerns remain about the vagueness of the semantics of this, andhence mycontinued concern about adding this MEP. In particular,rule 1.B: the WS-Resource implementation is free to interpret theresourceproperties document contained in the Put request in any way it deemsnecessary forthe update to occur.The freedom for an implementation to interpret the request in whichever way itseems best strikes me as a HUGE interoperability threat. How is arequestor tofigure out what the actual interpretation might be? Further, giventhis is a MEPthat potentially changes values in the WS-Resource, we must treat thisMEPcarefully, it might be difficult or impossible for the requestor to"undo" theresults, if it later deems that the implementation interpreted therequest 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 ofPutResourcePropertiesDocument operationsemanticsResponding to my AI [(Igor) Put forward a proposal to resolve issue 72- how thiswould be done with respect to the semantics issues etc.] I suggest to define the following semantics for thePutResourcePropertiesDocumentoperation. The words are precise, so may not be easy to read. Let meknow if thisneeds further clarifications or not. rule 1: a resource properties document SHOULD be contained in the Putrequest, inwhich case the WS-Resource implementation MUST interpret the requestas an updateof the resource properties document. rule 1.A: the resource properties document contained in the Putrequest MUST be XMLSchema valid. rule 1.B: the WS-Resource implementation is free to interpret theresourceproperties document contained in the Put request in any way it deemsnecessary forthe update to occur. rule 1.B.I: if the resource properties document maintaned by theWS-Resource afterupdate is XML Infoset identical to the resource properties documentcontained inthe Put request, then response MUST contain nothing. rule 1.B.II: if the resource properties document maintaned by theWS-Resource afterupdate is not XML Infoset identical to the resource propertiesdocument containedin the Put request, then response MUST contain the updated resourceproperties document.rule 3: in principle any document MAY be contained in the Put request,in whichcase the WS-Resource implementation MAY find sufficient information inthe requestto interpret it as an update of the resource properties document. Theresponse thenMUST contain the updated resource properties document. This behaviourisimplementation specific. Note that rule 3 is covering the case where the resource propertiesdocumentsubmitted in Put request in not XML Schema valid (e.g. a partialdocument with somerequired properties omitted). The rule 1.B.I is covering the casewhere thedocument is valid, but may fill the values that are assigned by theWS-Resourceimplementation e.g. IDs, static values, default values, calculatedvalues,transient values, etc. Either way it is up to the implementation tointerpret Put,however, I believe, it is sufficiently interoperable if the client cancount onthese 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]