RE: Proposed resolution for issue 440

 

> -----Original Message-----
> From: Marc Hadley [mailto:[email protected]] 
> Sent: 06 November 2003 18:23
> To: Martin Gudgin
> Cc: Xml-Dist-App@W3. Org
> Subject: Re: Proposed resolution for issue 440
> 
> On 6 Nov 2003, at 12:08, 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.
> 
> I don't think we need to exclude additional MIME parts not 
> involved in MTOM processing for MTOM to remain an effective 
> abstraction.

And that is the crux of our disagreement

> 
> >  Otherwise, we might as well have not bothered.
> >
> A little over dramatic perhaps ;-).

I don't think so.

> 
> > Regarding multiple references to the same attachment, the 
> > Representations header gives you one way of dealing with this.
> 
> Yes, thinking about this some more we could combine the 
> functions of the representation header and the attachment 
> anchor I suggested below. 
> The combined header would then contain all the attachment 
> metadata (mime type, content-location, content-id, ... in XML 
> form and what we now think of as xbinc:Include elements would 
> instead be intra-message references to the header. The key 
> thing IMO is to have a normative mechanism for referring to 
> such a combined header - the xbinc:IncludeRef in my example.

Why, when we already have xs:anyURI?

> 
> >  As Hervé points out applications are also free to use their own 
> > mechanisms.
> >
> So you want to give applications freedom to use their own 
> mechanisms for referring to representations within the SOAP 
> message but take away the freedom of applications to use 
> attachments outside the MTOM processing model - that seems a 
> little inconsistent ?

I don't think so. See crux above.

Gudge

> 
> Marc.
> 
> >
> >> -----Original Message-----
> >> From: Marc Hadley [mailto:[email protected]]
> >> 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 <[email protected]>
> >> Web Technologies and Standards, Sun Microsystems.
> >>
> >
> >
> --
> Marc Hadley <[email protected]>
> Web Technologies and Standards, Sun Microsystems.
>