[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: raw chat log of 2011-05-19 telcon
Simon Holdsworth: Participant Code: 7059536
USA Toll-Free 888-426-6840 begin_of_the_skype_highlighting
888-426-6840 end_of_the_skype_highlighting
USA Caller Paid 215-861-6239 begin_of_the_skype_highlighting
215-861-6239 end_of_the_skype_highlighting
UNITED KINGDOM Toll-Free 0800-368-0638 begin_of_the_skype_highlighting
0800-368-0638 end_of_the_skype_highlighting
UNITED KINGDOM Caller Paid 0-20-30596451 begin_of_the_skype_highlighting
0-20-30596451 end_of_the_skype_highlighting
Ireland Toll-Free 1-800-943-427
Ireland Caller Paid 0-1-5264424 begin_of_the_skype_highlighting
0-1-5264424 end_of_the_skype_highlighting
Bulgaria Toll-Free 00800-117-4514
Other access codes can be found at:
https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=7059536&accessNumber=02030596451
Simon Holdsworth: Agenda:
Simon Holdsworth: 1. Opening
Introductions
Scribe assignment
Top of the scribe list:
Plamen Pavlov SAP AG
David Booz IBM
Martin Chapman Oracle Corporation
Tom Rutt Fujitsu Limited
Anish Karmarkar Oracle Corporation
Ashok Malhotra Oracle Corporation
Bryan Aupperle IBM
Eric Johnson TIBCO Software Inc.
Agenda bashing
2a. Ratify resolution of issue BINDINGS-161
BINDINGS-161 "resolved with proposal in the minutes below"
Martin Chapman seconded the motion but did not have voting rights.
2b. Approval of the minutes from 12 May:
http://www.oasis-open.org/committees/download.php/42158/SCA%20Bindings%20minutes%202011-05-12.doc
3. Actions
20110310-03 [Editors] Make the change to the JMS spec doc + Testcases
doc described in
http://lists.oasis-open.org/archives/sca-bindings/201103/msg00007.html
4. New Issues
No new issues
5. Open Issues
http://www.osoa.org/jira/browse/BINDINGS-154
Clarify optionality of MAY statements in JMS binding spec
Status: Proposed resolution in JIRA
http://www.osoa.org/jira/browse/BINDINGS-156
Clarify optionality of SHOULD statement BJM30030
Status: Proposed resolution in JIRA
http://www.osoa.org/jira/browse/BINDINGS-158
Clarify optionality of SHOULD statement BJM60016
Status: Proposed resolution in JIRA
http://www.osoa.org/jira/browse/BINDINGS-153
write new tests for TA-20021 TA-20022 TA-20028 TA-20032TA-20034 TA-20035
TA-40007 TA-50008 TA-50009
Status: Proposed resolution in JIRA
http://www.osoa.org/jira/browse/BINDINGS-157
Clarify optionality of SHOULD statement BJM60009
Status: Alternative proposed resolutions in JIRA
http://www.osoa.org/jira/browse/BINDINGS-159
Clarify optionality of SHOULD statement BJM60001
Status: No proposed resolution, needs discussion
6. AOB
anonymous morphed into MartinC
Please change your name from 'anonymous' using the Settings button
anish: scribe: anish
anish: 5 of 7 VM present
anish: meeting is quorate
anish: Topic: Agenda bashing
anish: Agenda approved
anish: Topic: Ratify resolution of issue BINDINGS-161 from last week
(seconder was not a VM)
anish: Anish moves Mike seconds to ratify the resolution of issue 161
from last week
anish: motion passes w/o
MartinC will not attend to motion or 2nd again
anish: Topic: approval of minutes from 12 May
http://www.oasis-open.org/committees/download.php/42158/SCA%20Bindings%20minutes%202011-05-12.doc
anish: minutes approved
anish: topic: AI review
anish: 20110310-03 [Editors] Make the change to the JMS spec doc +
Testcases doc described in
http://lists.oasis-open.org/archives/sca-bindings/201103/msg00007.html
anish: PENDING
Mike Edwards lowered your hand
anish: topic: issue 154
anish: http://www.osoa.org/jira/browse/BINDINGS-154
Clarify optionality of MAY statements in JMS binding spec
Status: Proposed resolution in JIRA
anish: Four MAY statements in the JMS spec
anish: proposal is to replace all of these MAYs with non-normative stmts
anish: Simon explains the proposal for BJM30006
anish: SCA runtimes MAY allow other values of the @correlationScheme
attribute to indicate other correlation schemes [BJM30006].
Change the text to: "SCA runtimes supporting other correlation schemes
can allow additional values for the @correlationScheme attribute."
anish: Simon explains the proposal for BJM30028
anish: SCA runtimes MAY place restrictions on the properties of the
resource adapter Java bean that can be set using the resourceAdapter
element [BJM30028].
Change the text to: "The resource adapter and SCA runtime together
define the set of valid properties for configuring the resource adapter
via the JMS binding."
anish: Simon explains the proposal for BJM40007
anish: The SCA runtime MUST support the default JMS wire format and
operation selector behavior, and MAY provide additional means to
override it [BJM40001].
Remove the MAY clause from the statement. Add the following sentence at
the end of the paragraph currently ending on line 368: "The
operationSelector and wireFormat elements allow a binding element to
specify behaviour defined by the binding specification or custom
behaviour provided by an SCA runtime."
anish: Simon explains the proposal for BJM40007
anish: sent [BJM40007].
Change the text to: "The default wire format allows a choice of text or
bytes format when sending messages; an SCA runtime can restrict this to
one or other via additional configuration.
anish bad cut-and-paste
anish: When using the default wire format an SCA runtime MAY provide
additional configuration to allow selection between JMS text or bytes
messages to be sent [BJM40007].
Change the text to: "The default wire format allows a choice of text or
bytes format when sending messages; an SCA runtime can restrict this to
one or other via additional configuration.
anish: Since some conformance items are being removed in the proposal,
additional changes to the documents are required:
1) Remove BJM30006, BJM30028, BJM40007 from the table at the end of the
JMS binding spec.
2) Remove test assertions BJM-TA-30006, BJM-TA-30028, BJM-TA-40007 from
the JMS binding testcase specification, including entries in the tables
in Appendix B and C
3) Update test case description for BJM-TA-40001 to remove the MAY
clause, and remove the "D" from the testcase name (editorial).
anish: no comments on the proposal
anish: Mike moves Anish seconds to resolve issue 154 with the proposal
in JIRA
anish: no discussions
anish: no objections
anish: motion approved w/o
anish: Topic: issue 156
anish: http://www.osoa.org/jira/browse/BINDINGS-156
Clarify optionality of SHOULD statement BJM30030
Status: Proposed resolution in JIRA
anish: The SCA runtime SHOULD make the operationProperties element
corresponding to the selectedOperation available to the wireFormat
implementation [BJM30030].
anish: Proposal:
I don't see the value of having this as a normative statement as we have
no direct control over implementations. Delete this statement; add the
following text to continue the previous non-normative text on line 299:
"; an SCA runtime can pass these values to the wireFormat implementation
for each message received."
Additional changes to the documents are required:
1) Remove BJM30030 from the table at the end of the JMS binding spec.
2) Remove test assertions BJM-TA-30030 from the JMS binding testcase
specification, including entries in the tables in Appendix B and C
Description
From email:
http://lists.oasis-open.org/archives/sca-bindings/201104/msg00030.html
Description: The JMS binding specification includes statement BJM30030
with a SHOULD keyword: The SCA runtime SHOULD make the
operationProperties element corresponding to the selectedOperation
available to the wireFormat implementation [BJM30030]. We need to
clarify whether this is an optional part of the JMS binding spec.
Proposal: I don't see the value of having this as a normative statement
as we have no direct control over implementations. Delete this
statement; add the following text to continue the previous non-normative
text on line 299: "; an SCA runtime can pass these values to the
wireFormat implementation for each message received." Additional changes
to the documents are required: 1) Remove BJM30030 from the table at the
end of the JMS binding spec. 2) Remove test assertions BJM-TA-30030 from
the JMS binding testcase specification, including entries in the tables
in Appendix B and C
Show
anish: line 299, is the text that describes the operationProperty element
anish: Mike: can't assume that there is a specific wireFormat
implementation. Upto the implementation
anish: ... it talks about things that are mandated nowhere
Simon Holdsworth: Existing text:
Simon Holdsworth: " /binding.jms/operationProperties/property
specifies properties specific to this operation. These properties are
intended to be used to parameterize the wireFormat identified for the
binding for a particular operation.
Simon Holdsworth: (line 297-299)
anish: Mike: i would just remove the currently normative text as it is
completely bogus
anish: Simon: happy with that modification
anish: Mike moves Anish seconds to resolve issue 156 by removing the
statement BJM30030 from the body of the spec, removing BJM30030 from the
table at the end of the JMS binding spec, removing test assertions
BJM-TA-30030 from the JMS binding testcase specification, including
entries in the tables in Appendix B and C
anish: no discussion
anish: no objections
anish: motion approved w/o
anish: topic: issue 158
anish: http://www.osoa.org/jira/browse/BINDINGS-158
Clarify optionality of SHOULD statement BJM60016
Status: Proposed resolution in JIRA
anish: Proposal:
Strengthen the statement by removing the SHOULD as follows:
For an SCA service with a JMS binding, when a callback request message
is sent and no callback destination can be identified then the SCA
runtime MUST raise an error and throw an exception to the caller of the
callback operation [BJM60016]
anish: Mike moves Anish seconds to resolve issue 158 with proposal in JIRA
anish: no discussion
anish: no objections
anish: motion approved w/o
MartinC hello frank
anish: Anish suggested to skip 153 for today and move to the other JMS
issues
anish: Mike stated that the only acceptable resolution for 153 would be
some actual testcases
anish: Topic: issue 157
anish: http://www.osoa.org/jira/browse/BINDINGS-157
Clarify optionality of SHOULD statement BJM60009
Status: Alternative proposed resolutions in JIRA
anish: simon explains the issue and the proposal.
anish: Simon: the reason it is a should is that a runtime may have
alternate means to specify this
anish: simon: this needs to be strengthened
anish: ... possible make it that an error be raised when the message is
received
anish: anish: might want to say MUST NOT process the message rather than
MUST stop processing
anish: simon: we'll require a test case if we approve this
Mike Edwards: Mike Edwards moves to resolve Issue 157 by replacing the
text of BJM60009 with the following:
Mike Edwards: "For an SCA service with a JMS binding, when a request
message is received as part of a request/response MEP where the request
message includes a null JMSReplyTo destination and the JMS binding does
not include a response/destination then the SCA runtime MUST not process
the request and raise an error [BJM60009] "
anish: s/not/NOT/
anish: Mike moves Anish seconds to resolve issue 157 with the proposal above
anish: no discussion
anish: no objections
anish: motion approved w/o
anish: Anish: do we need another issue for the testcase
anish: ACTION: Simon to look into whether we need a testcase for the
uddated normative statement in BJM60009
anish: s/uddated/updated/
anish: topic: issue 159
anish: http://www.osoa.org/jira/browse/BINDINGS-159
Clarify optionality of SHOULD statement BJM60001
anish: simon explains the issue
anish: Eric: might be dealing with existing implementation and going
from SHOULD-> MUST seems to be the wrong direction
anish: anish: agree with eric
anish: Eric moves Mike seconds to resolve issue 159 by replacing
BJM60001 with 2nd paragraph of the proposal in JIRA
anish: The JMS specification provides the JMSReplyTo header as the way
for a JMS application to identify the destination on which replies or
other messages are to be placed that relate to the one being sent. For
one-way requests sent by SCA references with unidirectional interfaces,
the JMSReplyTo will not usually be set as no reply or other related
message is expected.
anish: no discussion
anish: no objection
anish: motion resolved w/o
anish: meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]