[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]