Eric,
Thanks for that detailed review.
There
is a combination of editorial updates and issues that need to be
discussed;
my impression is that we have the following issues that should be
opened,
the rest could be dealt with by the editors:
- (ws) Fix references in the WS
binding
spec (may be some discussion around syntax, targets)
- (all) Should bindings specs
show and
document the @uri, @name and @requires attributes from the base binding
element?
- (jms) Should correlation
property values
be renamed to be consistent with the JMS properties? (p. 9, line 140,
141
- "RequestMsgIDtoCorrelID" --> MessageID, and
RequestCorrelIDToCorrelID
--> "CorrelationID") and clarify meaning of "None"
- (jms) Clarify the use of
"plain
names" for connection factories, activation specs
- (jms) Clarify default function
selection/data
binding behaviour
- (jms) Should we remove the
restriction
on request/response operations in an interface when used with a Topic
destination?
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
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.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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