- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Thu, 6 Nov 2003 10:41:20 -0800
- To: "Marc Hadley" <Marc.Hadley@Sun.COM>
- Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
> -----Original Message----- > From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] > 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: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. >
Received on Thursday, 6 November 2003 13:41:23 UTC