See also: IRC log
hair: Roland
<scribe> chair: Roland
<Roland> Scribe: mphilip
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)
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.[End of scribe.perl diagnostic output]