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.

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

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

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

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.