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

Hey Ram,
  thanks for this.  In looking thru the spec I think one more spot was 
missed, the 4th paragraph under PutResponse. I think removing this would 
be consistent with the removal of the text we're removing under the other 
operations.  What do you think? 

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> 
Sent by: public-ws-resource-access-request@w3.org
04/08/2009 09:32 PM

To
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
cc
Doug Davis/Raleigh/IBM@IBMUS, 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-request@w3.org" 
<public-ws-resource-access-request@w3.org>
Subject
RE: [Bug 6730] Transfer: Redundant SOAP Processing Advice






> [NEW] ACTION: Ram to consolidate 6730 proposals for consideration next 
time [recorded in http://www.w3.org/2009/04/07-ws-ra-minutes.html#action01
]
 
Per AI from the previous meeting, please find attached the final proposal.
 
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[attachment "6730 - Amended proposal.doc" deleted by Doug 
Davis/Raleigh/IBM]