sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Disposition of Eric's binding spec review comments
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Thu, 19 Jun 2008 13:48:33 +0100
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]