Re: [wsrf] resolving issue 72: clarification ofPutResourcePropertiesDocument 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 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 ..
()

-- (631)
342-4325 ..
1 CA Plaza, Islandia, NY
11749