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
>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.