RE: A fix for the async case and the WS-I logs

Hi Paul,
I agree this deserves some careful thought and I'm not overly attached to 
my solution.
I think that numbering 1,2,3,4 could be a good solution (as we can 
additionally assert that 2 and 4 are empty).

The reason I avoided that route was that it wouldn't be compatible with 
Microsofts logs (they don't seem to contain elements for the empty HTTP 
responses)

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> 
30/01/2006 11:14

To
David Illsley/UK/IBM@IBMGB, <public-ws-addressing-tests@w3.org>
cc

Subject
RE: A fix for the async case and the WS-I logs






Hi David

Thanks for the detailed work and instructions here!
 
I'd like to take some time and think carefully about this. 

The approach I was considering was for these message patterns 'correctly'
numbering the messages '1','2','3','4' to match the messages 
identified on messsage-exchange patterns page:
http://www.w3.org/2002/ws/addr/testsuite/exchanges/#SOAP12-HTTP-In-Out-Callback 


It's a bigger change, but may save churn later.

Paul

-----Original Message-----
From: public-ws-addressing-tests-request@w3.org on behalf of David Illsley
Sent: Sun 1/29/2006 4:49 PM
To: public-ws-addressing-tests@w3.org
Subject: A fix for the async case and the WS-I logs
 
I like green... and here's how we (well just IBM at the moment) can get 
some more...

The area of the WS-I logs that I think caused most problems were those 
tests which use non-anonymous reply/fault to addresses. In these cases the 

WS-I monitor consists of 2 request response logs for each of these tests.
The problem is how to select the 2 relevant messages from the 4 to apply 
the assertions againt. I'm proposing a pretty simplistic solution, which 
has at least one general down side but which I'm happy to accept for logs 
submitted by IBM.

The approach is twofold:
        1. Remove all messageEntry elements from the WS-I log files (or 
more accurately don't copy them across) which have an empty messageContent 

element
                In order to confirm that messages haven't been removed 
that should have assertions applied againt them, I suggest adding the 
following assertion to the first message of the aync tests:
        2. When there are multiple message elements in the WS-Addressing 
log file format with the same testcase id, renumber the message value of 
the second one to 2.
                This is where the downside comes in ... it doesn't allow 
runs of the same test in the same log. It also mandates that there is no 
re-ordering of the logs but right now that isn't a problem.
                There are more advanced things we could do to pick out the 

second message as a reply e.g. examining the contents for an echoOut or 
Fault element or even using the WSAddressin
                 RelatesTo value but that was beyond my XPath expertise

        In order to confirm that this all works can I also suggest adding 
the following assertion to the request messages of the async tests:
                <assert test=
"../following-sibling::log:message[@testcase=current()/../@testcase and 
@message='2']"/> 

No doubt Jonathan and Paul can come up with a better way of doing it if 
they have time but to keep things going I've got a very basic working 
solution going (sorry if my XSLT/XPath is horrendously inefficient).
It consists of 2 changes:

1, ws-i.xsl:
        Replace
                        <xsl:for-each select="//wsi-log303:messageEntry">
        with
                        <xsl:for-each 
select="//wsi-log303:messageEntry[string-length(wsi-log303:messageContent/text())>0]">
And similarly for the other namespace

2. Add yet another file to the pipeline for the WS-I logs: fix-asyc.xslt
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" 
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
xmlns:log="http://www.w3.org/2002/ws/addressing/logs/" 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
        <xsl:output method="xml" version="1.0" encoding="UTF-8" 
indent="yes"/>
        <xsl:template match="* | comment()">
                <xsl:copy>
                        <xsl:apply-templates select="@*"/>
                        <xsl:apply-templates/>
                </xsl:copy>
        </xsl:template>
        <xsl:template match="log:message">
                <xsl:copy>
                        <xsl:apply-templates select="@*"/>
                        <xsl:call-template 
name="testcase-message-renumber">
                        <xsl:with-param name="testcase" 
select="@testcase"/>
                        </xsl:call-template>
                        <xsl:apply-templates/>
                </xsl:copy>
        </xsl:template>
        <xsl:template name="testcase-message-renumber">
                <xsl:param name="testcase"/>
                <xsl:attribute name="message">
                <xsl:choose>
                <xsl:when 
test="preceding-sibling::log:message[@testcase=$testcase]">2</xsl:when>
                <xsl:otherwise>1</xsl:otherwise></xsl:choose>
                </xsl:attribute>
        </xsl:template>
        <xsl:template match="@*">
                <xsl:copy-of select="."/>
        </xsl:template>
</xsl:stylesheet>

This should make the IBM-IBM column from the event logs all green... and 
should be usable by the other participants using the WS-I tool if they're 
happy to accept the limitation I mentioned above.
Paul, if this seems reasonable can you add these changes to the workflow, 
at least for the IBM case?
Now for some attention to the new tests!
Cheers,
David

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