- 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