RE: message contents -- was Minutes - WS-Addressing Test Suite TF call 5 Jan 2006

BTW, the only reason I care about the brackets is human-readibility.
Any fixed format or SOAP header would do fine (but again, why not go
with one that's easy to look at?).

--G 

> -----Original Message-----
> From: public-ws-addressing-tests-request@w3.org 
> [mailto:public-ws-addressing-tests-request@w3.org] On Behalf 
> Of Glen Daniels
> Sent: Monday, January 09, 2006 11:14 AM
> To: paul.downey@bt.com; public-ws-addressing-tests@w3.org
> Subject: RE: message contents -- was Minutes - WS-Addressing 
> Test Suite TF call 5 Jan 2006
> 
> 
> Hi Paul:
> 
> The contents of the notify/echo string are a) easy to change, 
> and b) not things that are really part of an implementation - 
> they're part of the test suite itself.  As such it shouldn't 
> be much trouble to have everyone send the same pattern, 
> should it?  Why make life difficult for ourselves?
> 
> What I'm after here is a clear and simple way to look at a 
> given message exchange and know for sure which test was being 
> executed.  This is going to make writing validating endpoints 
> easier (otherwise you need to configure the endpoint before 
> the messages are received - so I'm not exactly sure how you 
> can say the tests should work without being keyed on the test 
> number?), it's going to make debugging easier (not that we'll 
> need any of that of course :)), and it's going to make 
> reading the log files easier, not to mention writing up the results.
> 
> Honestly I don't care if we use a fixed string format or use 
> a SOAP header, but I feel pretty strongly that it's a mistake 
> to skip this kind of thing.
> 
> --Glen 
> 
> > -----Original Message-----
> > From: paul.downey@bt.com [mailto:paul.downey@bt.com]
> > Sent: Monday, January 09, 2006 11:04 AM
> > To: Glen Daniels; public-ws-addressing-tests@w3.org
> > Subject: message contents -- was Minutes - WS-Addressing 
> Test Suite TF 
> > call 5 Jan 2006
> > 
> > Hi Glen,
> > 
> > sending the test number is optional, given the tests should work 
> > without being keyed on the test number.
> > 
> > However some of the defaulting and explicit values in 
> responses could 
> > be legitimately keyed on the test number, and I think 
> that's OK for a 
> > joke canned interaction, but not for a test with a real 
> > implementation.
> > 
> > I think we can identify the fault and test number as things stand 
> > using the following regex expressions:
> > 
> >   /^$/                      
> >         - receiver must fault
> > 
> >   /^fault/                  
> >         - receiver must fault
> > 
> >   /^.*(test[0-9]{4,4}).*$/  
> >         - $1 contains the test number
> > 
> > Adding the '[' ']' is OK for you as a sender, but I think 
> you can do 
> > what you want without requiring everybody to send text in a 
> different 
> > order or including the '[' ']' eye-catchers..
> > 
> > Sound OK, or am I missing something important?
> > 
> > Paul
> > 
> > 
> > 
> > -----Original Message-----
> > From: public-ws-addressing-tests-request@w3.org on behalf of Glen 
> > Daniels
> > Sent: Mon 1/9/2006 3:19 PM
> > To: public-ws-addressing-tests@w3.org
> > Subject: RE: Minutes - WS-Addressing Test Suite TF call 5 Jan 2006
> >  
> > 
> > 
> > Could we actually go one step further here?  It would be nice if 
> > receiver implementations knew what test was actually being run in a 
> > standard way, so that they could do validation correctly.
> > 
> > Can we all standardize on strings like this:
> > 
> > [test1100] anything here
> > 
> > In other words, "[" + test name + "]" + string
> > 
> > I think this will end up making our lives (and log files) 
> MUCH easier.
> > We could either keep the idea of faulting on something like this:
> > 
> > [test1133] fault
> > 
> > Or just fault on an empty "string":
> > 
> > [test1133]
> > 
> > Thoughts?
> > --G
> > 
> > > -----Original Message-----
> > > From: public-ws-addressing-tests-request@w3.org
> > > [mailto:public-ws-addressing-tests-request@w3.org] On
> > Behalf Of David
> > > Illsley
> > > Sent: Friday, January 06, 2006 6:47 AM
> > > To: paul.downey@bt.com
> > > Cc: public-ws-addressing-tests@w3.org;
> > > public-ws-addressing-tests-request@w3.org
> > > Subject: Re: Minutes - WS-Addressing Test Suite TF call 5 Jan 2006
> > > 
> > > 
> > > Having agreed on the call last night that the testname
> > should be moved
> > > into the echo string itself rather than be an attribute (because 
> > > having it as an attribute changes the required schema) I
> > realised why
> > > it is that way... so that messages which attempt to
> > generate a fault
> > > by sending the empty string still have the test string in them 
> > > somewhere.
> > > 
> > > I've spoken to Paul and agreed that we'll modify the operation 
> > > semantics for notify and echo so that either an empty text
> > string or a
> > > text string beginning with the string 'fault' should 
> cause a fault. 
> > > This shouldn't break any existing implementations of the 
> test suite 
> > > and should be minimal work to add recognition of 'fault'.
> > We will then
> > > be free to trigger faults using strings like fault-test1133
> > > 
> > > David
> > > 
> > > David Illsley
> > > Web Services Development
> > > IBM Hursley Park, SO21 2JN
> > > +44 (0)1962 815049 (Int. 245049)
> > > david.illsley@uk.ibm.com
> > > 
> > > 
> > > 
> > > <paul.downey@bt.com>
> > > Sent by: public-ws-addressing-tests-request@w3.org
> > > 
> > > 05/01/2006 21:55 To
> > > <public-ws-addressing-tests@w3.org>
> > > cc
> > > Subject
> > > Minutes - WS-Addressing Test Suite TF call 5 Jan 2006
> > > 
> > > 	
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Present: 
> > >  David Illsley (IBM)
> > >  Mike Vernal (Microsoft)
> > >  Mark Nottingham (WG Chair)
> > >  Giovanni Boschi
> > >  Kim Palko
> > >  Glen Daniels (Sonic and Apache)
> > >  Paul Downey (BT)
> > > 
> > > 
> > > agenda+ Action items
> > > 
> > > ACTION: pauld to flag which tests are for CORE, SOAP, WSDL CR
> > > (PENDING)
> > > 
> > > (not discussed!)
> > > 
> > > -----
> > > 
> > > Glen concerned about lack of non-anonymous test cases and
> > combinations
> > > thereof:
> > > 
> > > http://www.w3.org/2002/ws/addr/testsuite/issues/#test15
> > > 
> > > Glen: to supply non-anon ReplyTo/FaultTo test cases based upon 
> > > existing operations.
> > > 
> > > These shouldn't impact those implementing the current 
> operations as 
> > > services.
> > > 
> > > Implementations are not required to generate each and every
> > test case
> > > message - though expected to process and respond correctly
> > to messages
> > > sent to them. We can use a canned client to send specific 
> requests.
> > > 
> > > ACTION: Paul to make his canned implementation available
> > > 
> > > -----
> > > 
> > > agenda+ Dispatching by Action
> > > 
> > > GED (v) Action, specific testing required in this round of CR?
> > > http://lists.w3.org/Archives/Public/public-ws-addressing-tests
> > > /2006Jan/0007.html
> > > 
> > > Consensus on the call: we're happy with the Status Quo of 
> the tests 
> > > for Vancouver - i.e. echoIn and echoOut message bodies enabling 
> > > processing keyed by Action and/or GED.
> > > 
> > > WSDL CR testing may include tests to prove dispatching on
> > the action,
> > > should that be deemed appropriate.
> > > 
> > > -----
> > > 
> > > agenda+ Features not covered by tests
> > > 
> > > http://www.w3.org/2002/ws/addr/testsuite/features/
> > > 
> > > * wsa:RelatesTo/@RelationshipType defaulting
> > > 
> > > http://www.w3.org/2002/ws/addr/testsuite/features/#core07
> > > 
> > > David suggests an echo followed by a notify as one way of 
> proving a 
> > > relationship.
> > > 
> > > requiring defaulting  of RelationshipType is tricky
> > > - as with the notify tests, implementations may not be able to 
> > > generate all of the messages.
> > > 
> > > ACTION: Paul to write a RelatesTo test
> > > 
> > > Again a 'canned' server may be used to send defaulted and
> > undefaulted
> > > replies to test clients.
> > > 
> > > * optional faults
> > > 
> > > http://www.w3.org/2002/ws/addr/testsuite/features/#soap07
> > > 
> > > Lack of test cases - Glen raises it would be interesting to
> > know who
> > > had implemented what error codes - Paul remains concerned
> > how many are
> > > testable or implicitly imply order of processing.
> > > 
> > > ACTION: Paul to enumerate missing fault code tests
> > > ACTION: Paul to elicit which fault codes have been implemented
> > > 
> > > -----
> > > 
> > > agenda+ Other Issues
> > > 
> > > http://www.w3.org/2002/ws/addr/testsuite/issues/
> > > 
> > > ....
> > > 
> > > -----
> > > 
> > > agenda+ The interoperability Event
> > > 
> > > http://lists.w3.org/Archives/Public/public-ws-addressing/2005D
> > > ec/0034.html
> > > http://www.w3.org/2002/ws/addr/testsuite#status
> > > 
> > > Unclear if running implementations on laptops will be available 
> > > outside the hotel / room. Ideally endpoints should be publicly 
> > > available.
> > > 
> > > 
> > > -----
> > > 
> > > agenda+ Status of implementations
> > > 
> > > IBM, Microsoft, Axis2 confirmed on the call, Axis C/C++, 
> Sonic, Sun 
> > > and JBOSS possibly ready for Vancouver.
> > > 
> > > Paul asks that implementations should be able to optionally
> > send the
> > > test case number as content (not as additional elements or
> > attributes
> > > which would require the WSDL changing the Schema element from an 
> > > xs:string into ComplexType.) as described:
> > > http://www.w3.org/2002/ws/addr/testsuite/#operations
> > > 
> > > -----
> > > Previous meetings:
> > > http://lists.w3.org/Archives/Public/public-ws-addressing-tests
> > > /2005Dec/0033.html
> > > http://lists.w3.org/Archives/Public/public-ws-addressing-tests
> > > /2005Dec/0016.html
> > > http://lists.w3.org/Archives/Public/public-ws-addressing-tests
> > > /2005Dec/0003.html
> > > http://lists.w3.org/Archives/Public/public-ws-addressing-tests
> > > /2005Nov/0001.html
> > > http://lists.w3.org/Archives/Public/public-ws-addressing-tests
> > > /2005Oct/0004.html
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
>

Received on Monday, 9 January 2006 16:19:59 UTC