See also: IRC log
<Yves> trackbot, start telcon
<trackbot> Date: 24 June 2008
<Phil> Roland, FYI... I will miss the 7/8 call due to vacation
<Roland> Scribe: markphillips
<Yves> Scribe: Mark
<Yves> Scribenick: markphillips
<scribe> chair: Roland
<Roland> http://lists.w3.org/Archives/Public/public-soap-jms/2008Jun/0018.html
Amy sent the above testing summary to the list
- two approaches to test framework
- "opposite side" where we implement the sending or receiving partner of a message exchange
- or an SPI layer which intecepts requests and validates them
There is no agreement on this - other that to say that the way applications interact with JAX-WS is out of scope of the tests
Alternatively we could require that the vendors provide some way to dump the messages
There is more agreement on how messages are validated (with Relax-NG)
- this seems a useful place to start because all paths agree on this
<alewis> maybe we should build on this?
<alewis> http://www.w3.org/TR/2007/REC-soap12-testcollection-20070427/
The inputs into the test are the URI parameters, the WSDL parameters, and the Message content
<Yves> well, the easiest, the best, as the tests are here...
Mark: have we covered testing the message exchange patterns WRT sequence of messages ?
<alewis> yves: it tests assertions in soap. that won't necessarily test assertions in soap/jms. so we would at least be required to supplement the tests; we could take that set of tests as a starting point, or a foundation, perhaps.
Eric: One way is easy - the message arrives or not. For req-resp we have to write tests for both sides of the exchange.
<Yves> yes, I meant that it's already a base for parts of what we want to tests
Roland: We have to check that the correct JMS headers arrive.
Phil: Don't forget that the message is not necessarily just a SOAP envelope - may contain attachments
<Roland> http://lists.w3.org/Archives/Public/public-soap-jms/2008Jun/att-0015/00-part
Peter suggested a number of changes at the above message
Eric captured Peter's work and augmented it
<Roland> Section 1.1: Do we want to specify actual JMS calls? While we don't want to make the specific calls mandatory, we could require the equivalent.
Eric: We could define *a* way but
not *the* way - if we do this it should not be normative
... and we should do it using the API because there is no
standard model for processing below the JMS API
Section 2.2.2 and 2.2.3 would be the right place to put an example of how to use the API.
e.g. "message.setJMSDeliveryMode(DeliveryMode.PERSISTENT);"
Phil: This would involve a lot of duplication for the generic (string properties etc.) It would not be too bad for the JMS message header properties (like DeliveryMode above)
<scribe> ACTION: Phil to write a proposal of the text that should appear in each section of the spec. [recorded in http://www.w3.org/2008/06/24-soap-jms-minutes.html#action01]
<trackbot> Created ACTION-12 - Write a proposal of the text that should appear in each section of the spec. [on Phil Adams - due 2008-07-01].
Section 1.5: What do we really mean by "MUST fully support the JMS IRI [sic] scheme"? That is, should we should we spell out "support" in this context? (If I recall correctly, I take blame for the weak wording here - sorry.)
<Roland> now 1.6 http://dev.w3.org/cvsweb/~checkout~/2008/ws/soapjms/soapjms.html?content-type=text/html;%20charset=utf-8#introduction-conformance
Eric: We don't say what we mean. Does every "MUST" in the URI scheme equate to something which MUST be supported in the binding spec?
<scribe> ACTION: Eric to investigate and fix where necessary [recorded in http://www.w3.org/2008/06/24-soap-jms-minutes.html#action02]
<trackbot> Created ACTION-13 - Investigate abiguity about "MUST fully support the JMS IRI" and fix where necessary [on Eric Johnson - due 2008-07-01].
<Roland> Section 2.2.2: Do we mandate that property "replyToName" is only used for a two-way MEP?
Roland: in 2.6 it should say you MUST use it and in 2.7 it should say you MUST NOT use it
<scribe> ACTION: Roland to add text to say in sction 2.6 you MUST use replyToName and in 2.7 it should say you MUST NOT use it [recorded in http://www.w3.org/2008/06/24-soap-jms-minutes.html#action03]
<trackbot> Created ACTION-14 - Add text to say in sction 2.6 you MUST use replyToName and in 2.7 it should say you MUST NOT use it [on Roland Merrick - due 2008-07-01].
Phil: That will enforce it at runtime, but is it an error to use replyToName in the URI or WSDL for a one-way MEP?
Roland: Does anyone have any views on the value of a F2F to scope testing?
Eric: For testing it will be implementation focussed and that should be months away
Roland: Agreed - we would not do this before September
<Yves> roland, see http://www.w3.org/2008/10/TPAC/Overview.html
Roland: We should continue discussion on the spec updates via the mailing list
ACTION-13 = Investigate abiguity about "MUST fully support the JMS IRI" and fix where necessary
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) Succeeded: s/JAX-RPX/JAX-WS/ Succeeded: s/Investigate/Investigate abiguity about "MUST fully support the JMS IRI"/ Found Scribe: markphillips Found Scribe: Mark Found ScribeNick: markphillips Scribes: markphillips, Mark Default Present: +0138687aaaa, Yves, Roland, Phil, Eric, +1.919.742.aabb, +0196270aacc, alewis, markphillips, Bhakti Present: +0138687aaaa Yves Roland Phil Eric +1.919.742.aabb +0196270aacc alewis markphillips Bhakti Regrets: Peter Agenda: http://lists.w3.org/Archives/Public/public-soap-jms/2008Jun/0024.html Found Date: 24 Jun 2008 Guessing minutes URL: http://www.w3.org/2008/06/24-soap-jms-minutes.html People with action items: eric phil roland[End of scribe.perl diagnostic output]