ISSUE-31: soapjms:isFault typing is ambiguous and its value is weakened because it is an optional property
soapjms:isFault typing is ambiguous and its value is weakened because it is an optional property
- State:
- CLOSED
- Product:
- SOAP-JMS Binding specification
- Raised by:
- Mark Phillips
- Opened on:
- 2010-03-02
- Description:
- There is a disparity between the text in 2.2.3 which talks about the value of soapjms:isFault being 0 or 1, and the example in 2.2.3.1 which shows it being set as a Boolean property.
Furthermore, presumably the main value of "isFault" is that it allows faults to be detected quickly without needing to parse the SOAP payload. However, because the property is optional, an implementation cannot rely on the property to detect faults (or non-fault responses). I suggest we make this mandatory - at least for faults. Should be added to the table in 2.6.2.3 (responding node)
Proposal:
In section 2.2.3, change:
[Definition: soapjms:isFault] (xsd:boolean)
* This property indicates whether a SOAP/JMS message is a fault. For senders, this property should be set to true when responding with a SOAP fault. When this property is true, the sending software SHOULD include a JMS property named SOAPJMS_isFault with a value of 1.
* For receivers, this property is derived from the JMS property named SOAPJMS_isFault — if present and containing a value of 1, the value of soapjms:isFault is true. If omitted, or present with a value of 0, the value of soapjms:isFault is false.
to:
* This property indicates whether a SOAP/JMS message is a fault. For senders, this property is set to true when responding with a SOAP fault. When this property is true, the sending software MUST include a JMS property named SOAPJMS_isFault with a value of true.
* For receivers, this property is derived from the JMS property named SOAPJMS_isFault — if present and containing a value of true, the value of soapjms:isFault is true. If omitted, or present with a value of false, the value of soapjms:isFault is false.
...this change would introduce a new assertion in the first bullet, which would require a test case.
In section 2.6.2.3, add a new row to the JMS Message properties section of the table
SOAPJMS_isFault - Set to true if the response is a SOAP fault
- Related Actions Items:
- No related actions
- Related emails:
- Agenda for the 2010-05-11 conference call (from eric@tibco.com on 2010-05-10)
- Action-161: update available (from phil_adams@us.ibm.com on 2010-05-05)
- Agenda for the 2010-05-04 conference call (from eric@tibco.com on 2010-05-03)
- Issue-30, Issue-31: update available (from phil_adams@us.ibm.com on 2010-04-26)
- Agenda for the 2010-04-13 conference call (from eric@tibco.com on 2010-04-26)
- Updated: Agenda for the 2010-04-13 conference call (from eric@tibco.com on 2010-04-12)
- Agenda for the 2010-04-13 conference call (from eric@tibco.com on 2010-04-12)
- Agenda for the 2010-04-06 conference call (from eric@tibco.com on 2010-04-05)
- Re: Agenda for 2010-03-30 conference call (from eric@tibco.com on 2010-03-29)
- Agenda for 2010-03-30 conference call (from eric@tibco.com on 2010-03-29)
- Updated proposal for ISSUE-31, my ACTION-156 (from eric@tibco.com on 2010-03-17)
- Re: Agenda for 2010-03-16 conference call (from eric@tibco.com on 2010-03-15)
- Agenda for 2010-03-16 conference call (from eric@tibco.com on 2010-03-15)
- Agenda for 2010-03-09 conference call (from eric@tibco.com on 2010-03-08)
- ISSUE-31: soapjms:isFault typing is ambiguous and its value is weakened because it is an optional property (from sysbot+tracker@w3.org on 2010-03-02)
Related notes:
Opened as per: http://www.w3.org/2010/03/02-soap-jms-minutes.html
Eric Johnson, 8 Mar 2010, 23:50:37Working group accepted the application of the resolution of this issue:
http://www.w3.org/2010/05/11-soap-jms-minutes.html
Display change log