RE: Proposed resolution to issue 455

 

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of Marc Hadley
> Sent: 25 February 2004 22:04
> To: xml-dist-app@w3.org
> Subject: Proposed resolution to issue 455
> 
> I took an action to propose a resolution to issue 455[1]. The 
> issue concerns the relationship of the Representation header 
> block to the SOAP processing model.
> 
> The proposed resolution:
> 
> (i) A representation header block is only 'in scope' wrt to 
> URI resolution if the representation header block is 
> targetted at a role played by the SOAP node.
> 
> (ii) The normal SOAP processing rules apply: the role, 
> mustUnderstand and relay attributes all function as normal.
> 
> (iii) If the header block is targetted at the standard 'next' 
> role and is processed by an intermediary then it should be reinserted.
> 
> (iv) Another (different) header block could be used to 
> override (iii) above.
> 
> The issue also includes the following question:
> 
> "If I want to specifically cause two different 
> representations, of the same media type for the same 
> resource, to be sent to A and B respectively, can I safely 
> use multiple representation headers that differ in their 
> soap:roles to do this?  I would think so."
> 
> I think the answer is yes, but (unfortunately) our current 
> rules would require that, when using our SOAP binding, each 
> representation header include a different MIME part (since we 
> disallow multiple inclusions of a single MIME part) - i.e. 
> this would require multiple copies of the data in the XOP package.

But if they're different representations they'd need to be different
MIME parts anyway, wouldn't they? It's only if they're the same
representation that the multi-ref thing would come up. Personally, I
think this is EXACTLY what soap:role='none' is for. In SOAP 1.1 it was
used for multi-ref stuff in SOAP encoding that was referenced from
multiple headers. Everyone could look at 'none' headers, no one removed
them.

Gudge

Received on Thursday, 26 February 2004 04:39:48 UTC