- 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