Disposition of Eric's binding spec review comments

[Simon Holdsworth <simon_holdsworth@uk.ibm.com>]

Here's my opinion on the disposition
of Eric's review comments.  I've moved the ones that I'm not sure
about to the top of the two lists.  These require some further email
discussion/clarification.

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. 
-> Need to analyse document
to determine all trademarks and abbreviations

p. 8, line 110 - Shouldn't the @uri
attribute take precedence if it exists?
p. 17, line 430 - use of include here
presumes the same namespace as SCA Assembly.
-> Not an editorial change
- no existing issue to cover these.

p. 6, line 55 - should include a table
showing implied prefix to namespace mappings. 
-> Not entirely sure what
is being asked for here, but not covered by existing issues.

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. 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. 12, line 273 - "WS-ReliableMessaging"
--> only reference in the document. Needs a reference in the normative
section. 
-> Covered by Issue BINDINGS-30
"Normative reference consistency"

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. 
-> Covered by issue BINDINGS-32
Document the attributes inherited from the base definition provided by
SCA Assembly specification. 

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. 17, line 416 - copyright wrong. 
p. 17, line 418 - namespace assumed
-- should be flagged as unknown. 
-> Fixed in WD-03 (12th
June 2008)

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

p. 3 - "[insert specific trademarked
names and abbreviations here]" 
-> Need to analyse document
to determine all trademarks and abbreviations

p. 5, line 38 - Should have a table
of prefix to namespace mappings used throughout the document. 
-> Not entirely sure what
is being asked for here, but not covered by existing issues.

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. 
-> Requires further discussion.

p. 12, line 255 - XML referenced here,
but not mentioned in normative references. 
-> Covered by Issue BINDINGS-30
"Normative reference consistency"

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 - 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? 
-> Covered by issue BINDINGS-31
What is a "plain name" for a connection factories or activation
specs, and how is one distinguished from a JNDI name? 

p. 8, line 68 - does not show the uri
attribute, even though it is documented on the next page. 
-> Covered by issue BINDINGS-32
Document the attributes inherited from the base definition provided by
SCA Assembly specification. 

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". 
-> Covered by issue BINDINGS-33
Correlation property names are odd, and the space of options is not extensible.


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 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?

-> Covered by issue BINDINGS-34
Clarify default function selection and data binding behavior.

p. 9, line 158-159 - This restriction
on the use of topics seems arbitrary and unnecessary. 
p. 12, line 310 - why "scaCallbackQueue"
--> this is assuming a particular implementation pattern. How about
"scaCallbackDestination" and "scaCallbackType"? Or
we should allow scaCallbackTopic. 
-> Covered by issue BINDINGS-35
Allow topics anywhere that queues can be used.

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. 6, line 41 - "port type"
--> "portType". 
p. 9, line 139 - Are these the only
valid values? This should probably read, "Values defined by this specification
include..." 
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. 19, line 557 - ">" in
quotes should be >
-> Fixed in WD-03 (19th
June 2008)

Regards, Simon

Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU