RE: Proposed resolution for issue 440

 

> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
> Sent: 08 November 2003 03:33
> To: Martin Gudgin
> Cc: Marc Hadley; Xml-Dist-App@W3. Org
> Subject: 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).

If you want the data to be INLINED then you MUST serialize it twice.

> 
> 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.

You are quite correct. If you want to have multiple references to the same thing, you have to design that in. I don't see this as being a bug.

> 
> 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. 

And I think it meets the use case as stated.

> If not, can you please explain what you meant.

I think you understand perfectly. It comes down to this:

If you want the data to be inline, then you have to pay the price of serializing it twice.
If you don't want to pay the price of serializing the data twice, the data can't be inline ( you must use URI and the Representation header ).

Gudge

> 
> 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 Saturday, 8 November 2003 09:02:28 UTC