See also: IRC log
<bob> folks to send in testimonials ASAP as in yesterday
<pauld> points the WG at the SOAP/core WSDL documents as a starting point: http://www.w3.org/2002/ws/addr/testsuite/documents/wsdl11/
<pauld> http://www.w3.org/2002/ws/addr/testsuite/documents/wsdl20/
<bob> tom: Will the test wsdl do all the way to the end services:
<pauld> they're escaped inside this document: http://www.w3.org/2002/ws/addr/testsuite/documents/
<pauld> http://www.w3.org/2002/ws/addr/testsuite/documents/#wsdl11/wsaTestService.wsdl
Bob: checking links sent by Paul
Paul: wsdl describe an exchange and there is an expectation of certain messages/behaviors to take place
<pauld> http://www.w3.org/2002/ws/addr/testsuite/documents/epr/epr3.xml
Jonathan: we can take out Paul's document and throw our markup - in WSDL require true and false flavors
Glen: Binding A/B/C have using addressing required/no or no marker
<pauld> we also have test cases 1107 and 1207 which exchanged refps containing WSDL documents: http://www.w3.org/2002/ws/addr/testsuite/testcases/#test1107
Jonathan: The WSDL we have implies addressing is required
Hugo: this is WSDL 2.0
Bob: (opens wsdl 1.1 document)
Jonathan: try to have the fewer # of WSDLs
(Philippe edits document)
Gil: remember that we don't want to modify a binding of the protocol test files, this needs to be a new binding
<gil> exactly
Jonathan: a test maps to one message exchange, i.e. one operation
Anish: need to use separate endpoints, since incompatible bindings cannot live on the same endpoint.
Philippe: we added UsingAddressing to the binding with wsdl:require=true; now we add a second one with required=false, adding a new port
Anish: should not actually provide the service since the address depends on each implementation - just leave a pattern
Philippe: next, we put addressing on the port
Anish: markup cannot be in both the binding and the port
... need 3 bindings - usingaddr required, usingaddr not required, and no usingaddr specified
Gil: can we import the binding used for the core tests?
Anish: better have self contained wsdl documents, importing gets complex
Jonathan: there are message artifacts defined, we need to check those
<pauld> avoiding import/include is worth going for - if necessary I suggest using XSLT/Perl to assemble test documents from parts
Jonathan: the overview document in the testcases folder may have the list of messages and tests
... the "message" links in each test point to the right messages
Anish: wsdl required=false needs two messages, w/ and w/o wsa headers
... we can use the same messages with the right modification in all cases
Bob: at this point it is clear that we need to pick someone to lead the testing activity, be the point of coordination as Paul and friends did before
... we should create a new tree, testsuitewsdl
... similar structure as with testcases
Jonathan: not everything is needed however
Bob: makes a testcases, documents subdirectories
... breaking now, back at 10:30
<bob> hi folks, lets restart
Bob: we have a first cut at a test WSDL into the documents directory
... how do we get to a more complete expansion of these test cases and parse the work out
... back to the features table from yesterday
... seems that the MEPs section in there needs to be expanded; each MEP will be as much work as some other features
... I would like to see someone volunteer to lead the test work; otherwise we'll do it in committee
... no one here
... I asked Paul, who did an excellent work last time. But it is unfair to ask him again
... we thank Paul once again
Gil: item #1 is to find the resource
Bob: it is actually to find out who will be participating in the testing from each company, then pick the primary lead from that set
... by next call, each company participating in the implementation will identify the person leading their implementation work
<pauld> agree with Glen that setting the bar to be 'provide a complete testcase' is a good goal, but that puts people off submitting testcases
Bob: even if we have people contributing prat of their time, we need someone to make sure the quality and completeness of the work is up to par
<pauld> I note the interop event drove the last round, more than my personal involvement, fwiw
<scribe> ACTION: companies participating in the testing identify their implementation leaders [recorded in http://www.w3.org/2006/05/04-ws-addr-minutes.html#action01]
Paul: in addition to the AI, we can construct a representative test to seed people's work
Jonathan: we need to be more organized that in other cases (XQuery) where different people submit test cases
Bob: let's set 5/15 to be the due date for the action item above
... we identified the end date of the CR period as 7/7
... can we have a date for the interop event?
Philippe: can we co locate with the WSDL meeting?
(discussion on possible locations)
Bob: possibility is MIT, the week of 7/10
... location is MIT, 18, 19 of July
<scribe> ACTION: Philippe to confirm availability of MIT location [recorded in http://www.w3.org/2006/05/04-ws-addr-minutes.html#action02]
Glen: let's dig deeper into one test
... WSDL has usingaddressing, client sends the wsa headers, server responds with wsa headers
... we can take the same we were editing
... binding has usingaddr with wsdlrequired=true
... question - do we have a canned server?
Paco: depends what are we testing, client, server or both
Glen: Both
Anish: server implementers publish their WSDL with specific endpoints
Glen: WSDl is generic except for endpoints
... test presence of WSA headers in request and response
Gil: next is the same testing for the negative case - client sends no headers, server sends back the right fault
Glen: requires a 'broken' client - send same message w/o wsa headers
Anish: message is not arbitrary, it is the same headers w/o wsa headers
... next (3) same as 1 with usingaddr on the port/endpoint
Bob: (4) is like 2 with usingaddr on port/endpoint
TonyR: (5) is as 1 with wsdlrequired=false; client sends wsa headers, server sends back wsa headers
Glen: headers sent back from server have mU=false
Gil: (6) is same. client includes no wsa headers, server returns valid response w/o mU=true wsa headers
Anish: in 5, server can send mU=true in response
... we need 7, 8 with flip sides of 5 and 6
TonyR: there is no flip side, server must obey contract
... (7), port indicates using addr with wsdlrequired=true
TonyR: (8) is as (7) with wsdlrequired=false
Bob: this gives us a first test pattern
... recessing till 1pm
... do we need WSDL test cases for all the MEPs in Section 5?
Glen: You can test solicit response and notification in WSA
<scribe> ACTION: Bob to flesh out MEPs into features table [recorded in http://www.w3.org/2006/05/04-ws-addr-minutes.html#action03]
Bob: we may discover gaps as we go over the MEPs, don't want to go back to WD
Anish: we can compose common MEPs to do the more sophisticated ones
Jonathan: there are several possible cases among the WSDL 2.0 MEPs
Bob: we'll see how out-only MEPs go - but I would like to make the argument that WSDL 1.1 is well understand once we finish the 1.1 tests, and say we are waiting for more 2.0 implementations
... take a 2 step approach, with a status statement at the end of the 1st one
Jonathan: can we mark some MEPs 'at risk'?
Hugo: no need to - it already says that MEPs are removed if not enough implementations are produced
Jonathan: then we should mark MEPs at risk in WSA as well
Hugo: we get rid of MEPs people don't implement
Bob: can we make this statement in the status portion of the document?
<scribe> ACTION: at the point of progression to CR, need to put words saying that MEPs at risk in the WSDL 2.0 document are also at risk in this document [recorded in http://www.w3.org/2006/05/04-ws-addr-minutes.html#action04]
Anish: is the SOAp response MEP a way to to out-only?
Glen: not the same, out is not a response
Paco: the SOAP MEP is like a client pulling a message, not a message push
Bob: question of Philippe regarding addressing 1.1. I am not for keeping WGs around w/o good justification
... is there value in extending to a future edition of WSA. Please all start considering that, put straw man concepts that we can discuss
... an extension to the charter could be the mechanisms to accommodate this requirements
Philippe: we ask this of all WGs at this stage. there is also the question of how to deal with errata
Jonathan; having a group to to errata for WS specs gets more interesting as more WGs close down
<pauld> suggests collapsing Addressing errata into XMLP
<pauld> WS-Core?
TonyR: let the dust settle before moving ahead
Bob: back to the test cases
... we should go over Action
Anish simple - just stick the right value, either default or not
Anish: test (9) WSDL specifies wsaw:Action in messages, client sends action and gets the right message
<rsalz> leave
Paco: we need different operations to test server side dispatching
Anish: let's take a wsdl with 2 request response operations, same input message body and different Action values, returning different response message body and actions
Bob: that is test 11
Anish: for test 10, client sends default Action, server expects non-default one, sends specified fault back
... test 12, same as 11, using default action values
Glen: do we need to test that defaulting works?
Jonathan: we should isolate the correct generation of correct default action values so an error in this does not make all other tests fail
Bob: test (13) no explicit action value in WSDL, client generates messages with correct action values
... in 13, server responds with default action as well
... 14 is negative of 13: client sends an action different from default, server faults
Hugo: are we testing Action returned by server?
Anish: yes, we do in all cases
Hugo: question is explicitly stating what form of action (explicit, default) is sent back by server. We need to clarify that the statements we make in the test case description applies to both client and server (default, non default)
Bob: coming to anonymous now
Anish: anonymous requires that usingAddressing is being used
Glen: we don't specify in the tests whether anonymous is being used or not
Anish: three values, required, optional, prohibited; not-specified implies no behavior
Jonathan: send the right or wrong value, get the right response
Bob: (15) is UsingAnonymous=required, client sends and anonymous replyTo, gets response on back-channel
Anish: 16 is the same, negative test, non anonymous reply and fault is sent back in back channel
... 17, 18 are same, adding the markup on the binding/operation element
... actually, we don;t need 15, 16, anonymous marker can only go on the operation
Bob: 17 says anonymous is prohibited; 18 is the negative of that
Anish: this is the weird one, where you send the fault back other than the back channel
TonyR: test needs to say the fault is sent to the ERP encoded on the faultTo EPR; assume non-anonymous faultTo
Tony: do we need a 19 for case when faultTo is anonymous?
Anish: no, behavior is unspecified
Paco: but it is the most common error
Anish: but is not specified in the spec
Paco: then we need to go beyond spec text?
TonyR: test says client must not receive response message in this case (faultTo is anon) - this is test 19
Paco: doing optional
Bob: 20, 21 will be like 17, 18 - anonymous marker is optional now, behavior in 20 is like in 17; in 21 server sends back response on back channel
Paco: we can test the case when anonymous is absent - client can assume optional behavior and server faults if it cannot support the EPRs selected
Anish: what is the value of doing that
Glen: right
TonyR: let's leave it at 21
Jonathan: let's put this in some XML format
Bob: I will stick it somewhere in the new tree
... keypoint is to identify the people doing the testing
Anish: Both MEPs and metadata are left to do
Bob: we are then done for the day
<pauld> thanks to Paco for some excellent scribing!