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

Just updated our implementation (locally) to on non faulting test the 
message is:
test1100
And on tests that are expected to fault
fault-test1100
seems workable as described to me.


Rick Rineholt
"MAINTENANCE FREE -- It's impossible to fix."

rineholt@us.ibm.com




<paul.downey@bt.com> 
Sent by: public-ws-addressing-tests-request@w3.org
01/09/2006 11:04

To
<gdaniels@sonicsoftware.com>, <public-ws-addressing-tests@w3.org>
cc

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
> 
> 
> 
>