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. MTOM 
provides one approach to attachments but I fail to see why it shouldn't 
be composable with alternative mechanisms. What gets broken in MTOM by 
allowing this flexibility ?

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

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

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