W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > April 2009

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

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.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:17:54 GMT