RE: Proposed resolution for issue 440

 

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] 
> Sent: 06 November 2003 19:12
> To: Martin Gudgin
> Cc: Xml-Dist-App@W3. Org
> Subject: Re: Proposed resolution for issue 440
> 
> On 6 Nov 2003, at 13:41, Martin Gudgin wrote:
> >>
> >> 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
> >
> Rather than simply disagreeing perhaps you could explain your 
> reasons for doing so ;-).
> 
> For my part I think that requiring every attachment to have a 
> corresponding xbinc:Include is too restrictive because it 
> would effectively disallow use of existing attachment 
> techniques. 

I see this as a feature not a bug.

> MTOM provides one approach to attachments but I 
> fail to see why it shouldn't be composable with alternative 
> mechanisms. 

Because the alternatives are not architecturally sound.

> What gets broken in MTOM by allowing this flexibility ?

The fact that the entire message is not an infoset.

> 
> >
> >>
> >>> 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?
> >
> The same reason we need an Include element in the current 
> formulation: 
> we need something to hang the MTOM processing magic on.

I don't think multiple references need any processing magic beyond what xs:anyURI and the Representations header provide.

> 
> >>
> >>>  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.
> >
> I don't see the connection ?

I am fine with restricting freedom along one axis while allowing it in another.

Gudge

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

Received on Thursday, 6 November 2003 14:33:31 UTC