- From: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- Date: Tue, 26 Jan 2010 16:13:23 +0000
- To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <503546C5699C1144BDEA0D0DFFE7F881184C2676@TK5EX14MBXC119.redmond.corp.microsoft.>
Agree that PutResponse and CreateResponse need some clarity, particularly, about when the response may not contain a representation. I like to suggest the following change: Ø [Body]/wst:CreateResponse As an optimization and as a service to the requestor, the wst:CreateResponse this element of the response message SHOULD be empty other than the ResourceCreated element, if there are no extension elements, and if the created representation does not logically differ from the representation sent in the Create request message or if the creation instructions in the Create request message were successfully executed; that is, if the service accepted the new representation or creation instructions verbatim or successfully executed the creation instructions. Such a response indicates that the request was completely successful (assuming no intervening mutating operations are performed). A service MAY return the current representation of the resource as the second child of the wst:CreateResponse element even in this case. Ø [Body]/wst:PutResponse This REQUIRED element, if it contains any child elements, MUST have as its first child element, an element that comprises the representation of the resource that has been updated. As an optimization and as a service to the requester, this element SHOULD be empty, if there are no extension elements, and if the updated representation does not differ from the representation sent in the Put request message or if the instructions in the PutResponse message were successfully executed; that is, if the service accepted the new representation verbatim or successfully executed the instructions. Such a response (an empty wst:PutResponse) implies that the update request was successful in its entirety (assuming no intervening mutating operations are performed). A service MAY return the current representation of the resource as the child of the wst:PutResponse element even in this case. -----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: Friday, November 13, 2009 7:30 PM To: public-ws-resource-access-notifications@w3.org Subject: [Bug 8302] New: descriptions of PutResponse and CreateResponse contain unclear sections http://www.w3.org/Bugs/Public/show_bug.cgi?id=8302 Summary: descriptions of PutResponse and CreateResponse contain unclear sections Product: WS-Resource Access Version: PR Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Transfer AssignedTo: public-ws-resource-access-notifications@w3.org ReportedBy: gilbert.pilz@oracle.com QAContact: public-ws-resource-access-notifications@w3.org The description of PutResponse contains the following paragraph: "Such a response (an empty wst:PutResponse) implies that the update request was successful in its entirety (assuming no intervening mutating operations are performed). A service MAY return the current representation of the resource as the child of the wst:PutResponse element even in this case, however." The description of CreateResponse contains the following paragraph: "As an optimization and as a service to the requestor, the wst:CreateResponse element of the response message SHOULD be empty, other than the ResourceCreated element, if the created representation does not logically differ from the representation sent in the Create request message and there are no extension elements; that is, if the service accepted the new representation or creation instructions verbatim. Such a response indicates that the request was completely successful (assuming no intervening mutating operations are performed). A service MAY return the current representation of the resource as the second child of the wst:CreateResponse element even in this case, however." You can sort of get the gist of what both of these paragraphs are trying to say but it's not completely clear. General Proposal: reword for clarity -- 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. You are the assignee for the bug.
Received on Tuesday, 26 January 2010 16:13:59 UTC