Re: ACTION 186 - top to bottom review of current copy of spec

In another follow-up, this email correlates the issue raised with the
item from the email I sent earlier.

This email does not reflect all issues to be filed, as I've gone a
little batty tracking all the details.  More issues to be filed.

-Eric.

On 07/12/2010 12:16 PM, Eric Johnson wrote:
> Issues to raise
> ===============
> 
> Abstract: Needs work.  Currently reads:
> "This document specifies how SOAP should bind to a messaging system that
> supports the Java Message Service (JMS) [Java Message Service]. Binding
> is specified for both SOAP 1.1 [SOAP 1.1] and SOAP 1.2 [SOAP 1.2
> Messaging Framework] using the SOAP 1.2 Protocol Binding Framework. " --
> uses RFC 2119 keyword, doesn't say anything about WSDL.

Filed as: http://www.w3.org/2002/ws/soapjms/tracker/issues/42

> 
> Section 2.2: paragraph #2: "If the specified property is present then it
> MUST be processed as specified." -- not flagged as an assertion. Also,
> possibly spurious, since each property has its own normative statements.
> 

Filed as: http://www.w3.org/2002/ws/soapjms/tracker/issues/43

> Section 2.2.1: jndiConnectionFactoryName, jndiInitialContextFactory,
> jndiURL, jndiContextParameter definition:
> "MAY be specified in JMS URI, WSDL, or somewhere else in the
> environment" --> This doesn't really work.  Seems like it should just
> read "Can be specified in the JMS URI, WSDL, ..."

Filed as: http://www.w3.org/2002/ws/soapjms/tracker/issues/44

> 
> Section 2.2.1: jndiContextParameter definition:
> Includes two "MAY"s and one "MUST", but none are flagged as assertions.
>  The "MAY" here seems spurious, and should be replaced with "can"

Filed as: http://www.w3.org/2002/ws/soapjms/tracker/issues/45

> 
> Section 2.2: soapjms:replyToName definition: "Specifies the name of the
> destination to which a response message SHOULD  be sent".  Not flagged
> as normative, and I suspect it ought to read "Specifies the name of the
> destination to which a response message will be sent."

Filed as: http://www.w3.org/2002/ws/soapjms/tracker/issues/46

> 
> Section 2.2.2: soapjms:topicReplyToName definition
> "name of the topic destination to which a response message SHOULD  be
> sent" --> Perhaps ought to read "name of the Topic destination to which
> a response message will be sent"
> "not relevant and MUST be ignored" --> This is not flagged as an
> assertion.  Also, "the replyToName is specified in the URI, WSDL, or
> environment, topicReplyToName is not relevant and MUST be ignored." -
> MUST is not bolded, and statement is not flagged as an assertion.
> 
> Section 2.4: Four "MUST" statements not flagged as normative assertions:
> First pair: "Based on the sending node's use of SOAP 1.1, SOAP 1.2, SOAP
> Messages with Attachments, and MTOM, the contentType  property MUST be
> set as it would be for SOAP/HTTP, and the message body MUST use the
> corresponding format. "
> 
> Second pair: "For example, if the SOAP payload is formatted as a simple
> SOAP envelope, the contentType  property value MUST be specified as
> "text/xml" for SOAP 1.1 or "application/soap+xml" for SOAP 1.2. On the
> other hand, if the SOAP payload is formatted as a MIME multipart
> message, the contentType  property value MUST be specified as
> "multipart/related". "
> 
> Section 2.4.1: Another MUST statement without an assertion: "Since the
> message is already in
> text format the "encoding" attribute in the XML header MUST be ignored."
> 
> Section 2.5:
> First: "An instance of a binding to JMS conforming to this binding
> specification MUST support the following message exchange patterns:†"
> 
> and shortly following: "In the case of SOAP 1.2 a conforming SOAP-JMS
> Binding instance MUST  support the following message exchange patterns:†"
> 
> These seem redundant.
> 
> Section 2.4, 2.6.1.1, 2.7.1:
> 
> Protocol 2027: "The contents of the JMS Message body MUST be the SOAP
> payload as a JMS BytesMessage or TextMessage. "
> 
> Protocol 2034: "(request-response MEP - requesting node) The message
> MUST  be created as a JMS BytesMessage or TextMessage as defined in 2.4
> The JMS Message Body."
> 
> Protocol 2040: The message MUST be created as a JMS BytesMessage or
> TextMessage  as defined in 2.4 The JMS Message Body.†
> 
> I conclude that normative statements 2034, 2040 are redundant with 2027.
> 
> Section 2.6.1.1:
> Description of JMSReplyTo has a "must" that should be replaced.
> 
> Section 2.6.1.3:
> "If a well formed response message is received a transition to "Success"
> is made."  Doesn't say what to do for the other cases ("transition to
> fail.").  Suggestion - change this to: "... a transition to "Success" is
> made, and otherwise transition to fail."
> 
> Section 2.6.2.3, table, description of JMSDeliveryMode.
> "this SHOULD be the same as that specified on the request" --> Not
> tagged as an assertion.
> 
> Section 2.7.2:
> There are three "MUST"s, two "SHOULD"s, and one "MAY" that are not
> tagged as normative statements.
> 
> Section 3.3.2: "the transport attribute MUST be set to the value
> http://www.w3.org/2010/soapjms/ . "  --> Not flagged as an assertion.
> 
> Section 3.3.5: Normative statement not flagged as such. (A MUST and a
> SHOULD.)
> 
> Appendix A:
> * Some of the references are non-normative, but are not listed as such.
> * References to some of the other W3C hosted specs are to the latest
> versions, rather than a specific draft.

Received on Monday, 12 July 2010 23:38:10 UTC