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

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

David,

[the new RP Doc replaced the old one or fault, would be preferable if a lot less useful. This would at leaset parallel the WS-Transfer put]

Not exactly parallel. Accordng to WS-Transfer,

[A service MUST return the current representation of the resource as the initial child of the s:Body element if the updated representation differs from the representation sent in the Put request message.]

Which means that the new RP doc MAY not be a 100% replacement. The service MAY interpret Put the way it needs to. Moreover,

[A resource MAY accept updates that provide
different XML representations than that returned by the resource; in such a case, the semantics of the update operation is defined by the resource.]

Then, [1) I'm still missing a really compelling use case for replacing the whole RP Doc in one go.]

Something like a customer record. If my client maintains/can serialize an XML document of a customer record and there is an endpoint which represents it, why would I have to disassemble it into pieces? Even more so if I can retrieve the whole record in the nice schema-validaed package from that very endpoint. On the Web, you do GET and receive a document, then you may do PUT of the document with changes. That seems natural. Why would you have to update that document paragraph-by-paragraph?

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 


-----Original Message-----
From: David Snelling [mailto:David.Snelling@UK.Fujitsu.com] 
Sent: Friday, January 07, 2005 6:09 PM
To: Sedukhin, Igor S
Cc: wsrf@lists.oasis-open.org
Subject: Re: [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocument operation semantics

Folks,

I'm with Steve on this. I know how nice it would be to have symmetry with get and put for the whole document, but I don't think it is worth the complexity. Reasons:

1) I'm still missing a really compelling use case for replacing the whole RP Doc in one go.

2) The semantics provided by Igor make it clear to me that this is not a simple operation. A simpler semantic, e.g. the new RP Doc replaced the old one or fault, would be preferable if a lot less useful. This would at leaset parallel the WS-Transfer put for a WS-Resource that had a 100% writable RP Doc. Incidentally, I believe that a PutRPDoc operation is only meaningful in the first place if the whole document is writable.

3) I would put a big -1 to parameterizing the operation. Igor's semantics are already too complex for my liking. Let's not parameterize them as well.

4) I can't think of another one, but it probably has to do with Lawyers.

Talk to you all on Monday.


On 7 Jan 2005, at 5:57, Sedukhin, Igor S wrote:

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

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE

     +44-208-606-4649 (Office)
     +44-208-606-4539 (Fax)
     +44-7768-807526  (Mobile)