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

David Illsley
Web Services Development
MP127, 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/03/2006 19:12

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

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

Paul


-----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 
@message='1']/log:content/soap11:Envelope/soap11:Header/wsa:MessageID"/> 
            <assert test=
"not(soap11:Envelope/soap11:Header/wsa:RelatesTo/@RelationshipType) or 
soap11:Envelope/soap11:Header/wsa:RelatesTo/@RelationshipType = 
'http://www.w3.org/2005/08/addressing/reply'"/>

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

Thoughts?
David

David Illsley
Web Services Development
MP127, IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
david.illsley@uk.ibm.com
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