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