OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

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