Tidbits and errata with binding.ws & binding.jms

[Eric Johnson <eric@tibco.com>]

In doing a review of the specifications, with the expectation that we would try to produce a committee draft of the specifications, we reviewed the current drafts.

The following is a relatively raw list of items that we found with the specs.  Most of these issues are not particularly substantive, however, some of them are.

For the binding.ws specification (wd-02):

p. 3 - "[insert specific trademarked names and abbreviations here]" should be removed, and the sentence reworded to match.

p. 5, line 30 - [rfc2119] reference syntax different from other references. All references ought to be written like this one.

p. 5, line 33 - reference to assembly spec should be to OASIS hosted one?

p. 6, line 45 - since SOAP 1.2 comes in two parts, the normative references should be to both parts? Also, this reference is to a specific version, whereas we don't reference specific versions for other specs, like WSDL. Should be consistent. Also a reference to an old SOAP 1.2 version.

p. 6, line 49 - this would be the second reference to WSDL 2.0.

p. 6, line 55 - should include a table showing implied prefix to namespace mappings.

p. 7, line 59 - should show the optional @uri, @name, and @requires attribute, as they are all used in this document.

p. 7, line 65 - should document @uri attribute, particularly with reference to section 2.1.

p. 8, line 110 - Shouldn't the @uri attribute take precedence if it exists?

p. 8, line 126 - "WS-I AP" --> "WS-I AttachmentsProfile", also need a "[3]" reference.

p. 8, line 127 - "MTOM" --> This is the only reference to this in the document. This needs a reference in the normative section.

p. 8, line 131 - "HTTP" --> Should formalize reference to HTTP (with version #).

p. 8, line 135 - "UDDI" --> This is the only reference to this in the document. Addition needed in normative reference section.

p. 8, line 137 - reference to section 2.3 --> section 4.

p. 9, line 155 - "does not curtail" --> "allows"

p. 10, line 172 - "This service must be conformant with the WS-I basic profile 1.1." --> (Improving the English) "This service must conform to WS-I Basic Profile 1.1." I don't think we intend this as an RFC 2119 statement, but for now, we're ignoring that.

p. 10, line 209 - Spurious "/>" on the end of this line.

p. 11, line 219 - "WS-I BP" --> "WS-I BasicProfile"

p. 11, line 221 - "port type" --> "portType"

p. 11, line 257, 258, 267 - "soap/1.2" --> "soap.1_2" (etc.)

p. 12, line 273 - "WS-ReliableMessaging" --> only reference in the document. Needs a reference in the normative section.

p. 17, line 416 - copyright wrong.

p. 17, line 418 - namespace assumed -- should be flagged as unknown.

p. 17, line 430 - use of include here presumes the same namespace as SCA Assembly.

---

Now for the binding.jms spec (wd-02):

p. 3 - "[insert specific trademarked names and abbreviations here]"

p. 5, line 21 - SCDL is not defined in this document or in the SCA assembly spec

p. 5, line 24 - "JMS artefacts" to refer to instances of JMS Java objects seems like an awkward fit.

p. 5, line 38 - Should have a table of prefix to namespace mappings used throughout the document.

p. 6, line 41 - "port type" --> "portType".

p. 8, line 68 - does not show the uri attribute, even though it is documented on the next page.

p. 9, line 139 - Are these the only valid values? This should probably read, "Values defined by this specification include..."

p. 9, line 140, 141 - "RequestMsgIDtoCorrelID" --> MessageID, and RequestCorrelIDToCorrelID --> "CorrelationID". Further "where the correlation ID of replies" --> "where the JMSCorrelationID property of reply messages"

p. 9, line 142 - Should the default be "None"? What does "None" mean? Seems to be a placeholder for "VendorDefined".

p. 9, line 158-159 - This restriction on the use of topics seems arbitrary and unnecessary.

p. 9, line 161 - if this is allowed to be either a plain name, or a JNDI name, how do you distinguish? We think this needs a separate @jndiName attribute which is mutually exclusive with @type and @name.

p. 10, line 169 - As far as JCA specs specifies the activation spec, it does not specifies the connnection factory but the destination. So the line "MUST NOT ..." does not apply here.

p. 10, line 169 - if this is allowed to be either a plain name, or a JNDI name, how do you distinguish? Is there any such thing as a "name" for a connection factory? If there is such a thing, what does the runtime do with it?

p. 10, line 173 - What is this notion of a "plain" name for an activation spec?

p. 10, line 202 - "JCA 1.5-compliant JMS provider" --> So far as we know, there is no standard for such a declaration. If there is, it should be referenced more precisely here.

p. 11, line 225 - 227 - "If such configuration is done... MUST generate an error" - awkward sentences.

p. 12, line 254 - there is no obvious way for a component to manufacture a JMSMessage object in order to return it. Should we even talk about a JMSMessage return?

p. 12, line 255 - should this be TextMessage. Also should we allow either TextMessage or BytesMessage?

p. 12, line 255 - XML referenced here, but not mentioned in normative references.

p. 12, line 258 - if we allowed "document wrapped" style, should we also support the ability to interpret the operation from the message body? Need a normative reference to "document literal wrapped" style. Can you have multiple parts to a WSDL message?

p. 12, line 310 - why "scaCallbackQueue" --> this is assuming a particular implementation pattern. How about "scaCallbackDestination" and "scaCallbackType"? Or we should allow scaCallbackTopic.

p. 19, line 557 - ">" in quotes should be &gt;

---

-Eric.