Re: Use of conversation in the 'observer' causing problems

Replying to myself.... a slippery slope.
I've done a little digging and the specific change I'm proposing is in 
mkschema.xsl:
<sch:rule context="log:message[@testcase='{$testcase}'][@message='1' and 
(not(@conversation) or @conversation!='2')]/log:content">
to
<sch:rule 
context="log:message[@testcase='{$testcase}'][@message='1']/log:content">
and
<sch:rule context="log:message[@testcase='{$testcase}'][@conversation='2' 
or @message='2']/log:content">
to
<sch:rule 
context="log:message[@testcase='{$testcase}'][@message='2']/log:content">

By my estimate this will (accurately) turn about 8 reds green and I can't 
see a downside...

N.B. This is not a fix for the async cases but for ALL 2 way SOAP1.2 
messages between Sun->IBM and IBM->Microsoft... and who knows which WS-I 
files in the future.

David

David Illsley
Web Services Development
IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
david.illsley@uk.ibm.com



David Illsley/UK/IBM@IBMGB 
Sent by: public-ws-addressing-tests-request@w3.org
08/02/2006 09:01

To
<public-ws-addressing-tests@w3.org>
cc

Subject
Use of conversation in the 'observer' causing problems







In the Sun ->IBM and IBM->Microsoft columns, a bunch of tests are failing 
(all 12xx where xx>=30) because 2 'conversations' were used to capture the 
logs. 
I haven't had time to fully back track this to the source (the observer is 
a bit of a black box for me) but I can see that the problem is being 
caused by matches such as: 
<xsl:template match="log:message[@testcase='test1230'][@conversation='2' 
or @message='2']/log:content" priority="3999" mode="M30"> 
in processor-xmlout.xsl This means that a message 1 in a conversation 2 is 
having the message 2 assertions run against it. 

I'm guessing these refrerences to conversationid were added to help with 
the async case but I don't believe they are doing this at the moment. 
Since there is no way to predict the way that clients and servers will 
behave with regards to keep-alive and conversations I propose that 
references to the conversationid be removed from the observer and it be 
based entirely on messageid (which is consistent with all the recent 
proposals for the async case I've seen). 

David 

David Illsley
Web Services Development
IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
david.illsley@uk.ibm.com