See also: IRC log
<scribe> Scribe: alewis
<scribe> agenda: meeting minutes for 5 June 2006. minutes accepted without objection.
open action items include call for additional participants in testing effort.
call for additional participants; no response.
primary purpose of meeting: discuss WSDL tests so far, work done by Arun and David.
Arun: review of WSDL test work so far.
URL posted just above summarizes and describes work to date, including the test design, tests themselves, and results so far, including the face to face
Arun: expected to have fifteen to
twenty test cases, but in fact have more. IBM and Sun have
implementations of all test cases.
... each test case has a number, which includes target WSDL version, target SOAP version, and a sequence number. tests try to cover a variety of cases; there are short descriptions of each.
... each test should be associated with an assertion; each test is either required or optional (right now, only one is optional).
... report page includes a todo list at the top.
... describes format of table in list, results for IBM-IBM, IBM-SUN, SUN-SUN.
... discussion of action-based dispatch, tests related to that, questions arising around it.
... trouble correlating messages in some cases.
... where four white boxes appear, there are questions about the spec.
... testing raises some questions about the interactions of various properties; the behavior of the processor is not always well-defined for all cases of all combinations of properties.
David: concurs with summary.
Bob: call for questions on
... issue from testing. related to SOAP Action.
... issue raised on mailing list, Jonathan may have raised about a week earlier.
... issue #26: unclear soap action.
Arun: concurs, this summarizes issue very well.
David: have some other stuff that need to discuss; this is not what David has had problems with.
Arun: David's issue with
action-related dispatch and [scribe lost remainder]
... proposed resolution of unspecified soap action header, something on empty string.
Anish: soap action "" actually is
specified. wsa:action is required to be an absolute URI; soap
action is not.
... consequently, at least in the case when soap:action is specified as "", it can't be used for wsa:action.
... Arun's suggestion would solve both problems.
Arun: if wsa:action is specified, use that. If soap:action is present and is not an empty string, use that. if that doesn't exist, construct the default.
Bob: is this a new issue?
Anish: specification doesn't
handle the case in which a soap:action is specified, but is not
... spec says that wsa:action and soap:action must match, but also say that wsa:action must be an absolute URI (which is not required for soap:action, even excluding the empty string case).
Arun: three issues: existing
cr26, the case Anish seems to be raising, and [??]
... what is meant by specified soap:action? empty string could be considered to be "specified", but should not be included.
David: if soap:action is empty string, then use the default pattern. need to clarify text to match this expectation.
Bob: opening new issue, cr28, to deal with Arun's issue and the proposed resolution from the email referenced above.
Paul: support resolution.
Bob: call for specific text. Arun: will post. Bob: fine, let's get exact proposed replacement text.
<agupta> From section: http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#explicitaction
Arun: will post existing text and proposed revised text.
<agupta> Current text: In the absence of a wsaw:Action attribute on a WSDL input element where a SOAPAction value is specified,
<agupta> Proposed text: In the absence of a wsaw:Action attribute on a WSDL input element where a *non empty* SOAPAction value is specified,
Bob: call for objections to accepting the proposal as resolution of cr28.
RESOLUTION: text proposed by Arun closes CR28.
addition of "non-empty" before "SOAPAction value" in 4.4.1.
Bob: David's issue. Arun: need to open Anish's issue. Bob: Anish said he will raise that issue. back to David.
David: this is clarification of
the general understanding.
... there are tests which expect that if a WSDL does not describe a wsaw:action, then an ActionNotSupportedFault is returned.
... however, the specification does not support ActionNotSupportedFault as a requirement, in David's reading.
... Arun read this differently, that the fault is required.
... spec language is pretty clear in SOAP binding; action not supported is optional. therefore it seems that it should be optional in the tests as well; Arun felt that it ought to be required.
Bob: call for objections to making tests optional. none heard.
RESOLUTION: tests in which ActionNotSupportedFault is returned are to be made optional, per David's recommendation.
<bob> Section 4.4.1 defines a mechanism to explicitly set the action value
<bob> (wsaw:Action). It says "In the absence of a wsaw:Action attribute" use
<bob> the specified SOAP action.
<bob> Section 4.4.2 defines a defaulting mechanism. It says "In the absence
<bob> of a wsaw:Action attribute" calculate the action using the algorithm
<bob> which follows.
<bob> The use of the same text ("In the absence...") for each of these
<bob> mechanisms renders it unclear whether the default action pattern or the
<bob> specified SOAP action is to take precedence. I think the intention is
<bob> clear - use wsaw:Action if present, else use specified SOAP action if
<bob> present, otherwise use the default pattern.
<bob> There appear to be a number of straightforward editorial remedies.
Bob: paste from Jonathan's
... call for agreement to proposal.
Bob: mark as editorial?
paul knight: non-empty is covered?
Tony: covered in closure of earlier cr.
Bob: call for objections.
RESOLUTION: close cr26, adopting the proposal of Jonathan Marsh as offered, subject to editorial interpretation and inclusion of "non-empty".
Arun: need to deal with question of action-based dispatch, as raised by David.
Bob: if hasn't been raised in email, then hasn't got visibility.
Arun: okay, will raise the issue.
question asked: is the problem with addressing or with the WS-I BP?
Arun: yes, this is a potential
interaction between WS Addressing and WS-I; wants to get a
sense of how to resolve.
... but the critical part of the question is: for this test case, what is the requirement/assertion that is being tested, using action-based dispatch?
Bob: interpreted this as an understanding that there are some otherwise valid WSDL that are not accepted by the WS-I BP.
Arun: will raise to list and record as issue.
Bob: propose next meeting in two weeks.
14 August. Arun, however, proposes earlier meeting. Bob: if raised to list, will be in one week, 7 August. call for objections.
Next meeting: 7 August 2006, same bat time, same bat channel.