See also: IRC log
<trackbot> Date: 24 May 2011
<scribe> scribe: Dug
<scribe> scribenick: Dug
RESOLUTION: new issue
... Issue 12722 proposal approved
any desire to do it?
Dug to ping Katy to see if she wants to finish up MEX
No other folks seem to have any interest
Bob: went to CR
... formal objection was raised an a topic
... raiser stands by formal objection but doesn't want to hold up the work
... after discussion it was suggested that we figure out how to test the possible issue raised in the FO
... charter requirement includes WS-I compliance
... between WS-I requirements and WSA there might be dup of info
... requirement might be to cover a transient phase between non-wsa and wsa support
... allows for either dispatch mechanism
... how would we go about testing it?
Ram: what is the director looking
... spec says what wsa and wrapper should be. if receiver detects a diff from spec then it should fault.
... its a corner case
... we (msft) can live with the decision of the WG. Not interested in negative testing.
Bob: specs don't say "all impls must
detect all incorrect syntax"
... lots of other places where this can happen
... some impls will do xsd checking - not required by specs
Dave: if a client didn't match the spec (either wsa or wrapper is wrong) what should happen? Fault or do what you think is right?
Dave: do any existing impls exhibit
weird behavior ?
... we could create a test that looks for this but do we have any impls that could generate this bad situation?
Dug: IMO its out of scope for us to say what should happen when a non-compliant impl sends bad stuff
Bob: we don't specify what fault
might be generated
... we would have the build something weird to make this happen
Dave: a possible test would be to generate a bogus wrapper in the Body that mis-matches the action
Bob: why is this syntax check any
diff from any other syntax error?
... do diff other than the FO was raised.
... Ram,would you like to either put together a test for it or withdraw the FO?
Ram: we can decide that this issue isn't big enough to do the additional testing
Bob: a statement from msft to that effect would be helpful
Ram: msft doesn't see a strong need to do additional testing for these corner cases
Bob: would you construct an email stating that?
Ram: yes i'll send it
Concluded pair-wise testing for all but mex
Dug: Li did you test ws-eventing with IBM?
Status is from f2f
Bob: no change to eventing so f2f eventing testing is fine
soap-assertions, evn are not tested
we need to say that "presence in metadata is sufficient"
Dug: how/where do we say this?
Bob: in scenario doc (show where it
goes), and in the test results we send up the chain
... in test results doc
... current position - write-up results for all but mex
... some other groups are interested in seeing these progress. EVD, Enum and Eventing
Dug: I'd prefer to wait if Oracle is close
Bob: has pinged Oracle but no firm response yet
Li: what is the length of the PR phase?
Bob: min 4 weeks
Li: so no new changes unless there's a bug
Bob: namespace will be locked down at PR phase
Li: ok to wait
<Yves> we need to have interop report _before_ going to PR
Bob: Gil, any ETA on mex?
Gil: not yet - working on eventing
Bob: eventing is covered already
... don't have a pair of impls of mex
Gil: so mex first and eventing later?
Gil: might be able to do by first week of June 10th
Bob: folks ok to wait ~10 days?
... Dug/Gil please work on testing mex
... formatting of testing report, any volunteers ?
... I'll do it
... mini-matrix per spec
... casual looker will not follow what we currently have
... assuming current 'success' will stay.
... need something in scenario doc for evd and sa
... Dug - please add something to scenario doc.
<scribe> ACTION: Dug to add text in scenario doc w.r.t. sa and evd [recorded in http://www.w3.org/2011/05/24-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-182 - Add text in scenario doc w.r.t. sa and evd [on Doug Davis - due 2011-05-31].
Bob: next meeting?
... June 14th?
Bob: Gil please let us know if you finish early or if you need more time
<Ram> Regarding the discussion about the need for additional / negative testing for the issue relating to the formal objection: While the possibility of encountering this interoperation problem in the real world exists (particularly when implementations choose to do dispatch using first child element), I think it is not serious enough at this time to have to do any additional / negative testing to check for this case.
Bob: please put that in an email to
the public list
... add that it would require the construction of special clients and/or services
... to force them to misbehave
Ram: will do