Simon Holdsworth: Audio conference *UPDATED 10th Jan 2011*
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: 1. Opening
Introductions
Scribe assignment
Top of the scribe list:
Plamen Pavlov SAP AG
Laurent Domenech TIBCO Software Inc.
Ant Elder IBM
David Booz IBM
Martin Chapman Oracle Corporation
Tom Rutt Fujitsu Limited
Eric Johnson TIBCO Software Inc.
Ashok Malhotra Oracle Corporation
Anish Karmarkar Oracle Corporation
Bryan Aupperle IBM
Agenda bashing
2. Approval of the minutes from 24 February:
http://www.oasis-open.org/committees/download.php/41288/SCA%20Bindings%20minutes%202011-02-24.doc
3. Actions
20110203-2 [Simon Holdsworth] Check on reference update for new revision of IETF JMS URI spec, possible designated cross reference with TC Admin
4. New Issues
http://www.osoa.org/jira/browse/BINDINGS-145
Web Services Binding specification should require conformanceto the Web Services Binding TestCases
Raiser: Anish Karmarker
Status: Proposed resolution in JIRA
http://www.osoa.org/jira/browse/BINDINGS-146
WS Binding Testcases document has no conformance section
Raiser: Anish Karmarker
Status: Proposed resolution in JIRA
5. IETF JMS URI reference
Discuss recent email response from TC admin and proposed modification of the reference text.
6. Open Issues
http://www.osoa.org/jira/browse/BINDINGS-142
Missing links to test artifacts (WS)
Owner: Editors
Status: No proposed resolution
http://www.osoa.org/jira/browse/BINDINGS-143
Missing links to test artifacts (JMS)
Owner: Editors
Status: No proposed resolution
7. AOB
anish what? you mean they want to make money over solving world's technical problems 
Eric Johnson: Scribe: Eric
Eric Johnson: Attendance: 70%
Eric Johnson: Topic: Agenda bashing
Eric Johnson: (no changes)
Eric Johnson: Topic: Approval of minutes
Eric Johnson: No objections to approving the minutes from 2011-02-24
Eric Johnson: Topic: Action items
Eric Johnson: Re: 20110203-2
Eric Johnson: Simon: Designated cross-references are limited to OASIS.
Eric Johnson: 20110203-2 - completed.
Eric Johnson: Topic: New issues
Eric Johnson: Simon: Should we do these in the order listed
Eric Johnson: Anish: 146 less controversial
Eric Johnson: Subtopic: BINDINGS-146
Eric Johnson: Anish reviewing the issue.
Eric Johnson: Anish: Got feedback that under OASIS rules, spec documents require a conformance section
Eric Johnson: Anish: ... hence, open issue.
Eric Johnson: Anish moves to open BINDINGS-146, Mike 2nds.
Eric Johnson: No objections to unanimous consent, motion passes, issue opened.
anish: An implementation that claims to conform to this specification MUST be
able to run all applicable tests in Section 2 TestCases, producing the
Expected Output. As described in Section 1.1.2 Test Application the test
suite can be adapted to suit the requirements of a specific
implementation technology by replacing second-level composites,
replacing binding used to connect from the top-level composite to the
client application, replacing the contributions BWS_nnn_Java and
BWS_General_Java with appropriate implementation technology specific
contributions, and by changing the appropriate system or environment
variable.
Eric Johnson: Anish: I couldn't come up with a good conformance statement for test assertions. Very abstract thing.
Eric Johnson: Anish: Don't have a response for test assertions, just test cases. Test cases point to a runnable thing.
Eric Johnson: Anish: Tried to point out that the test suite itself is modular
Eric Johnson: Anish reads through the text...
Eric Johnson: Simon: I wasn't sure about the replacing of the bindings? Isn't it always the web service binding anyway.
Eric Johnson: Anish: If that's not true, then we need to change section 1.1.2.
Eric Johnson: Mike: There's no need to do that, you shouldn't need to do that.
Eric Johnson: Mike: You don't need to replace the bindings, but you do need to replace the implementation.
Eric Johnson: Simon: We have some test cases that use a JAX-WS binding as a way of accessing composites with a JMS binding, and that's an error - so we could use any other binding.
Eric Johnson: Simon: ... but then there are other cases where the web services bindings are what's being tested.
Eric Johnson: Simon: In JMS test cases, some of them use binding.ws in composites, which forces the composite to be accessed to generate an error.
Eric Johnson: Simon: Just using binding.ws because it is guaranteed to be available.
Eric Johnson: Mike: Trying to test the way an external JMS client as well.
Eric Johnson: Mike: Should just say that the bindings should be left alone. If the test cases contain a binding, then that binding must be supported.
Eric Johnson: Simon: Is there any reason to swap one binding with another.
Eric Johnson: Anish: There's an error on my part. Replacement of bindings in section 1.1.2 is present in POJO spec, but is not present in binding.ws doc.
Eric Johnson: Anish: ... We can delete the clause
anish: An implementation that claims to conform to this specification MUST be
able to run all applicable tests in Section 2 TestCases, producing the
Expected Output. As described in Section 1.1.2 Test Application the test
suite can be adapted to suit the requirements of a specific
implementation technology by replacing second-level composites, replacing the contributions BWS_nnn_Java and
BWS_General_Java with appropriate implementation technology specific
contributions, and by changing the appropriate system or environment
variable.
Eric Johnson: Eric: If you claim to pass the test cases, does this mean that you must pass the test suite, but yet that the main spec may or may not require passing the test suite.
Eric Johnson: Mike: Right. This gets us a conformance statement.
Eric Johnson: Simon: We might question the wording.
Eric Johnson: Mike: Yes, the direction looks fine.
Eric Johnson: Mike: Reasonably happy with the words there now.
Eric Johnson: Simon: What does "applicable" mean?
Mike Edwards: there are no testcases for optional function
Mike Edwards: if we ever invent testcases for optional function, then 2 responses must be acceptable: 1) "not implemented" 2) responds as expected
Eric Johnson: Anish: That's something we should debate. Reason I put that in is that the main spec has optional things. Callback protocol is optional. Had that in mind. Thought it would be useful to have language where so that they don't have to pass the optional parts.
Eric Johnson: Mike: I would remove applicable.
Eric Johnson: Simon: To conform to the test cases, you have to support the callback as well. Do we need two conformance statements to separate this out.
Eric Johnson: Anish: Language is a little bit loose. Options - get rid of "applicable" - then you have to run all tests. Keep applicable. Finally, keep applicable, and define precisely what it means - the optional items in the main spec.
Eric Johnson: Anish: Additional option - we could have different conformance targets. Minimum list of tests, plus an optional set. Could give it a name (callback client, callback server), then you can claim to conform to those optional targets.
Eric Johnson: Simon: Would prefer to be more explicit.
anish: 2) remove "applicable"
anish: 3) list all the tests for the mandatory bits in the main spec and only require those tests
anish: 4) create 2 targets X and Y. To claim X, you have to pass only the mandatory bits, to claim Y, you have to pass all the tests
Eric Johnson: Eric: I'd prefer if we followed the pattern set by the main spec. Which would be option #4
Eric Johnson: Anish: Any other preferences? Mike, do you have a preference?
Eric Johnson: Simon: I'm thinking more along the lines of #3. A set of test cases that you must pass. And then if you do the callbacks, then you have to support the reamaining targets
Eric Johnson: Mike: What Simon said sounds like a version of #4.
Eric Johnson: Mike: I prefer that path. Dividing them into sheep and goats, as it were.
Eric Johnson: Mike: What can we say about conformance to the test assertions document?
Mike Edwards: Test assertions conformance statement:
Mike Edwards: Each Testcase that claims to test an assertion defined in this document MUST test the artifact defined in the assertion,
with the declared pre-requisites and produce an output that reflects the declared predicate.
Eric Johnson: Mike: A little bit of work because of the word "reflects". This is because the test case might be testing a positive or a negative.
Simon Holdsworth: A possible update for 146: "An implementation that claims to conform to this specification MUST be able to run all tests in Section 2 Test Cases, subsections 1 and 2, producing the Expected Output. An implementation that also claims to conform to the SCA Web Services Callback Protocol MUST be able to run all tests in Section 2, Test Cases, subsection 3, producing the Expected Output".
Eric Johnson: Anish: Confused by this.
Eric Johnson: Mike: Any test cases that are written, match the assertions document.
Eric Johnson: Mike: Something like Simon's wording (in the chat) would be fine my me.
Eric Johnson: Mike: Want to check the details.
Eric Johnson: Simon: Need to go through every testcase just to be sure.
Eric Johnson: Simon: Anish, can you take an action, and produce a final version of the proposal?
Eric Johnson: ACTION: Anish to draft a final version of the proposal to resolve 146 for the test cases document.
Eric Johnson: Anish: Do we really need the test assertions document to be a spec?
Eric Johnson: Mike: Just a hassle for keeping as it is.
Eric Johnson: Mike: If someone wants to challenge the test cases document, they would be pointing back at the test assertions doc.
Eric Johnson: Simon: Happy to wait on the JCA binding test documents.
Eric Johnson: Anish: Are there optional parts for JMS
Eric Johnson: ACTION: Mike to come up with specific text for test assertions document.
anish eric, you have a cold?
Eric Johnson: ACTION (cont.) ... and Mike will open an issue indicating the need for conformance statement in test assertions.
Eric Johnson: Subtopic: BINDINGS-145
Eric Johnson: Anish: I realize this is late....
Eric Johnson: Anish: Perhaps we can add a non-normative link? Just want to establish some link between test cases?
anish: in we do that then s/Web Services Binding specification should require conformanceto the Web Services Binding TestCases/No linkage between the main spec and TC document/
Eric Johnson: Mike: Don't want mandatory requirements to pass test. Happy with Anish's direction for non-normative link.
Eric Johnson: Mike moves to open BINDINGS-145, changing its name to "There's no linkage between the web services binding spec and the test cases document."
Eric Johnson: Anish 2nds.
Eric Johnson: No objections, motion passes, issue is opened (and renamed).
Eric Johnson: Anish: Related works would put it on the cover page, but non-normative would give us some way to talk about it.
Eric Johnson: Anish: Related works would put it on the cover page, but non-normative would give us some way to talk about it.
Eric Johnson: ACTION: Anish to send a proposal to get us started on BINDINGS-145.
|