W3C home > Mailing lists > Public > public-ws-addressing-tests@w3.org > March 2006

RE: Additional assertions for 1150 and 1250

From: David Illsley <david.illsley@uk.ibm.com>
Date: Sun, 5 Mar 2006 20:31:13 +0000
To: <paul.downey@bt.com>
Cc: public-ws-addressing-tests@w3.org, public-ws-addressing-tests-request@w3.org
Message-ID: <OF4625A983.E6D49F90-ON80257128.006BA70E-80257128.0070B25B@uk.ibm.com>
Hmmm.... interesting...
I can tell you what our implementation does... which is to assign [message 
id] with the 'first' one and then fault on (processing) the second one. 
Then from the rules in the Core (see below), the RelatesTo 
(RelationshipType=reply) is set to the value assigned to [message id]. Of 
course I don't see a reason why someone else might not choose the other 
one and do the same. Also,I think it would be valid to include 2 
RelatesTo, both of type reply with a different message id in each. 
Finally, I suppose someone might decide they don't know what the [message 
id] is and use the 'unspecified message uri'

On top of this there is Core 3.4 (which includes 2 relevant MUSTs):
In either of the above cases, if the related message lacks a [message id] 
property, the processor MUST fault.
Send the message according to the previous section, but also including:
[relationship]: this property MUST include a pair of IRIs as follows; the 
relationship type is the predefined reply URI 
"http://www.w3.org/2005/08/addressing/reply" and the related message's 
identifier is the [message id] property value from the message being 
replied to; other relationships MAY be expressed in this property

The second MUST there does suggest to me that we should have an assertion 
to check that there is a RelatesTo with RelationshipType=reply in the 
response, and I think that the contents could be any of the input message 
ids or the unspecified message uri.

Until tomorrow,

David Illsley
Web Services Development
MP127, IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)

Sent by: public-ws-addressing-tests-request@w3.org
05/03/2006 19:12

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

RE: Additional assertions for 1150 and 1250

I'm working on this, and wondering which RelatesTo value should be used
for test1144 - duplicate MessageID fault?


-----Original Message-----
From: public-ws-addressing-tests-request@w3.org on behalf of David Illsley
Sent: Sat 3/4/2006 5:27 PM
To: public-ws-addressing-tests@w3.org
Subject: Additional assertions for 1150 and 1250
Hi all,
I've been reviewing a problem with the IBM client which has problems with 
one of the implementations which doesn't send a RelatesTo on a 
non-anonymous response. (I've followed up on this off-list)
It's important that this header be there (pretty fundamental in an async 
model) and isn't currently caught by an assertion so I propose adding the 
relevant assertions from 1130 and 1230 to 1150 and 1250 to make sure that 
the RelatesTo is there e.g.

            <assert test="soap11:Envelope/soap11:Header/wsa:RelatesTo = 
../preceding-sibling::log:message[@testcase=current()/../@testcase and 
            <assert test=
"not(soap11:Envelope/soap11:Header/wsa:RelatesTo/@RelationshipType) or 
soap11:Envelope/soap11:Header/wsa:RelatesTo/@RelationshipType = 

This is in my opinion important enough to add even at this late stage in 
the game.


David Illsley
Web Services Development
MP127, IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
Received on Sunday, 5 March 2006 20:31:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:54:42 UTC