ISSUE-9: clarification on proposed re-wording of assertions

In my previous email re: ISSUE-9, I was not very specific about the 
precise changes I am proposing.   Here is a list of the detailed changes 
(listed in the order they are found in the document):

1) For assertion 2071, section 2.2.1, change:
"[Definition: Use fault subcode unsupportedLookupVariant if the JMS URI 
specifies a lookupVariant that is not supported by the implementation.†]
to be:
[Definition: A fault MUST be generated with subcode 
unsupportedLookupVariant if the JMS URI specifies a lookupVariant that is 
not supported by the implementation.†] 

2) For assertion 2011, section 2.2.3, change:
"[Definition: Fault subcode unrecognizedBindingVersion MUST be generated 
if the value of the soapjms:bindingVersion property does not match the 
fixed value.†]"
to be:
"[Definition: A fault MUST be generated with subcode 
unrecognizedBindingVersion if the value of the soapjms:bindingVersion 
property does not match the fixed value.†] 

3) For assertion 2025, section 2.2.4, change:
"[Definition: Use fault subcode malformedRequestURI when the URI violates 
the expected syntax.† ]"
to be:
"[Definition: A fault MUST be generated with subcode malformedRequestURI 
when the URI violates the expected syntax.† ]"

4) For assertion 2026, section 2.2.6, change:
"[Definition: Use fault subcode targetServiceNotAllowedInRequestURI when 
targetService parameter is included in the requestURI).†]"
to be:
"[Definition: A fault MUST be generated with subcode 
targetServiceNotAllowedInRequestURI when the targetService parameter is 
included in the requestURI).†] 

5) For assertion 2028, section 2.4, change:
"[Definition: Use fault subcode unsupportedJMSMessageFormat when the 
arriving message format is not BytesMessage or TextMessage. †]."
to be:
"[Definition: A fault MUST be generated with subcode 
unsupportedJMSMessageFormat when the arriving message format is not 
BytesMessage or TextMessage. †]"

Certainly, these changes are minor, but I think it is valuable to have 
consistency in the wording of specific statements that fall within the 
same general class of statements related to generating faults, etc.    One 
thing I've noticed in other specs is that when similar statements are 
worded differently, there is a potential for reading too much into the 
wording differences.   By using identical (or nearly so) wording, we can 
make things crystal clear to the reader (hopefully).

Regards,
Phil 
__________________________________________________________________________________________________________ 

Phil Adams (phil_adams@us.ibm.com)

WebSphere Application Server
Office: (512) 286-5041 (t/l 363)
Web Services Development
Cell: (512) 750-6599
IBM - Austin, TX