Re: FW: ws-polling comment

Diego and I chatted briefly off-line and the WSA spec allows for multiple 
wsa:RelatesTo headers w/o any restrictions on the contents of each (e.g. 
each can have a RelationshipType of wsa:Reply).  One option would be to 
define a new value for the RelationshipType attribute of wsa:RelatesTo 
(e.g. wsp:Reply) so that they can be differentiated. However, the response 
message is in fact also a wsa:Reply so I believe the current version of 
the ws-polling spec is compliant with WSA but this issues is something 
that should probably be explored in the future.
thanks
-Doug

> From: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf Of 
> Diego Gonzalez
> Sent: Wednesday, November 09, 2005 9:21 AM
> To: www-ws@w3.org
> Subject: ws-polling comment

> Hi,
> 
> I've been reading the spec and I found something quirky in the 
> section 3.2 with respect to wsa:RelatesTo usage. The sample response
> message described in the document contains two wsa:RelatesTo attributes
> 
> <s:Envelope ...>
>   <s:Header ...>
>     <wsa:Action>...</wsa:Action>
>     <wsa:MessageID>xs:anyURI</wsa:MessageID>
>     <wsa:RelatesTo>xs:anyURI</wsa:RelatesTo> ?
>     <wsa:RelatesTo>messageID from GetMessage</wsa:RelatesTo>
>     <wsa:To>...</wsa:To> 
>     ...
>   </s:Header>
>   <s:Body ...>
>    ...
>   </s:Body>
> </s:Envelope>
> 
> The first one is OPTIONAL and the second MUST be present. I think 
> there is very confusing to distinguish between them, since multiple 
> WS stacks use the RelatesTo element to match the response message 
> for a pending response, having two will force the stack to look 
> twice for the message. 
> 
> I think that it will be very valuable to add a RelationshipType 
> attribute to the RelatesTo element that represents the message id of
> the original message, with a value that allows to distinguish between 
them.
> 
> Regards,
> Diego Gonzalez
> Lagash Systems SA
> 
> PS: Is this the correct mailing list to discuss about this submission?

Received on Wednesday, 9 November 2005 22:06:52 UTC