W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2003

RE: Proposed resolution for issue 440

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Thu, 6 Nov 2003 09:08:05 -0800
Message-ID: <DD35CC66F54D8248B6E04232892B63384EDA47@RED-MSG-43.redmond.corp.microsoft.com>
To: "Marc Hadley" <Marc.Hadley@Sun.COM>
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>

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
> >
> --
> Marc Hadley <marc.hadley@sun.com>
> Web Technologies and Standards, Sun Microsystems.
> 
Received on Thursday, 6 November 2003 12:09:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT