Re: Proposed resolution for issue 440

Gudge,

We have already accepted use case UC6 [2]. It seems to me that this 
requires that we allow multiple references to the same attachment.

You have suggested that Representation header can be used for this 
purpose. I don't see how this will work (possibly because of not 
understanding exactly what you meant).

For example, I may have the following XML fragment to be send inside a 
SOAP env:

<foo>
   <bindata1>...</bindata>
   <bindata2>...</bindata2>
<foo>

Both bindata1 and bindata2 have the exact same binary content.
I can include the data in the MIME part with content-id 
"1234@example.org" and send the following (along with the right MIME parts):

<foo>
   <bindata1>
     <xbinc:Include href="cid:1234@example.org"/>
   </bindata1>
   <bindata2>
     <xbinc:Include href="cid:1234@example.org"/>
   </bindata2>

If I am not allowed to do this, then the binary data has to be 
replicated in two MIME parts (defeats the purpose of optimization).

I don't quite see how Representation header fits the bill. To use the 
Representation header, I have to change the original infoset that I 
wanted to send (by inventing a application specific mechanism of 
referring to the URI whose content is carried by the Representation 
header) -- which means it is no longer just optimization.

For example I can do the following:

<foo>
   <bindata1 myhref="http://example.com/bindata"/>
   <bindata2 myhref="http://example.com/bindata"/>
</foo>

where, "http://example.com/bindata" is the value of the "URI" attribute 
on the Representation header element.

Did I correctly infer what you were trying to say about how 
Representation header can be used? If so, I don't think it fits the 
bill. If not, can you please explain what you meant.

Thx.

-Anish
--



[2] http://www.w3.org/2000/xp/Group/3/10/wd/soap-os-ucr.html


Martin Gudgin wrote:

> I disagree entirely. As far as I'm concerned the WHOLE POINT of PASWA/MTOM is to ensure that ALL MIME parts are in the infoset. Otherwise, we might as well have not bothered. 
> 
> Regarding multiple references to the same attachment, the Representations header gives you one way of dealing with this. As Hervé points out applications are also free to use their own mechanisms.
> 
> Gudge
> 
> 
>>-----Original Message-----
>>From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] 
>>Sent: 06 November 2003 16:04
>>To: Martin Gudgin
>>Cc: Xml-Dist-App@W3. Org
>>Subject: Re: Proposed resolution for issue 440
>>
>>On 5 Nov 2003, at 12:48, Martin Gudgin wrote:
>>
>>>Proposed resolution:
>>>
>>>Each MIME body part (except the root) MUST be referenced by exactly 
>>>one xbinc:Include element.
>>>
>>
>>I think requiring every attachment to have a corresponding 
>>xbinc:Include is too restrictive. Adopting this approach 
>>would effectively disallow use of existing attachment 
>>techniques. MTOM provides one well specified approach to 
>>attachments but it shouldn't prevent someone from using an 
>>alternative. MTOM should support composition with other 
>>attachments techniques rather than rule them out. I don't 
>>think the MTOM spec has much to say about attachments that 
>>aren't referenced using an xbinc:Include element but it 
>>certainly shouldn't disallow them.
>>
>>I also think there are many cases where a single attachment 
>>would be logically included in multiple places in a message 
>>and that we should address this case in a normative manner 
>>rather than defer to some application specific means of 
>>supporting this.
>>
>>Perhaps we could refactor the include mechanism into two separate
>>components: a SOAP header block that forms an anchor for 
>>references to an attachment plus a schema type or 
>>element/attribute that is used to refer to the anchor header 
>>blocks where the data they refer to should be logically included. E.g.
>>
>><s:Envelope xmlns:s="...">
>>   <s:Header>
>>     <xbinc:AttachmentAnchor xmlns:a="..." id="id1" href="cid:..."/>
>>   </s:Header>
>>   <s:Body>
>>     <d:document xmlns:d="...">
>>       <picture xbinc:IncludeRef="id1">
>>       </picture>
>>     </d:document>
>>   </s:Body>
>></s:Envelope>
>>
>>Only one AttachmentAnchor would be allowed per MTOM attachment. 
>>Following MTOM processing the picture element would logically 
>>contain a
>>base64 encoded version of the attachment referred to by the 
>>corresponding Attachment Anchor and would maintain the 
>>xbinc:IncludeRef aii.
>>
>>Marc.
>>
>>
>>>[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x440
>>>
>>

> 
>

Received on Friday, 7 November 2003 22:33:02 UTC