- From: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- Date: Mon, 6 Apr 2009 20:31:24 -0700
- To: Doug Davis <dug@us.ibm.com>
- CC: Bob Freund <bob.freund@hitachisoftware.com>, "david.Snelling@UK.Fujitsu.com" <david.Snelling@UK.Fujitsu.com>, "member-ws-resource-access@w3.org" <member-ws-resource-access@w3.org>, "member-ws-resource-access-request@w3.org" <member-ws-resource-access-request@w3.org>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>
- Message-ID: <79ABF5D0F6E88B4BA1F0885575759B214D230CD7CB@NA-EXMSG-C104.redmond.corp.microsoft>
One another point. I noticed this sentence [1] in the latest draft of the specification http://www.w3.org/2002/ws/ra/edcopies/wst.html. Should we add this statement to the section http://www.w3.org/2002/ws/ra/edcopies/wst.html#extensions? [1] "Since the response may not be sent to the original sender, extension specifications should consider adding a corresponding SOAP header value in the response to signal to the receiver that the extension is being used." From: Ram Jeyaraman Sent: Monday, April 06, 2009 4:23 PM To: 'Doug Davis' Cc: Bob Freund; david.Snelling@UK.Fujitsu.com; member-ws-resource-access@w3.org; member-ws-resource-access-request@w3.org; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org Subject: RE: [Bug 6730] Transfer: Redundant SOAP Processing Advice Thanks Doug, Your suggested changes look good to me! From: Doug Davis [mailto:dug@us.ibm.com] Sent: Sunday, April 05, 2009 6:34 PM To: Ram Jeyaraman Cc: Bob Freund; david.Snelling@UK.Fujitsu.com; member-ws-resource-access@w3.org; member-ws-resource-access-request@w3.org; public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org Subject: Re: [Bug 6730] Transfer: Redundant SOAP Processing Advice Ram wrote: ... > 1. Section 3.1 > > The sentence > > "Implementations may respond with a fault message using the standard > fault codes > defined in WS-Addressing (e.g., wsa:ActionNotSupported). Other > components of the outline above are not further constrained by this > specification." > > should not be removed. Why? This really doesn't say anything other than "Hey, you may fault for some reason". Isn't this true of all message in all WS-* specs? Why does this need it? > 2. Section 3.2 > > The sentence > > "In addition to the standard fault codes defined in WS-Addressing, > implementations MAY use the fault code wst:InvalidRepresentation if > the presented representation is invalid for the target resource. See > 5 Faults. Other components of the outline above are not further > constrained by this > specification." > > should not be removed. I agree that the part about InvalidRepresentation probably should remain but I think the WSA part can be dropped since, like above, that just normal stuff. So, how about just: Implementations MAY use the fault code wst:InvalidRepresentation if the presented representation is invalid for the target resource. See 5 Faults. Other components of the outline above are not further constrained by this specification. > In addition to Dave's proposal plus the suggested changes above, I > suggest the following: > > 1. A few paragraphs in section 3.3 (Delete) need to be removed: > > "Extension specifications MAY define extensions to the Delete > request, enabled by OPTIONAL header values, which > specifically control preconditions for the Delete to succeed and > which may control the nature or format of the response. Since the > response may not be sent to the original sender, extension > specifications should consider > adding a corresponding SOAP header value in the response to signal > to the receiver that the extension is being > used." > > "Specifications which define extensions for use in the original > Delete request which control the format of the > response MUST allow processing the Delete message without such extensions." +1 > 2. A few paragraphs in section 4.1 (Create) need to be removed: > > "Extensions specifications MAY also define extensions to the > original Create request, enabled by OPTIONAL SOAP > headers, which constrain the nature of the response, as discussed in > remarks on the CreateResponse below.Similarly, > they may require headers which control the interpretation of the > wst:Create as part of the resource creation > process." > > "Such specifications MUST also allow processing the Create message > without such extensions." > +1 -Doug
Received on Tuesday, 7 April 2009 03:32:12 UTC