Re: [Bug 6730] Transfer: Redundant SOAP Processing Advice

Thanks Doug, I agree with your analysis. I withdraw my prior comment.

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, April 07, 2009 5:31 AM
To: public-ws-resource-access@w3.org
Subject: RE: [Bug 6730] Transfer: Redundant SOAP Processing Advice


I always figured it would depend on the sender of the message to decide that - in this case the service.  If a service accepts an extension on the request there may or may not be any semantic difference (or extension element) on the response. And since the extensibility section of each spec already mentions that mU headers should be used to ensure that the receiver understands extensions [1], and this is stated w/o regard to the message being a request or response, I would think we should already be covered.  no?

[1] Senders MAY indicate the presence of an extension that has to be understood through the use of a corresponding SOAP Header with a soap:mustUnderstand attribute with the value "1".

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>

04/06/2009 11:31 PM

To

Doug Davis/Raleigh/IBM@IBMUS

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>

Subject

RE: [Bug 6730] Transfer: Redundant SOAP Processing Advice







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