hair: Roland

<scribe> chair: Roland

<Roland> Scribe: mphilip

Testing

Yves: Soap-HTTP binding was tested by examining the messages that flowed. Suggest testing soap-jms by intercepting the JMS API.

<Yves> http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html

Peter has marked up both spec. XML documents with ed. notes to identify assertions.

<plh> example: <where/> <forall/> x, y : components @ <nl/> <t1/> Id(x) = Id(y) <implies/> x = y <also/> componentIds = {~x : components @ Id(x)~}

Looking for precedents for marking up assertions: the normative WSDL spec. used a markup style and WS-I took a similar approach

alewis: We should check for correctness of RFC2119 keywords in the spec.

peaston: There are approximately 50 assertions

<plh> http://dev.w3.org/cvsweb/2002/ws/desc/

alewis: Using markup for assertions helps to make the specification more effective

<Yves> databiding did build the spec from the example, using lots of XSLT, but that's too extreme for us.

<scribe> ACTION: peaston to Take a look at the way that WSDL assertions are marked up and to try and apply it to soap-jms spec. [recorded in http://www.w3.org/2008/06/03-soap-jms-minutes.html#action01]

<trackbot-ng> Created ACTION-8 - Take a look at the way that WSDL assertions are marked up and to try and apply it to soap-jms spec. [on Peter Easton - due 2008-06-10].

(Arthur was instrumental in formalizing the assertions in WSDL - and writing a non-normative version in Z notation)

Proposals on the approach to testing

Phil and alewis have each made a proposal

alewis: There are 2 profiles soap+wsdl and soap alone. for WSDL we simply need a validation tool. For SOAP, the proposal is to define a canonical XML schema for JMS messages - which will allow us to validate messages constructed by producers & consumers
... The tests would involve the implementation calling a message parser to check the correctness of messages.
... This proposal does not state how the test framework and test cases are structured

Phil: This approach focuses on driving each implementation using mocked up partner code - so a producer would be tested against a mocked up consumer and vice-versa
... Validation would be carried out using a similar schema based canonical representation of messages

Roland: There are two things to test - the specifications, and the conformance of implementations
... i.e. is the specification complete, correct, consistent, and can it be implemented?

alewis: (apart from "Z") there aren't tools to test the spec. but implementing it and developing test cases is a good way to tighten a spec.

Phil and alewis will continue to discuss their proposals and will aim for a single proposal - or to find some common ground - by next week

next meeting - same time next week

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: mphillip
Found Scribe: mphilip
Default Present: alewis, Roland, Peter, Derek, Phil, +1.408.667.aaaa, Bhakti, +0196287aabb, Yves, mphilip, +1.408.956.aacc, Plh
Present: alewis Roland Peter Derek Phil +1.408.667.aaaa Bhakti +0196287aabb Yves mphilip +1.408.956.aacc Plh
Regrets: Eric
Agenda: http://lists.w3.org/Archives/Public/public-soap-jms/2008Jun/0000.html
Got date from IRC log name: 03 Jun 2008
Guessing minutes URL: http://www.w3.org/2008/06/03-soap-jms-minutes.html
People with action items: peaston

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.