W3C

- DRAFT -

SOAP-JMS Binding Working Group Teleconference

26 Aug 2008

Agenda

See also: IRC log

Attendees

Present
Regrets
Chair
eric
Scribe
alewis

Contents


 

 

<trackbot> Date: 26 August 2008

<peaston> redialling now

<eric> scribe: alewis

<Phil> Yay Amy :)

outstanding actions

eric; action 19 is still open, awaiting Roland or Mark

eric: action 21 completed; eric responded to email
... action 22: derek has just sent an email to the list
... action 23 still open, awaiting mark

phil: information sent to the mailing list on action 24. still in progress on structure of test cases, modeled on ws-addressing test cases.
... need some input from others on issues which he has raised (see emails on the list)
... have defined basic structure, and format of messages. other things (message exchange patterns, etc.) are referred to from the test case, not yet defined in phil's proposal.

eric: is this action complete?

phil: yes, substantially complete, if others are in agreement; remainder can make a separate action.

RESOLUTION: action 24 closed by phil's proposals sent to the mailing list

eric: action 25 still open, on phil (wording changes that may be needed for support of TextMessage)

phil: can have proposal by next week. asks if discussion can be added to this week's agenda.

eric: agree, if there is time.

Phil's test case message examples

phil: look at testcases.xml in testcases directory (zip file attached to message sent to list)

<eric> Link to test cases ZIP: http://lists.w3.org/Archives/Public/public-soap-jms/2008Aug/att-0029/soapjms_testcases.zip

phil: disclaimer: not expert in xslt, basing this on ws-addressing; main file is testcases.xml; can trace the structure from there.
... each test case in its own file, which then points at messages and features and such.
... run this through xslt transform, produces html documents with linkages that point at the extensions (particularly with reference to extensions/features defined in soap/jms specification).
... then message exhanges appear. ws-addressing has nice pictorial representation, which could also be developed; the message exchange element points at the mep definition document.
... each message exchange points at the messages, which are defined in separate xml files.
... each file is simply a soap/jms message.
... then each message element contains assertions specifying the state of various things.

eric: this is on receipt?

phil: this can't necessarily be used to drive a compliance tester, but at least this allows someone to look at things at an arbitrary point and compare it to the stuff defined in the test case.

eric: how compare message id equivalence?

phil: for this one, since it's one way, message id and correlation id are probably not relevant

eric: we wouldn't define this, since the engine generates the message id, would we?

phil: switch to two-way exchange. first message a->b, request. we *do* care what message id is. not necessarily that it's a specific value, but the correlation id in the reply message *must* be equivalent to message id of request message.

eric: we might need some way to specify some other parameters. for instance, message id.
... things like delivery mode, expiration, etc. may be controlled

phil: yes, that's why those aren't in brackets

eric: should we be able to specify the uri used for this message? to say delivery mode is specific value.

phil: oops. forgot to include endpoint url.
... need to specify extra element to indicate which endpoint url was used to send the message.

eric: need to test iri.

phil: request iri used in runtime, which makes for a property value in jms.

eric: properties may be unspecified: want to check default. properties may be unspecified: undefined. properties may be specified: check value. might be specified in various places.

phil: some test cases won't include wsdl (we don't require it); we may have properties set from various places.

eric: need link to those?

phil: possibly yes, how describe properties in wsdl? or in iri?

amy: there are other properties: properties that must be defined, but we don't define what the specific values are, such as for jndi.

phil: thought of using relative values.

amy: not enough: ought to have a place to put a substitution/variable there.

phil: so, for instance, in the jndi specification, instead of relative or "myuri" value, use a syntax that names a variable.

amy, eric: yes. this lets us test equivalence between variables, too.

phil: do we need a brief description of the variables in the test case?

amy: sure, sounds like doc element, possibly with linkages.

eric: phil, willing to incorporate some of the changes proposed in this discussion?

phil: sure.

eric: okay, let's complete the discussion, then assign some actions (to phil or to others).

phil: in two-way request, property values in brackets are placeholders. may not be able to define the values.

amy: can we use the variable syntax for this?

phil: was thinking that syntax would be used for vendors for value that they set.

amy: sure, but can also be used for things set by the engine, no?

phil: okay, but we need to make it clear in the test case whether this is something that the application sets, or something that will be set by the engine, to avoid confusion.
... further we get from ws-addressing, less confident that can produce the html results, not expert in xslt.

amy, eric: we have xslt expertise on the committee.

eric: see numbers on the elements, what are they?

phil: those correspond to assertions in the soap-jms specification.
... so there will be a features.xml file that defines the feature number, and it will produce html which will produce a brief description and then link directly into specification.

eric: need to use the full id, not just the numbers, so that we can auto-generate links.
... want to avoid separate features.xml file, if we can link directly into the spec.

phil: other questions?
... testcases.xsl does the transformation from testcases.xml to html describing the test case.
... documents/messages/soap-1.1, there's an example of a soap envelope, in the file there.
... also a two-way request/response example.

<scribe> ACTION: Phil to incorporate changes brought up in this discussion, due next week [recorded in http://www.w3.org/2008/08/26-soap-jms-minutes.html#action01]

<trackbot> Created ACTION-26 - Incorporate changes brought up in this discussion, due next week [on Phil Adams - due 2008-09-02].

phil: may need help from the xslt experts, however.

<scribe> ACTION: eric to examine/update xslt, once test cases stabilizes, due in two weeks. [recorded in http://www.w3.org/2008/08/26-soap-jms-minutes.html#action02]

<trackbot> Created ACTION-27 - Examine/update xslt, once test cases stabilizes, due in two weeks. [on Eric Johnson - due 2008-09-02].

<scribe> ACTION: Roland to work on adding test case documents and scripts to version control, due 2008-09-16 [recorded in http://www.w3.org/2008/08/26-soap-jms-minutes.html#action03]

<trackbot> Created ACTION-28 - Work on adding test case documents and scripts to version control, due 2008-09-16 [on Roland Merrick - due 2008-09-02].

eric: will chair next week, call for objections?

no objections.

eric: was comment on mailing list, after phil put out first draft, mentioning ws-addressing, encouraging doing more with ws-addressing.

phil: just clarified that we're using their example of how to test, not using ws-addressing.

eric, phil: it's all public stuff, which means we're going to have people not in the working group making comments on things before they're fully baked. grin and bear it.

eric: only five minutes, which is not really enough for derek's mail or the wording changes to permit support of textmessage.

call for further issues. none raised.

meeting ends.

Summary of Action Items

[NEW] ACTION: eric to examine/update xslt, once test cases stabilizes, due in two weeks. [recorded in http://www.w3.org/2008/08/26-soap-jms-minutes.html#action02]
[NEW] ACTION: Phil to incorporate changes brought up in this discussion, due next week [recorded in http://www.w3.org/2008/08/26-soap-jms-minutes.html#action01]
[NEW] ACTION: Roland to work on adding test case documents and scripts to version control, due 2008-09-16 [recorded in http://www.w3.org/2008/08/26-soap-jms-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/08/26 16:56:44 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Found Scribe: alewis
Inferring ScribeNick: alewis

WARNING: No "Present: ... " found!
Possibly Present: Bhakti Derek Peter_Easton Phil TIBCO Yves aaaa aabb aacc aadd alewis amy eric joined peaston soap-jms trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/public-soap-jms/2008Aug/att-0035/00-part
Found Date: 26 Aug 2008
Guessing minutes URL: http://www.w3.org/2008/08/26-soap-jms-minutes.html
People with action items: eric phil roland

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


[End of scribe.perl diagnostic output]