Tidbits and errata with binding.ws & binding.jms

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 >

-Eric.