[Bug 6730] Transfer: Redundant SOAP Processing Advice

Hi Bob, Dave,

Thanks for allowing me time to comment on the proposed resolution!

I reviewed the proposal below from Dave. Overall looks good!

A few suggested changes to Dave's proposal:

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.

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.

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."

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."

I have attached a document that shows changes to Dave's proposal.

I have also attached another document that shows the consolidated proposal.

-----Original Message-----
From: public-ws-resource-access-notifications-request@w3.org [mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
Sent: Tuesday, March 31, 2009 1:21 PM
To: public-ws-resource-access-notifications@w3.org
Subject: [Bug 6730] Transfer: Redundant SOAP Processing Advice

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730





--- Comment #1 from David Snelling <david.Snelling@UK.Fujitsu.com>  2009-03-31 20:21:21 ---
In section 3.1 Remove:

"As per the SOAP processing model, other specifications may introduce various
types of extensions to the semantics of this message which are enabled through
headers tagged with s:mustUnderstand="true". Such extensions may define how
resource or subsets of it are to be retrieved or transformed prior to
retrieval. Specifications which define such extensions MUST allow processing
the basic Get request message without those extensions. 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.

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."

In section 3.2 Remove:

"As per the SOAP processing model, other specifications MAY introduce various
types of extensions to this message which are enabled through headers tagged
with s:mustUnderstand="true". Such extensions may require that a full or
partial update should be accomplished using symbolic, instruction-based, or
other methodologies.

Extension specifications MAY also define extensions to the original Put
request, enabled by OPTIONAL SOAP headers, which control the nature of the
response, as discussed in remarks on the PutResponse below.

Specifications which define any of these extensions MUST allow processing the
Put message without such extensions.

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."

In section 4.1 Remove: 

"Extension specifications MAY define extensions to the original Create request,
enabled by OPTIONAL header values, which specifically control the presence,
absence, or format of the initial representation or other child elements in the
CreateResponse. These headers MAY override the default behavior if they are
marked with s:mustUnderstand="true". In the absence of such OPTIONAL headers,
the behavior MUST be as described in the previous paragraphs. 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."


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.